Android：這是一份全面 & 詳細的Retrofit 2.0 原始碼分析指南

Carson_Ho發表於2018-03-07

Android原始碼

前言

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

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

請儘量在PC端而不要在移動端看，否則圖片可能看不清。

在閱讀本文前，建議先閱讀文章：這是一份很詳細的 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地址

3. Retrofit 的具體使用

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

4. 原始碼分析

4.1 Retrofit的本質流程

一般從網路通訊過程如下圖：

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

如下圖：

具體過程解釋如下：

通過解析網路請求介面的註解配置網路請求引數
通過動態代理生成網路請求物件
通過網路請求介面卡將網路請求物件進行平臺適配

平臺包括：Android、Rxjava、Guava和java8

通過網路請求執行器傳送網路請求
通過資料轉換器解析伺服器返回的資料
通過回撥執行器切換執行緒（子執行緒 ->>主執行緒）
使用者在主執行緒處理返回結果

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

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

4.2 原始碼分析

先來回憶Retrofit的使用步驟：

建立Retrofit例項
建立網路請求介面例項並配置網路請求引數
傳送網路請求

封裝了資料轉換、執行緒切換的操作

處理伺服器返回的資料

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(）後又放入了一個GsonConverterFactory
  public 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. 代理模式

代理模式：通過訪問代理物件的方式來間接訪問目標物件

分為靜態代理 & 動態代理：

靜態代理：代理類在程式執行前已經存在的代理方式

動態代理：代理類在程式執行前不存在、執行時由程式動態生成的代理方式具體請看文章代理模式（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傳送請求時做一些額外操作。這裡的額外操作是執行緒轉換，即將子執行緒切換到主執行緒

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物件

OkHttpCall類是OkHttp的包裝類

建立了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等等）
  }

複製程式碼

以上便是整個以非同步方式傳送網路請求的過程。

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的安卓開發筆記

請點贊！因為你的鼓勵是我寫作的最大動力！

Android：這是一份全面 & 詳細的圖片載入庫Glide原始碼分析
2018-03-21
AndroidIDE原始碼
Java：這是一份詳細&全面的HashMap 1.7 原始碼分析
2018-03-14
JavaHashMap原始碼
這是一份全面 & 詳細的Android多執行緒知識總結指南
2019-06-26
Android執行緒
Retrofit2.0- 原始碼分析
2018-09-01
原始碼
這是一份全面 & 詳細的Google序列化神器protocolBuffer 學習指南
2019-03-04
GoProtocol
Android 動畫：這是一份詳細 & 清晰的動畫學習指南
2018-05-03
Android動畫
Android Retrofit原始碼解析：都能看懂的Retrofit使用詳解
2021-10-14
Android原始碼
Android技能樹 — 網路小結(7)之 Retrofit原始碼詳細解析
2018-12-24
Android原始碼
Android RxJava：這是一份全面的操作符使用匯總（含詳細例項講解）
2018-05-31
AndroidRxJava
retrofit 原始碼分析
2019-01-19
原始碼
Retrofit原始碼分析
2020-11-08
原始碼
Retrofit原始碼分析三原始碼分析
2018-05-17
原始碼
Android Retrofit原始碼解析
2019-03-01
Android原始碼
計算機網路基礎：這是一份詳細 HTTP 學習指南
2018-08-28
計算機網路HTTP
[Android] Retrofit原始碼：流程解析
2019-03-22
Android原始碼
計算機網路：這是一份全面& 詳細 HTTP協議學習攻略
2019-03-25
計算機網路HTTP協議
Android主流三方庫原始碼分析（二、深入理解Retrofit原始碼）
2020-01-16
Android原始碼
可能是全網最全最新最細的 webpack-tapable-2.0 的原始碼分析
2019-03-02
Web原始碼
Android RxJava：這是一份RxJava使用入門學習指南
2018-06-09
AndroidRxJava
Android 網路框架 Retrofit 原始碼解析
2019-03-03
Android框架原始碼
原始碼分析Retrofit請求流程
2018-11-04
原始碼
Retrofit原始碼分析二代理模式
2018-04-17
原始碼模式
Retrofit原始碼分析一概覽
2018-04-17
原始碼
好嗨詳細的vuex原始碼分析之API 是如何實現
2018-10-22
Vue原始碼API
Android O 適配詳細指南
2019-03-04
Android
Android進階必學retrofit原始碼解析
2018-11-28
Android原始碼
Android網路程式設計：Retrofit原始碼解析
2019-03-22
Android程式設計原始碼
Laravel 原始碼方法執行類詳細分析
2018-12-19
Laravel原始碼
Android WebView：這是一份詳細 & 易懂的WebView學習攻略（含與JS互動、快取構建等）
2019-03-03
AndroidWebViewJS快取
Android 原始碼分析之 AsyncTask 原始碼分析
2019-03-04
Android原始碼
網路基礎|送你一份詳細HTTP學習指南
2018-09-10
HTTP
Laravel 原始碼環境檢測類詳細分析
2018-12-15
Laravel原始碼
4.這是一份Flutter常用Widget指南
2019-03-19
Flutter
Android進階：三、這一次，我們用最詳細的方式解析Android訊息機制的原始碼
2019-04-24
Android原始碼
Android：Retrofit 2.0 使用攻略（含例項講解）
2018-04-09
Android
Android 原始碼分析之 EventBus 的原始碼解析
2018-08-06
Android原始碼
java集合梳理【10】— Vector超級詳細原始碼分析
2020-11-08
Java原始碼
【UGUI原始碼分析】Unity遮罩之Mask詳細解讀
2021-08-12
UGUI原始碼Unity遮罩