Retrofit 入門
相信對於retrofit而言，很多人都知道如何用，網上也有很多文章介紹使用retrofit。而對於它的原理，簡直跟它的名字一樣，不相上下，介紹使用它的文章更是數不勝數，就是基於動態代理，也爲我們對於動態代理的應用提供了一個新思路，這裏是對retrofit實現的分析，也會提及它的動態代理部分，下面就是藉着retrofit的分析，來重新瞭解retrofit的設計部分,分成三個部分來進行分析：
1.【Retrofit三步走：流程梳理篇】
2.【Retrofit三步走：request篇】
3.【Retrofit三步走：Response篇】
準備部分
注：這裏使用的retrofit2.6.0版本
引用爲：implementation ‘com.squareup.retrofit2:retrofit:2.6.0’
對於Retrofit的使用，相信大家都很熟悉，我們先看看我們如何使用Retrofit
Retrofit retrofit = new Retrofit.Builder()
.baseUrl("http://www.test.com/") //設置網絡請求的Url地址
.addConverterFactory(GsonConverterFactory.create()) //設置數據解析器
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.build();
retrofit.create(某.class);
相信大多都是如此書寫，那我們就先從Retrofit的Builder中開始分析,着重瞭解retrofit對Request請求的一個構造
首先Builder當中就是我們提供的外部配置信息，像我們傳入的GsonConverterFactory和RxJavaCallAdapterFactory分別存放在covertFactories和calladapterFactories中
我們看看我們引入的三方支持包GsonConverterFactory和RxJavaCallAdapterFactory
GsonConverterFactory:
RxJavaCallAdapterFactory:
這兩個factory是我們整個網絡的關鍵類,我們隨後在response篇去詳細分析它們
接下來就剩下我們retrofit的入口方法create()，我們這篇也就順着create來完成對retrofit的Request篇的分析
retrofit的create前半部分的方法如下：
public <T> T create(final Class<T> service) {
首先是對我們目標的接口service進行驗證是否合法
Utils.validateServiceInterface(service);
if (validateEagerly) {
eagerlyValidateMethods(service);
}
}
具體的合法驗證規則如下：
validateServiceInterface的方法：
static <T> void validateServiceInterface(Class<T> service) {
if (!service.isInterface()) {
throw new IllegalArgumentException("API declarations must be interfaces.");
}
if (service.getInterfaces().length > 0) {
throw new IllegalArgumentException("API interfaces must not extend other interfaces.");
}
}
這個合法驗證就是驗證我們傳遞的參數必須爲一個接口且這個接口不可以有繼承，否則就時非法直接拋出異常
緊跟着後面進行一個validateEagerly對我們的method進行有效形驗證的判斷，當validateEagerly爲true時，進行eagerlyValidateMethods這個方法：
之所以把eagerlyValidateMethods和loadServiceMethod兩個方法連在一起分析，從loadServiceMethod方法中的serviceMethodCache可以看着這裏做了預處理操作內部存放了我們要處理的接口數據class
故對於validateEagerly的作用也很清晰了，就是是否對我們目標的類，進行預處理操作
到這裏，對於Retrofit這個類的龐大的build模塊相關部分就到這裏了
核心部分
retrofit最主要的實現位置是動態代理這部分，也就是create的返回值部分，如下
在動態代理的這部分，分成三部分
第一部分是容錯處理部分，即對Object類型的正常調用的返回以及不同平臺的處理;
好比isDefaultMethod的處理,就是應對 Java8 中 的 default 方法處理即判斷該方法對象是否爲默認方法;對於這個不同平臺可能會有人覺得有問題，其實在這個Platform類中有兩個內部類：
即Android/IOS兩個內部類處理，然後把主線程就放在了這兩個內部類裏面，Android裏面通過Looper.getMainLooper()方法來放置MainThreadExecutor，而IOS這裏，則放置的一個"org.robovm.apple.foundation.NSOperationQueue"的一個東西來做MainThreadExecutor，對與NSOperationQueue是蘋果提供的一套多線程處理方案,而robovm是一個已經商用的RoboVM 編譯器,Robovm可以編譯java代碼並有iOS一整套的轉化代碼來橋接，有興趣的朋友可以自行去研究，這裏僅貼出代碼:
Robovm地址:https://github.com/robovm/robovm
第二部分是預處理部分殊途同歸的方法loadServiceMethod方法;
這部分是對request組成【request分析篇】和response的組成【response分析篇】結構處理部分，我們放在兩個篇章詳細分析
對應篇章鏈接地址：【request分析篇】【response分析篇】
最後一部分就是藉助okhttp發起請求
最後這部分是結合okhttp串連之前的request和response，從而完成網絡請求的發起和處理，我們放在response裏來詳細贅述