Android：手把手帶你深刻剖析 Retrofit 2.0 源碼

時間 2019-11-21

標籤 android 手把手深刻剖析 retrofit 2.0 源碼欄目 Android 简体版

原文原文鏈接

前言

在Andrroid開發中，網絡請求十分經常使用
而在Android網絡請求庫中，Retrofit是當下最熱的一個網絡請求庫

今天，我將手把手帶你深刻剖析Retrofit v2.0的源碼，但願大家會喜歡

在閱讀本文前，建議先閱讀文章：這是一份很詳細的 Retrofit 2.0 使用教程（含實例講解）java

1. 簡介

特別注意：android

準確來講，Retrofit 是一個 RESTful 的 HTTP 網絡請求框架的封裝。
緣由：網絡請求的工做本質上是 OkHttp 完成，而 Retrofit 僅負責網絡請求接口的封裝

App應用程序經過 Retrofit 請求網絡，其實是使用 Retrofit 接口層封裝請求參數、Header、Url 等信息，以後由 OkHttp 完成後續的請求操做
在服務端返回數據以後，OkHttp 將原始的結果交給 Retrofit，Retrofit根據用戶的需求對結果進行解析

2. 與其餘網絡請求開源庫對比

除了Retrofit，現在Android中主流的網絡請求框架有：git

Android-Async-Http
Volley
OkHttp

下面是簡單介紹：github

一圖讓你瞭解所有的網絡請求庫和他們之間的區別！算法

附：各個主流網絡請求庫的Github地址json

3. Retrofit 的具體使用

具體請看我寫的文章：這是一份很詳細的 Retrofit 2.0 使用教程（含實例講解）設計模式

4. 源碼分析

4.1 Retrofit的本質流程

通常從網絡通訊過程以下圖：api

其實Retrofit的本質和上面是同樣的套路
只是Retrofit經過使用大量的設計模式進行功能模塊的解耦，使得上面的過程進行得更加簡單 & 流暢

以下圖：數組

具體過程解釋以下：緩存

經過解析網絡請求接口的註解配置網絡請求參數
經過動態代理生成網絡請求對象
經過網絡請求適配器將網絡請求對象進行平臺適配

平臺包括：Android、Rxjava、Guava和java8
經過網絡請求執行器發送網絡請求
經過數據轉換器解析服務器返回的數據
經過回調執行器切換線程（子線程 ->>主線程）
用戶在主線程處理返回結果

下面介紹上面提到的幾個角色

特別注意：因下面的源碼分析是根據使用步驟逐步帶你debug進去的，因此必須先看文章這是一份很詳細的 Retrofit 2.0 使用教程（含實例講解）

4.2 源碼分析

先來回憶Retrofit的使用步驟：
1. 建立Retrofit實例
2. 建立網絡請求接口實例並配置網絡請求參數
3. 發送網絡請求

封裝了數據轉換、線程切換的操做
4. 處理服務器返回的數據

4.2.1 建立Retrofit實例

a. 使用步驟

Retrofit retrofit = new Retrofit.Builder() .baseUrl("http://fanyi.youdao.com/") .addConverterFactory(GsonConverterFactory.create()) .build();

b. 源碼分析

Retrofit實例是使用建造者模式經過Builder類進行建立的

建造者模式：將一個複雜對象的構建與表示分離，使得用戶在不知道對象的建立細節狀況下就能夠直接建立複雜的對象。具體請看文章：建造者模式（Builder Pattern）- 最易懂的設計模式解析

接下來，我將分五個步驟對建立Retrofit實例進行逐步分析

步驟1

<-- Retrofit類 -->
 public final class Retrofit { private final Map<Method, ServiceMethod> serviceMethodCache = new LinkedHashMap<>(); // 網絡請求配置對象（對網絡請求接口中方法註解進行解析後獲得的對象） // 做用：存儲網絡請求相關的配置，如網絡請求的方法、數據轉換器、網絡請求適配器、網絡請求工廠、基地址等 private final HttpUrl baseUrl; // 網絡請求的url地址 private final okhttp3.Call.Factory callFactory; // 網絡請求器的工廠 // 做用：生產網絡請求器（Call） // Retrofit是默認使用okhttp private final List<CallAdapter.Factory> adapterFactories; // 網絡請求適配器工廠的集合 // 做用：放置網絡請求適配器工廠 // 網絡請求適配器工廠做用：生產網絡請求適配器（CallAdapter） // 下面會詳細說明 private final List<Converter.Factory> converterFactories; // 數據轉換器工廠的集合 // 做用：放置數據轉換器工廠 // 數據轉換器工廠做用：生產數據轉換器（converter） private final Executor callbackExecutor; // 回調方法執行器 private final boolean validateEagerly; // 標誌位 // 做用：是否提早對業務接口中的註解進行驗證轉換的標誌位 <-- Retrofit類的構造函數 --> Retrofit(okhttp3.Call.Factory callFactory, HttpUrl baseUrl, List<Converter.Factory> converterFactories, List<CallAdapter.Factory> adapterFactories, Executor callbackExecutor, boolean validateEagerly) { this.callFactory = callFactory; this.baseUrl = baseUrl; this.converterFactories = unmodifiableList(converterFactories); this.adapterFactories = unmodifiableList(adapterFactories); // unmodifiableList(list)近似於UnmodifiableList<E>(list) // 做用：建立的新對象可以對list數據進行訪問，但不可經過該對象對list集合中的元素進行修改 this.callbackExecutor = callbackExecutor; this.validateEagerly = validateEagerly; ... // 僅貼出關鍵代碼 }

成功創建一個Retrofit對象的標準：配置好Retrofit類裏的成員變量，即配置好：

serviceMethod：包含全部網絡請求信息的對象
baseUrl：網絡請求的url地址
callFactory：網絡請求工廠
adapterFactories：網絡請求適配器工廠的集合
converterFactories：數據轉換器工廠的集合
callbackExecutor：回調方法執行器

所謂xxxFactory、「xxx工廠」實際上是設計模式中工廠模式的體現：將「類實例化的操做」與「使用對象的操做」分開，使得使用者不用知道具體參數就能夠實例化出所須要的「產品」類。

具體請看我寫的文章
簡單工廠模式（SimpleFactoryPattern）- 最易懂的設計模式解析
 工廠方法模式（Factory Method）- 最易懂的設計模式解析
 抽象工廠模式（Abstract Factory）- 最易懂的設計模式解析

這裏詳細介紹一下：CallAdapterFactory：該Factory生產的是CallAdapter，那麼CallAdapter又是什麼呢？

`CallAdapter`詳細介紹

定義：網絡請求執行器（Call）的適配器
1. Call在Retrofit裏默認是OkHttpCall
2. 在Retrofit中提供了四種CallAdapterFactory： ExecutorCallAdapterFactory（默認）、GuavaCallAdapterFactory、Java8CallAdapterFactory、RxJavaCallAdapterFactory
做用：將默認的網絡請求執行器（OkHttpCall）轉換成適合被不一樣平臺來調用的網絡請求執行器形式
1. 如：一開始Retrofit只打算利用OkHttpCall經過ExecutorCallbackCall切換線程；但後來發現使用Rxjava更加方便（不須要Handler來切換線程）。想要實現Rxjava的狀況，那就得使用RxJavaCallAdapterFactoryCallAdapter將OkHttpCall轉換成Rxjava(Scheduler)：

// 把response封裝成rxjava的Observeble，而後進行流式操做
Retrofit.Builder.addCallAdapterFactory(newRxJavaCallAdapterFactory().create()); // 關於RxJava的使用這裏不做更多的展開

Retrofit還支持java八、Guava平臺。

好處：用最小代價兼容更多平臺，即能適配更多的使用場景

因此，接下來須要分析的步驟二、步驟三、步驟四、步驟4的目的是配置好上述全部成員變量

步驟2

咱們先來看Builder類

請按下面提示的步驟進行查看

<-- Builder類-->
public static final class Builder { private Platform platform; private okhttp3.Call.Factory callFactory; private HttpUrl baseUrl; private List<Converter.Factory> converterFactories = new ArrayList<>(); private List<CallAdapter.Factory> adapterFactories = new ArrayList<>(); private Executor callbackExecutor; private boolean validateEagerly; // 從上面能夠發現， Builder類的成員變量與Retrofit類的成員變量是對應的 // 因此Retrofit類的成員變量基本上是經過Builder類進行配置 // 開始看步驟1 <-- 步驟1 --> // Builder的構造方法（無參） public Builder() { this(Platform.get()); // 用this調用本身的有參構造方法public Builder(Platform platform) ->>步驟5（看完步驟二、三、4再看） // 並經過調用Platform.get（）傳入了Platform對象 // 繼續看Platform.get()方法 ->>步驟2 // 記得最後繼續看步驟5的Builder有參構造方法 } ... } <-- 步驟2 --> class Platform { private static final Platform PLATFORM = findPlatform(); // 將findPlatform()賦給靜態變量 static Platform get() { return PLATFORM; // 返回靜態變量PLATFORM，即findPlatform() ->>步驟3 } <-- 步驟3 --> private static Platform findPlatform() { try { Class.forName("android.os.Build"); // Class.forName(xxx.xx.xx)的做用：要求JVM查找並加載指定的類（即JVM會執行該類的靜態代碼段） if (Build.VERSION.SDK_INT != 0) { return new Android(); // 此處表示：若是是Android平臺，就建立並返回一個Android對象 ->>步驟4 } } catch (ClassNotFoundException ignored) { } try { // 支持Java平臺 Class.forName("java.util.Optional"); return new Java8(); } catch (ClassNotFoundException ignored) { } try { // 支持iOS平臺 Class.forName("org.robovm.apple.foundation.NSObject"); return new IOS(); } catch (ClassNotFoundException ignored) { } // 從上面看出：Retrofit2.0支持3個平臺：Android平臺、Java平臺、IOS平臺 // 最後返回一個Platform對象（指定了Android平臺）給Builder的有參構造方法public Builder(Platform platform) --> 步驟5 // 說明Builder指定了運行平臺爲Android return new Platform(); } ... } <-- 步驟4 --> // 用於接收服務器返回數據後進行線程切換在主線程顯示結果 static class Android extends Platform { @Override CallAdapter.Factory defaultCallAdapterFactory(Executor callbackExecutor) { return new ExecutorCallAdapterFactory(callbackExecutor); // 建立默認的網絡請求適配器工廠 // 該默認工廠生產的 adapter 會使得Call在異步調用時在指定的 Executor 上執行回調 // 在Retrofit中提供了四種CallAdapterFactory： ExecutorCallAdapterFactory（默認）、GuavaCallAdapterFactory、Java8CallAdapterFactory、RxJavaCallAdapterFactory // 採用了策略模式 } @Override public Executor defaultCallbackExecutor() { // 返回一個默認的回調方法執行器 // 該執行器做用：切換線程（子->>主線程），並在主線程（UI線程）中執行回調方法 return new MainThreadExecutor(); } static class MainThreadExecutor implements Executor { private final Handler handler = new Handler(Looper.getMainLooper()); // 獲取與Android 主線程綁定的Handler @Override public void execute(Runnable r) { handler.post(r); // 該Handler是上面獲取的與Android 主線程綁定的Handler // 在UI線程進行對網絡請求返回數據處理等操做。 } } // 切換線程的流程： // 1. 回調ExecutorCallAdapterFactory生成了一個ExecutorCallbackCall對象 //2. 經過調用ExecutorCallbackCall.enqueue(CallBack)從而調用MainThreadExecutor的execute()經過handler切換到主線程 } // 下面繼續看步驟5的Builder有參構造方法 <-- 步驟5 --> // Builder類的構造函數2（有參） public Builder(Platform platform) { // 接收Platform對象（Android平臺） this.platform = platform; // 經過傳入BuiltInConverters()對象配置數據轉換器工廠（converterFactories） // converterFactories是一個存放數據轉換器Converter.Factory的數組 // 配置converterFactories即配置裏面的數據轉換器 converterFactories.add(new BuiltInConverters()); // BuiltInConverters是一個內置的數據轉換器工廠（繼承Converter.Factory類） // new BuiltInConverters()是爲了初始化數據轉換器 }

對Builder類分析完畢，總結：Builder設置了默認的

平臺類型對象：Android
網絡請求適配器工廠：CallAdapterFactory

CallAdapter用於對原始Call進行再次封裝，如Call到Observable
數據轉換器工廠： converterFactory
回調執行器：callbackExecutor

特別注意，這裏只是設置了默認值，但未真正配置到具體的Retrofit類的成員變量當中

步驟3

仍是循序漸進按步驟來觀看

<-- 步驟1 --> public Builder baseUrl(String baseUrl) { // 把String類型的url參數轉化爲適合OKhttp的HttpUrl類型 HttpUrl httpUrl = HttpUrl.parse(baseUrl); // 最終返回帶httpUrl類型參數的baseUrl（） // 下面繼續看baseUrl(httpUrl) ->> 步驟2 return baseUrl(httpUrl); } <-- 步驟2 --> public Builder baseUrl(HttpUrl baseUrl) { //把URL參數分割成幾個路徑碎片 List<String> pathSegments = baseUrl.pathSegments(); // 檢測最後一個碎片來檢查URL參數是否是以"/"結尾 // 不是就拋出異常 if (!"".equals(pathSegments.get(pathSegments.size() - 1))) { throw new IllegalArgumentException("baseUrl must end in /: " + baseUrl); } this.baseUrl = baseUrl; return this; }

至此，步驟3分析完畢
總結：baseUrl（）用於配置Retrofit類的網絡請求url地址

將傳入的String類型url轉化爲適合OKhttp的HttpUrl類型的url

步驟4

咱們從裏往外看，即先看GsonConverterFactory.creat()

public final class GsonConverterFactory extends Converter.Factory { <-- 步驟1 --> public static GsonConverterFactory create() { // 建立一個Gson對象 return create(new Gson()); ->>步驟2 } <-- 步驟2 --> public static GsonConverterFactory create(Gson gson) { // 建立了一個含有Gson對象實例的GsonConverterFactory return new GsonConverterFactory(gson); ->>步驟3 } private final Gson gson; <-- 步驟3 --> private GsonConverterFactory(Gson gson) { if (gson == null) throw new NullPointerException("gson == null"); this.gson = gson; }

因此，GsonConverterFactory.creat()是建立了一個含有Gson對象實例的GsonConverterFactory，並返回給addConverterFactory（）
接下來繼續看：addConverterFactory（）

// 將上面建立的GsonConverterFactory放入到 converterFactories數組 // 在第二步放入一個內置的數據轉換器工廠BuiltInConverters(）後又放入了一個GsonConverterFactory public Builder addConverterFactory(Converter.Factory factory) { converterFactories.add(checkNotNull(factory, "factory == null")); return this; }

至此，分析完畢
總結：步驟4用於建立一個含有Gson對象實例的GsonConverterFactory並放入到數據轉換器工廠converterFactories裏
1. 即Retrofit默認使用Gson進行解析
2. 若使用其餘解析方式（如Json、XML或Protocobuf），也可經過自定義數據解析器來實現（必須繼承 Converter.Factory）

步驟5

終於到了最後一個步驟了。

public Retrofit build() { <-- 配置網絡請求執行器（callFactory）--> okhttp3.Call.Factory callFactory = this.callFactory; // 若是沒指定，則默認使用okhttp // 因此Retrofit默認使用okhttp進行網絡請求 if (callFactory == null) { callFactory = new OkHttpClient(); } <-- 配置回調方法執行器（callbackExecutor）--> Executor callbackExecutor = this.callbackExecutor; // 若是沒指定，則默認使用Platform檢測環境時的默認callbackExecutor // 即Android默認的callbackExecutor if (callbackExecutor == null) { callbackExecutor = platform.defaultCallbackExecutor(); } <-- 配置網絡請求適配器工廠（CallAdapterFactory）--> List<CallAdapter.Factory> adapterFactories = new ArrayList<>(this.adapterFactories); // 向該集合中添加了步驟2中建立的CallAdapter.Factory請求適配器（添加在集合器末尾） adapterFactories.add(platform.defaultCallAdapterFactory(callbackExecutor)); // 請求適配器工廠集合存儲順序：自定義1適配器工廠、自定義2適配器工廠...默認適配器工廠（ExecutorCallAdapterFactory） <-- 配置數據轉換器工廠：converterFactory --> // 在步驟2中已經添加了內置的數據轉換器BuiltInConverters(）（添加到集合器的首位） // 在步驟4中又插入了一個Gson的轉換器 - GsonConverterFactory（添加到集合器的首二位） List<Converter.Factory> converterFactories = new ArrayList<>(this.converterFactories); // 數據轉換器工廠集合存儲的是：默認數據轉換器工廠（ BuiltInConverters）、自定義1數據轉換器工廠（GsonConverterFactory）、自定義2數據轉換器工廠.... // 注： //1. 獲取合適的網絡請求適配器和數據轉換器都是從adapterFactories和converterFactories集合的首位-末位開始遍歷 // 所以集合中的工廠位置越靠前就擁有越高的使用權限 // 最終返回一個Retrofit的對象，並傳入上述已經配置好的成員變量 return new Retrofit(callFactory, baseUrl, converterFactories, adapterFactories, callbackExecutor, validateEagerly); }

至此，步驟5分析完畢
總結：在最後一步中，經過前面步驟設置的變量，將Retrofit類的全部成員變量都配置完畢。
因此，成功建立了Retrofit的實例

總結

Retrofit 使用建造者模式經過Builder類創建了一個Retrofit實例，具體建立細節是配置了：

平臺類型對象（Platform - Android）
網絡請求的url地址（baseUrl）
網絡請求工廠（callFactory）

默認使用OkHttpCall

網絡請求適配器工廠的集合（adapterFactories）

本質是配置了網絡請求適配器工廠- 默認是ExecutorCallAdapterFactory
數據轉換器工廠的集合（converterFactories）

本質是配置了數據轉換器工廠
回調方法執行器（callbackExecutor）
默認回調方法執行器做用是：切換線程（子線程 - 主線程）

因爲使用了建造者模式，因此開發者並不須要關心配置細節就能夠建立好Retrofit實例，建造者模式get。

在建立Retrofit對象時，你能夠經過更多更靈活的方式去處理你的需求，如使用不一樣的Converter、使用不一樣的CallAdapter，這也就提供了你使用RxJava來調用Retrofit的可能

2. 建立網絡請求接口的實例

2.1 使用步驟

<-- 步驟1：定義接收網絡數據的類 --> <-- JavaBean.java --> public class JavaBean { .. // 這裏就不介紹了 } <-- 步驟2：定義網絡請求的接口類 --> <-- AccessApi.java --> public interface AccessApi { // 註解GET：採用Get方法發送網絡請求 // Retrofit把網絡請求的URL分紅了2部分：1部分baseurl放在建立Retrofit對象時設置；另外一部分在網絡請求接口設置（即這裏） // 若是接口裏的URL是一個完整的網址，那麼放在建立Retrofit對象時設置的部分能夠不設置 @GET("openapi.do?keyfrom=Yanzhikai&key=2032414398&type=data&doctype=json&version=1.1&q=car") // 接受網絡請求數據的方法 Call<JavaBean> getCall(); // 返回類型爲Call<*>，*是解析獲得的數據類型，即JavaBean } <-- 步驟3：在MainActivity建立接口類實例 --> AccessApi NetService = retrofit.create(AccessApi.class); <-- 步驟4：對發送請求的url進行封裝，即生成最終的網絡請求對象 --> Call<JavaBean> call = NetService.getCall();

2.2 源碼分析

結論：Retrofit是經過外觀模式 & 代理模式使用create（）方法建立網絡請求接口的實例（同時，經過網絡請求接口裏設置的註解進行了網絡請求參數的配置）
1. 外觀模式：定義一個統一接口，外部與經過該統一的接口對子系統裏的其餘接口進行訪問。具體請看：外觀模式（Facade Pattern） - 最易懂的設計模式解析
2. 代理模式：經過訪問代理對象的方式來間接訪問目標對象。具體請看：代理模式（Proxy Pattern）- 最易懂的設計模式解析
3. 下面主要分析步驟3和步驟4：

<-- 步驟3：在MainActivity建立接口類實例 --> AccessApi NetService = retrofit.create(NetService.class); <-- 步驟4：對發送請求的url進行封裝，即生成最終的網絡請求對象 --> Call<JavaBean> call = NetService.getCall();

步驟3講解：`AccessApi NetService = retrofit.create(NetService.class);`

public <T> T create(final Class<T> service) { if (validateEagerly) { // 判斷是否須要提早驗證 eagerlyValidateMethods(service); // 具體方法做用： // 1. 給接口中每一個方法的註解進行解析並獲得一個ServiceMethod對象 // 2. 以Method爲鍵將該對象存入LinkedHashMap集合中 // 特別注意：若是不是提早驗證則進行動態解析對應方法（下面會詳細說明），獲得一個ServiceMethod對象，最後存入到LinkedHashMap集合中，相似延遲加載（默認） } // 建立了網絡請求接口的動態代理對象，即經過動態代理建立網絡請求接口的實例 （並最終返回） // 該動態代理是爲了拿到網絡請求接口實例上全部註解 return (T) Proxy.newProxyInstance( service.getClassLoader(), // 動態生成接口的實現類 new Class<?>[] { service }, // 動態建立實例 new InvocationHandler() { // 將代理類的實現交給 InvocationHandler類做爲具體的實現（下面會解釋） private final Platform platform = Platform.get(); // 在 InvocationHandler類的invoke（）實現中，除了執行真正的邏輯（如再次轉發給真正的實現類對象），還能夠進行一些有用的操做 // 如統計執行時間、進行初始化和清理、對接口調用進行檢查等。 @Override public Object invoke(Object proxy, Method method, Object... args) throws Throwable { // 下面會詳細介紹 invoke（）的實現 // 即下面三行代碼 ServiceMethod serviceMethod = loadServiceMethod(method); OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args); return serviceMethod.callAdapter.adapt(okHttpCall); } }); } // 特別注意 // return (T) roxy.newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler invocationHandler) // 能夠解讀爲：getProxyClass(loader, interfaces) .getConstructor(InvocationHandler.class).newInstance(invocationHandler); // 即經過動態生成的代理類，調用interfaces接口的方法其實是經過調用InvocationHandler對象的invoke（）來完成指定的功能 // 先記住結論，在講解步驟4的時候會再次詳細說明 <-- 關注點1：eagerlyValidateMethods（） --> private void eagerlyValidateMethods(Class<?> service) { Platform platform = Platform.get(); for (Method method : service.getDeclaredMethods()) { if (!platform.isDefaultMethod(method)) { loadServiceMethod(method); } // 將傳入的ServiceMethod對象加入LinkedHashMap<Method, ServiceMethod>集合 // 使用LinkedHashMap集合的好處：lruEntries.values().iterator().next()獲取到的是集合最不常常用到的元素，提供了一種Lru算法的實現 } }

建立網絡接口實例用了外觀模式 & 代理模式：

使用外觀模式進行訪問，裏面用了代理模式

1. 外觀模式

外觀模式：定義一個統一接口，外部與經過該統一的接口對子系統裏的其餘接口進行訪問。具體請看：外觀模式（Facade Pattern） - 最易懂的設計模式解析
Retrofit對象的外觀（門店） = retrofit.create()
經過這一外觀方法就能夠在內部調用各個方法建立網絡請求接口的實例和配置網絡請求參數

大大下降了系統的耦合度

2. 代理模式

代理模式：經過訪問代理對象的方式來間接訪問目標對象

分爲靜態代理 & 動態代理：
1. 靜態代理：代理類在程序運行前已經存在的代理方式
2. 動態代理：代理類在程序運行前不存在、運行時由程序動態生成的代理方式
具體請看文章代理模式（Proxy Pattern）- 最易懂的設計模式解析
return (T) roxy.newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler invocationHandler)經過代理模式中的動態代理模式，動態生成網絡請求接口的代理類，並將代理類的實例建立交給InvocationHandler類 做爲具體的實現，並最終返回一個動態代理對象。
生成實例過程當中含有生成實現類的緩存機制（單例模式），下面會詳細分析

使用動態代理的好處：

當NetService對象調用getCall（）接口中方法時會進行攔截，調用都會集中轉發到 InvocationHandler#invoke （），可集中進行處理
得到網絡請求接口實例上的全部註解
更方便封裝ServiceMethod

下面看源碼分析

下面將詳細分析`InvocationHandler類 # invoke（）`裏的具體實現

new InvocationHandler() { private final Platform platform = Platform.get(); @Override public Object invoke(Object proxy, Method method, Object... args) throws Throwable { // 將詳細介紹下面代碼 // 關注點1 // 做用：讀取網絡請求接口裏的方法，並根據前面配置好的屬性配置serviceMethod對象 ServiceMethod serviceMethod = loadServiceMethod(method); // 關注點2 // 做用：根據配置好的serviceMethod對象建立okHttpCall對象 OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args); // 關注點3 // 做用：調用OkHttp，並根據okHttpCall返回rejava的Observe對象或者返回Call return serviceMethod.callAdapter.adapt(okHttpCall); }

下面將詳細介紹3個關注點的代碼。

關注點1： `ServiceMethod serviceMethod = loadServiceMethod(method);`

<-- loadServiceMethod(method)方法講解 --> // 一個 ServiceMethod 對象對應於網絡請求接口裏的一個方法 // loadServiceMethod（method）負責加載 ServiceMethod： ServiceMethod loadServiceMethod(Method method) { ServiceMethod result; // 設置線程同步鎖 synchronized (serviceMethodCache) { result = serviceMethodCache.get(method); // ServiceMethod類對象採用了單例模式進行建立 // 即建立ServiceMethod對象前，先看serviceMethodCache有沒有緩存以前建立過的網絡請求實例 // 若沒緩存，則經過建造者模式建立 serviceMethod 對象 if (result == null) { // 下面會詳細介紹ServiceMethod生成實例的過程 result = new ServiceMethod.Builder(this, method).build(); serviceMethodCache.put(method, result); } } return result; } // 這裏就是上面說的建立實例的緩存機制：採用單例模式從而實現一個 ServiceMethod 對象對應於網絡請求接口裏的一個方法 // 注：因爲每次獲取接口實例都是傳入 class 對象 // 而 class 對象在進程內單例的，因此獲取到它的同一個方法 Method 實例也是單例的，因此這裏的緩存是有效的。

下面，我將分3個步驟詳細分析serviceMethod實例的建立過程：

步驟1：`ServiceMethod類` 構造函數

<-- ServiceMethod 類 -->
public final class ServiceMethod { final okhttp3.Call.Factory callFactory; // 網絡請求工廠 final CallAdapter<?> callAdapter; // 網絡請求適配器工廠 // 具體建立是在new ServiceMethod.Builder(this, method).build()最後的build()中 // 下面會詳細說明 private final Converter<ResponseBody, T> responseConverter; // Response內容轉換器 // 做用：負責把服務器返回的數據（JSON或者其餘格式，由 ResponseBody 封裝）轉化爲 T 類型的對象； private final HttpUrl baseUrl; // 網絡請求地址 private final String relativeUrl; // 網絡請求的相對地址 private final String httpMethod; // 網絡請求的Http方法 private final Headers headers; // 網絡請求的http請求頭 鍵值對 private final MediaType contentType; // 網絡請求的http報文body的類型 private final ParameterHandler<?>[] parameterHandlers; // 方法參數處理器 // 做用：負責解析 API 定義時每一個方法的參數，並在構造 HTTP 請求時設置參數； // 下面會詳細說明 // 說明：從上面的成員變量能夠看出，ServiceMethod對象包含了訪問網絡的全部基本信息 <-- ServiceMethod 類的構造函數 --> // 做用：傳入各類網絡請求參數 ServiceMethod(Builder<T> builder) { this.callFactory = builder.retrofit.callFactory(); this.callAdapter = builder.callAdapter; this.responseConverter = builder.responseConverter; this.baseUrl = builder.retrofit.baseUrl(); this.relativeUrl = builder.relativeUrl; this.httpMethod = builder.httpMethod; this.headers = builder.headers; this.contentType = builder.contentType; . this.hasBody = builder.hasBody; y this.isFormEncoded = builder.isFormEncoded; this.isMultipart = builder.isMultipart; this.parameterHandlers = builder.parameterHandlers; }

步驟2：`ServiceMethod的Builder（）`

public Builder(Retrofit retrofit, Method method) { this.retrofit = retrofit; this.method = method; // 獲取網絡請求接口方法裏的註釋 this.methodAnnotations = method.getAnnotations(); // 獲取網絡請求接口方法裏的參數類型 this.parameterTypes = method.getGenericParameterTypes(); //獲取網絡請求接口方法裏的註解內容 this.parameterAnnotationsArray = method.getParameterAnnotations(); }

步驟3：`ServiceMethod的build（）`

// 做用：控制ServiceMethod對象的生成流程 public ServiceMethod build() { callAdapter = createCallAdapter(); // 根據網絡請求接口方法的返回值和註解類型，從Retrofit對象中獲取對應的網絡請求適配器 -->關注點1 responseType = callAdapter.responseType(); // 根據網絡請求接口方法的返回值和註解類型，從Retrofit對象中獲取該網絡適配器返回的數據類型 responseConverter = createResponseConverter(); // 根據網絡請求接口方法的返回值和註解類型，從Retrofit對象中獲取對應的數據轉換器 -->關注點3 // 構造 HTTP 請求時，咱們傳遞的參數都是String // Retrofit 類提供 converter把傳遞的參數都轉化爲 String // 其他類型的參數都利用 Converter.Factory 的stringConverter 進行轉換 // @Body 和 @Part 類型的參數利用Converter.Factory 提供的 requestBodyConverter 進行轉換 // 這三種 converter 都是經過「詢問」工廠列表進行提供，而工廠列表咱們能夠在構造 Retrofit 對象時進行添加。 for (Annotation annotation : methodAnnotations) { parseMethodAnnotation(annotation); } // 解析網絡請求接口中方法的註解 // 主要是解析獲取Http請求的方法 // 註解包括：DELETE、GET、POST、HEAD、PATCH、PUT、OPTIONS、HTTP、retrofit2.http.Headers、Multipart、FormUrlEncoded // 處理主要是調用方法 parseHttpMethodAndPath(String httpMethod, String value, boolean hasBody) ServiceMethod中的httpMethod、hasBody、relativeUrl、relativeUrlParamNames域進行賦值 int parameterCount = parameterAnnotationsArray.length; // 獲取當前方法的參數數量 parameterHandlers = new ParameterHandler<?>[parameterCount]; for (int p = 0; p < parameterCount; p++) { Type parameterType = parameterTypes[p]; Annotation[] parameterAnnotations = parameterAnnotationsArray[p]; // 爲方法中的每一個參數建立一個ParameterHandler<?>對象並解析每一個參數使用的註解類型 // 該對象的建立過程就是對方法參數中註解進行解析 // 這裏的註解包括：Body、PartMap、Part、FieldMap、Field、Header、QueryMap、Query、Path、Url parameterHandlers[p] = parseParameter(p, parameterType, parameterAnnotations); } return new ServiceMethod<>(this); <-- 總結 --> // 1. 根據返回值類型和方法標註從Retrofit對象的的網絡請求適配器工廠集合和內容轉換器工廠集合中分別獲取到該方法對應的網絡請求適配器和Response內容轉換器； // 2. 根據方法的標註對ServiceMethod的域進行賦值 // 3. 最後爲每一個方法的參數的標註進行解析，得到一個ParameterHandler<?>對象 // 該對象保存有一個Request內容轉換器——根據參數的類型從Retrofit的內容轉換器工廠集合中獲取一個Request內容轉換器或者一個String內容轉換器。 } <-- 關注點1：createCallAdapter() --> private CallAdapter<?> createCallAdapter() { // 獲取網絡請求接口裏方法的返回值類型 Type returnType = method.getGenericReturnType(); // 獲取網絡請求接口接口裏的註解 // 此處使用的是@Get Annotation[] annotations = method.getAnnotations(); try { return retrofit.callAdapter(returnType, annotations); // 根據網絡請求接口方法的返回值和註解類型，從Retrofit對象中獲取對應的網絡請求適配器 // 下面會詳細說明retrofit.callAdapter（） -- >關注點2 } ... <-- 關注點2：retrofit.callAdapter() --> public CallAdapter<?> callAdapter(Type returnType, Annotation[] annotations) { return nextCallAdapter(null, returnType, annotations); } public CallAdapter<?> nextCallAdapter(CallAdapter.Factory skipPast, Type returnType, Annotation[] annotations) { // 建立 CallAdapter 以下 // 遍歷 CallAdapter.Factory 集合尋找合適的工廠（該工廠集合在第一步構造 Retrofit 對象時進行添加（第一步時已經說明）） // 若是最終沒有工廠提供須要的 CallAdapter，將拋出異常 for (int i = start, count = adapterFactories.size(); i < count; i++) { CallAdapter<?> adapter = adapterFactories.get(i).get(returnType, annotations, this); if (adapter != null) { return adapter; } } <-- 關注點3：createResponseConverter（） --> private Converter<ResponseBody, T> createResponseConverter() { Annotation[] annotations = method.getAnnotations(); try { // responseConverter 仍是由 Retrofit 類提供 -->關注點4 return retrofit.responseBodyConverter(responseType, annotations); } catch (RuntimeException e) { throw methodError(e, "Unable to create converter for %s", responseType); } } <-- 關注點4：responseBodyConverter（） --> public <T> Converter<ResponseBody, T> responseBodyConverter(Type type, Annotation[] annotations) { return nextResponseBodyConverter(null, type, annotations); } public <T> Converter<ResponseBody, T> nextResponseBodyConverter(Converter.Factory skipPast, int start = converterFactories.indexOf(skipPast) + 1; for (int i = start, count = converterFactories.size(); i < count; i++) { // 獲取Converter 過程：（和獲取 callAdapter 基本一致） Converter<ResponseBody, ?> converter = converterFactories.get(i).responseBodyConverter(type, annotations, this); // 遍歷 Converter.Factory 集合並尋找合適的工廠（該工廠集合在構造 Retrofit 對象時進行添加（第一步時已經說明）） // 因爲構造Retroifit採用的是Gson解析方式，因此取出的是GsonResponseBodyConverter // Retrofit - Converters 還提供了 JSON，XML，ProtoBuf 等類型數據的轉換功能。 // 繼續看responseBodyConverter（） -->關注點5 } <-- 關注點5：responseBodyConverter（） --> @Override public Converter<ResponseBody, ?> responseBodyConverter(Type type, Annotation[] annotations, Retrofit retrofit) { TypeAdapter<?> adapter = gson.getAdapter(TypeToken.get(type)); // 根據目標類型，利用 Gson#getAdapter 獲取相應的 adapter return new GsonResponseBodyConverter<>(gson, adapter); } // 作數據轉換時調用 Gson 的 API 便可。 final class GsonResponseBodyConverter<T> implements Converter<ResponseBody, T> { private final Gson gson; private final TypeAdapter<T> adapter; GsonResponseBodyConverter(Gson gson, TypeAdapter<T> adapter) { this.gson = gson; this.adapter = adapter; } @Override public T convert(ResponseBody value) throws IOException { JsonReader jsonReader = gson.newJsonReader(value.charStream()); try { return adapter.read(jsonReader); } finally { value.close(); } } }

當選擇了RxjavaCallAdapterFactory後，Rxjava經過策略模式選擇對應的adapter

關於策略模式的講解，請看文章策略模式（Strategy Pattern）- 最易懂的設計模式解析
具體過程是：根據網絡接口方法的返回值類型來選擇具體要用哪一種CallAdapterFactory，而後建立具體的CallAdapter實例

採用工廠模式使得各功能模塊高度解耦

上面提到了兩種工廠：CallAdapter.Factory & Converter.Factory分別負責提供不一樣的功能模塊
工廠負責如何提供、提供何種功能模塊
Retrofit 只負責提供選擇何種工廠的決策信息（如網絡接口方法的參數、返回值類型、註解等）

這正是所謂的高內聚低耦合，工廠模式get。

關於工廠模式請看我寫的文章：
簡單工廠模式（SimpleFactoryPattern）- 最易懂的設計模式解析
 工廠方法模式（Factory Method）- 最易懂的設計模式解析
 抽象工廠模式（Abstract Factory）- 最易懂的設計模式解析

終於配置完網絡請求參數（即配置好ServiceMethod對象）。接下來將講解第二行代碼：okHttpCall對象的建立

第二行：`OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args);`

根據第一步配置好的ServiceMethod對象和輸入的請求參數建立okHttpCall對象

<--OkHttpCall類 -->
public class OkHttpCall { private final ServiceMethod<T> serviceMethod; // 含有全部網絡請求參數信息的對象 private final Object[] args; // 網絡請求接口的參數 private okhttp3.Call rawCall; //實際進行網絡訪問的類 private Throwable creationFailure; //幾個狀態標誌位 private boolean executed; private volatile boolean canceled; <--OkHttpCall構造函數 --> public OkHttpCall(ServiceMethod<T> serviceMethod, Object[] args) { // 傳入了配置好的ServiceMethod對象和輸入的請求參數 this.serviceMethod = serviceMethod; this.args = args; }

第三行：`return serviceMethod.callAdapter.adapt(okHttpCall);`

將第二步建立的OkHttpCall對象傳給第一步建立的serviceMethod對象中對應的網絡請求適配器工廠的adapt（）

返回對象類型：Android默認的是Call<>；若設置了RxJavaCallAdapterFactory，返回的則是Observable<>

<--  adapt（）詳解-->
public <R> Call<R> adapt(Call<R> call) { return new ExecutorCallbackCall<>(callbackExecutor, call); } ExecutorCallbackCall(Executor callbackExecutor, Call<T> delegate) { this.delegate = delegate; // 把上面建立並配置好參數的OkhttpCall對象交給靜態代理delegate // 靜態代理和動態代理都屬於代理模式 // 靜態代理做用：代理執行被代理者的方法，且可在要執行的方法先後加入本身的動做，進行對系統功能的拓展 this.callbackExecutor = callbackExecutor; // 傳入上面定義的回調方法執行器 // 用於進行線程切換 }

採用了裝飾模式：ExecutorCallbackCall = 裝飾者，而裏面真正去執行網絡請求的仍是OkHttpCall
使用裝飾模式的緣由：但願在OkHttpCall發送請求時作一些額外操做。這裏的額外操做是線程轉換，即將子線程切換到主線程
1. OkHttpCall的enqueue()是進行網絡異步請求的：當你調用OkHttpCall.enqueue（）時，回調的callback是在子線程中，須要經過Handler轉換到主線程進行回調。ExecutorCallbackCall就是用於線程回調；
2. 固然以上是原生Retrofit使用的切換線程方式。若是你用Rxjava，那就不會用到這個ExecutorCallbackCall而是RxJava的Call，此處不過多展開

步驟4講解：`Call<JavaBean> call = NetService.getCall();`

NetService對象其實是動態代理對象Proxy.newProxyInstance（）（步驟3中已說明），並非真正的網絡請求接口建立的對象
當NetService對象調用getCall（）時會被動態代理對象Proxy.newProxyInstance（）攔截，而後調用自身的InvocationHandler # invoke（）
invoke(Object proxy, Method method, Object... args)會傳入3個參數：Object proxy:（代理對象）、
Method method（調用的getCall()）
Object... args（方法的參數，即getCall（*）中的*）
接下來利用Java反射獲取到getCall（）的註解信息，配合args參數建立ServiceMethod對象。

如上面步驟3描述，此處再也不次講解

最終建立並返回一個OkHttpCall類型的Call對象
1. OkHttpCall類是 OkHttp的包裝類
2. 建立了 OkHttpCall類型的Call對象還不能發送網絡請求，須要建立 Request對象才能發送網絡請求

總結

Retrofit採用了外觀模式統一調用建立網絡請求接口實例和網絡請求參數配置的方法，具體細節是：

動態建立網絡請求接口的實例（代理模式 - 動態代理）
建立 serviceMethod 對象（建造者模式 & 單例模式（緩存機制））
對 serviceMethod 對象進行網絡請求參數配置：經過解析網絡請求接口方法的參數、返回值和註解類型，從Retrofit對象中獲取對應的網絡請求的url地址、網絡請求執行器、網絡請求適配器 & 數據轉換器。（策略模式）
對 serviceMethod 對象加入線程切換的操做，便於接收數據後經過Handler從子線程切換到主線程從而對返回數據結果進行處理（裝飾模式）
最終建立並返回一個OkHttpCall類型的網絡請求對象

3. 執行網絡請求

Retrofit默認使用OkHttp，即OkHttpCall類（實現了 retrofit2.Call<T>接口）

但能夠自定義選擇本身須要的Call類
OkHttpCall提供了兩種網絡請求方式：
1. 同步請求：OkHttpCall.execute()
2. 異步請求：OkHttpCall.enqueue()

下面將詳細介紹這兩種網絡請求方式。
對於OkHttpCall的enqueue（）、execute（）此處不往下分析，有興趣的讀者能夠看OkHttp的源碼

3.1 同步請求`OkHttpCall.execute()`

3.1.1 發送請求過程

步驟1：對網絡請求接口的方法中的每一個參數利用對應ParameterHandler進行解析，再根據ServiceMethod對象建立一個OkHttp的Request對象
步驟2：使用OkHttp的Request發送網絡請求；
步驟3：對返回的數據使用以前設置的數據轉換器（GsonConverterFactory）解析返回的數據，最終獲得一個Response<T>對象

3.1.2 具體使用

Response<JavaBean> response = call.execute();

上面簡單的一行代碼，其實包含了整個發送網絡同步請求的三個步驟。

3.1.3 源碼分析

@Override public Response<T> execute() throws IOException { okhttp3.Call call; // 設置同步鎖 synchronized (this) { call = rawCall; if (call == null) { try { call = rawCall = createRawCall(); // 步驟1：建立一個OkHttp的Request對象請求 -->關注1 } catch (IOException | RuntimeException e) { creationFailure = e; throw e; } } } return parseResponse(call.execute()); // 步驟2：調用OkHttpCall的execute()發送網絡請求（同步） // 步驟3：解析網絡請求返回的數據parseResponse（） -->關注2 } <-- 關注1：createRawCall() --> private okhttp3.Call createRawCall() throws IOException { Request request = serviceMethod.toRequest(args); // 從ServiceMethod的toRequest（）返回一個Request對象 okhttp3.Call call = serviceMethod.callFactory.newCall(request); // 根據serviceMethod和request對象建立 一個okhttp3.Request if (call == null) { throw new NullPointerException("Call.Factory returned null."); } return call; } <-- 關注2：parseResponse（）--> Response<T> parseResponse(okhttp3.Response rawResponse) throws IOException { ResponseBody rawBody = rawResponse.body(); rawResponse = rawResponse.newBuilder() .body(new NoContentResponseBody(rawBody.contentType(), rawBody.contentLength())) .build(); // 收到返回數據後進行狀態碼檢查 // 具體關於狀態碼說明下面會詳細介紹 int code = rawResponse.code(); if (code < 200 || code >= 300) { } if (code == 204 || code == 205) { return Response.success(null, rawResponse); } ExceptionCatchingRequestBody catchingBody = new ExceptionCatchingRequestBody(rawBody); try { T body = serviceMethod.toResponse(catchingBody); // 等Http請求返回後 & 經過狀態碼檢查後，將response body傳入ServiceMethod中，ServiceMethod經過調用Converter接口（以前設置的GsonConverterFactory）將response body轉成一個Java對象，即解析返回的數據 // 生成Response類 return Response.success(body, rawResponse); } catch (RuntimeException e) { ... // 異常處理 } }

特別注意：

ServiceMethod幾乎保存了一個網絡請求所須要的數據
發送網絡請求時，OkHttpCall須要從ServiceMethod中得到一個Request對象
解析數據時，還須要經過ServiceMethod使用Converter（數據轉換器）轉換成Java對象進行數據解析

爲了提升效率，Retrofit還會對解析過的請求ServiceMethod進行緩存，存放在Map<Method, ServiceMethod> serviceMethodCache = new LinkedHashMap<>();對象中，即第二步提到的單例模式
關於狀態碼檢查時的狀態碼說明：

以上即是整個以同步的方式發送網絡請求的過程。

3.2 異步請求`OkHttpCall.enqueue()`

3.2.1 發送請求過程

步驟1：對網絡請求接口的方法中的每一個參數利用對應ParameterHandler進行解析，再根據ServiceMethod對象建立一個OkHttp的Request對象
步驟2：使用OkHttp的Request發送網絡請求；
步驟3：對返回的數據使用以前設置的數據轉換器（GsonConverterFactory）解析返回的數據，最終獲得一個Response<T>對象
步驟4：進行線程切換從而在主線程處理返回的數據結果

若使用了RxJava，則直接回調到主線程

異步請求的過程跟同步請求相似， 惟一不一樣之處在於：異步請求會將回調方法交給回調執行器在指定的線程中執行。
指定的線程此處是指主線程（UI線程）

3.2.2 具體使用

call.enqueue(new Callback<JavaBean>() { @Override public void onResponse(Call<JavaBean> call, Response<JavaBean> response) { System.out.println(response.isSuccessful()); if (response.isSuccessful()) { response.body().show(); } else { try { System.out.println(response.errorBody().string()); } catch (IOException e) { e.printStackTrace(); } ; } }

從上面分析有：call是一個靜態代理
使用靜態代理的做用是：在okhttpCall發送網絡請求的先後進行額外操做

這裏的額外操做是：線程切換，即將子線程切換到主線程，從而在主線程對返回的數據結果進行處理

3.2.3 源碼分析

<--  call.enqueue（）解析  -->
@Override public void enqueue(final Callback<T> callback) { delegate.enqueue(new Callback<T>() { // 使用靜態代理 delegate進行異步請求 ->>分析1 // 等下記得回來 @Override public void onResponse(Call<T> call, final Response<T> response) { // 步驟4：線程切換，從而在主線程顯示結果 callbackExecutor.execute(new Runnable() { // 最後Okhttp的異步請求結果返回到callbackExecutor // callbackExecutor.execute（）經過Handler異步回調將結果傳回到主線程進行處理（如顯示在Activity等等），即進行了線程切換 // 具體是如何作線程切換 ->>分析2 @Override public void run() { if (delegate.isCanceled()) { callback.onFailure(ExecutorCallbackCall.this, new IOException("Canceled")); } else { callback.onResponse(ExecutorCallbackCall.this, response); } } }); } @Override public void onFailure(Call<T> call, final Throwable t) { callbackExecutor.execute(new Runnable() { @Override public void run() { callback.onFailure(ExecutorCallbackCall.this, t); } }); } }); } <-- 分析1：delegate.enqueue（）解析 --> @Override public void enqueue(final Callback<T> callback) { okhttp3.Call call; Throwable failure; // 步驟1：建立OkHttp的Request對象，再封裝成OkHttp.call // delegate代理在網絡請求前的動做：建立OkHttp的Request對象，再封裝成OkHttp.call synchronized (this) { if (executed) throw new IllegalStateException("Already executed."); executed = true; call = rawCall; failure = creationFailure; if (call == null && failure == null) { try { call = rawCall = createRawCall(); // 建立OkHttp的Request對象，再封裝成OkHttp.call // 方法同發送同步請求，此處不做過多描述 } catch (Throwable t) { failure = creationFailure = t; } } // 步驟2：發送網絡請求 // delegate是OkHttpcall的靜態代理 // delegate靜態代理最終仍是調用Okhttp.enqueue進行網絡請求 call.enqueue(new okhttp3.Callback() { @Override public void onResponse(okhttp3.Call call, okhttp3.Response rawResponse) throws IOException { Response<T> response; try { // 步驟3：解析返回數據 response = parseResponse(rawResponse); } catch (Throwable e) { callFailure(e); return; } callSuccess(response); } @Override public void onFailure(okhttp3.Call call, IOException e) { try { callback.onFailure(OkHttpCall.this, e); } catch (Throwable t) { t.printStackTrace(); } } private void callFailure(Throwable e) { try { callback.onFailure(OkHttpCall.this, e); } catch (Throwable t) { t.printStackTrace(); } } private void callSuccess(Response<T> response) { try { callback.onResponse(OkHttpCall.this, response); } catch (Throwable t) { t.printStackTrace(); } } }); } // 請回去上面分析1的起點 <-- 分析2：異步請求後的線程切換--> // 線程切換是經過一開始建立Retrofit對象時Platform在檢測到運行環境是Android時進行建立的：（以前已分析過） // 採用適配器模式 static class Android extends Platform { // 建立默認的回調執行器工廠 // 若是不將RxJava和Retrofit一塊兒使用，通常都是使用該默認的CallAdapter.Factory // 後面會對RxJava和Retrofit一塊兒使用的狀況進行分析 @Override CallAdapter.Factory defaultCallAdapterFactory(Executor callbackExecutor) { return new ExecutorCallAdapterFactory(callbackExecutor); } @Override public Executor defaultCallbackExecutor() { // 返回一個默認的回調方法執行器 // 該執行器負責在主線程（UI線程）中執行回調方法 return new MainThreadExecutor(); } // 獲取主線程Handler static class MainThreadExecutor implements Executor { private final Handler handler = new Handler(Looper.getMainLooper()); @Override public void execute(Runnable r) { // Retrofit獲取了主線程的handler // 而後在UI線程執行網絡請求回調後的數據顯示等操做。 handler.post(r); } } // 切換線程的流程： // 1. 回調ExecutorCallAdapterFactory生成了一個ExecutorCallbackCall對象 // 2. 經過調用ExecutorCallbackCall.enqueue(CallBack)從而調用MainThreadExecutor的execute()經過handler切換到主線程處理返回結果（如顯示在Activity等等） }