前言

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

• 今天，我將手把手帶你深入剖析Retrofit v2.0的源碼，希望你們會喜歡

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

---

目錄

---

1. 簡介

特別注意：

• 準確來說，Retrofit 是一個 RESTful 的 HTTP 網絡請求框架的封裝。
• 原因：網絡請求的工作本質上是 OkHttp 完成，而 Retrofit 僅負責 網絡請求接口的封裝

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

---

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

除了Retrofit，如今Android中主流的網絡請求框架有：

• Android-Async-Http
• Volley
• OkHttp

下面是簡單介紹：

一圖讓你了解全部的網絡請求庫和他們之間的區別！

---

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

• Android-Async-Http
• Volley
• OkHttp
• Retrofit

---

3. Retrofit 的具體使用

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

---

4. 源碼分析

4.1 Retrofit的本質流程

一般從網絡通信過程如下圖：

• 其實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）的適配器

• Call在Retrofit里默認是OkHttpCall
• 在Retrofit中提供了四種CallAdapterFactory： ExecutorCallAdapterFactory（默認）、GuavaCallAdapterFactory、Java8CallAdapterFactory、RxJavaCallAdapterFactory

• 作用：將默認的網絡請求執行器（OkHttpCall）轉換成適合被不同平臺來調用的網絡請求執行器形式

• 如：一開始Retrofit只打算利用OkHttpCall通過ExecutorCallbackCall切換線程；但后來發現使用Rxjava更加方便（不需要Handler來切換線程）。想要實現Rxjava的情況，那就得使用RxJavaCallAdapterFactoryCallAdapter將OkHttpCall轉換成Rxjava(Scheduler)：

// 把response封裝成rxjava的Observeble，然后進行流式操作 Retrofit.Builder.addCallAdapterFactory(newRxJavaCallAdapterFactory().create()); // 關于RxJava的使用這里不作更多的展開

?

Retrofit還支持java8、Guava平臺。

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

所以，接下來需要分析的步驟2、步驟3、步驟4、步驟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（看完步驟2、3、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(）后又放入了一個GsonConverterFactorypublic Builder addConverterFactory(Converter.Factory factory) {converterFactories.add(checkNotNull(factory, "factory == null")); return this; }

?

• 至此，分析完畢
• 總結：步驟4用于創建一個含有Gson對象實例的GsonConverterFactory并放入到數據轉換器工廠converterFactories里
  
• 即Retrofit默認使用Gson進行解析
• 若使用其他解析方式（如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（）方法創建網絡請求接口的實例（同時，通過網絡請求接口里設置的注解進行了網絡請求參數的配置）
  
• 外觀模式：定義一個統一接口，外部與通過該統一的接口對子系統里的其他接口進行訪問。具體請看：外觀模式（Facade Pattern） - 最易懂的設計模式解析
• 代理模式：通過訪問代理對象的方式來間接訪問目標對象。具體請看：代理模式（Proxy Pattern）- 最易懂的設計模式解析
• 下面主要分析步驟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對象中獲取對應的網絡請求適配器 -->關注點1responseType = 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發送請求時做一些額外操作。這里的額外操作是線程轉換，即將子線程切換到主線程
  
• OkHttpCall的enqueue()是進行網絡異步請求的：當你調用OkHttpCall.enqueue（）時，回調的callback是在子線程中，需要通過Handler轉換到主線程進行回調。ExecutorCallbackCall就是用于線程回調；
• 當然以上是原生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提供了兩種網絡請求方式：
  
• 同步請求：OkHttpCall.execute()
• 異步請求：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();

• 1

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

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>() {@Overridepublic 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等等） }

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

---

5. 總結

Retrofit 本質上是一個 RESTful 的HTTP 網絡請求框架的封裝，即通過 大量的設計模式 封裝了 OkHttp ，使得簡潔易用。具體過程如下：

Retrofit 將 Http請求 抽象 成 Java接口

在接口里用 注解 描述和配置 網絡請求參數

用動態代理 的方式，動態將網絡請求接口的注解 解析 成HTTP請求

最后執行HTTP請求

最后貼一張非常詳細的Retrofit源碼分析圖：

6. 最后

• 看完本文，相信你已經非常熟悉 Retrofit 2.0 的源碼分析
• 關于Retrofit 2.0的詳細使用教程，請看文章這是一份很詳細的 Retrofit 2.0 使用教程（含實例講解）
• 接下來，我將繼續分析與 Retrofit 配合使用的 RxJava，有興趣可以繼續關注Carson_Ho的安卓開發筆記

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Android：手把手带你深入剖析 Retrofit 2.0 源码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。