Retrofit原始碼分析一 概覽

• Retrofit的本質和與Okhttp的關係 ​ 說到Retrofit，免不了要提起Okhttp，因為二者通常是繫結到一起使用的。那麼我們首先要明確一點Retrofit並不是一個網路請求框架，而是一個對網路請求框架（也就是Okhttp）的封裝。二者都是Squire公司的開源框架，Retrofit並不能脫離OKhttp，因為底層的網路訪問是由Okhttp來實現的。說到對網路請求的封裝，這裡小夥伴們可能會有一些疑問，什麼叫做對網路請求的封裝？這裡我們先簡單的貼一些程式碼來看一下

    //登入
    @FormUrlEncoded
    @POST("${BuildConfig.EXTRA_URL}account/login.do")
    fun login(@Field("username") userName: String, @Field("password") pwd: String, @Field("clientType") clientType: Int): Observable<HttpResultEntity<UserEntity>>
複製程式碼

在上面這個Kotlin編寫的的網路請求方法中，@FormUrlEncoded、@POST("${BuildConfig.EXTRA_URL}account/login")、 @Field("username")、@Field( "password") 、@Field("clientType")、Observable<HttpResultEntity> 這些都是對網路請求的封裝。這裡需要知道的是，對網路請求的封裝包括兩個方面：1. 對請求引數的封裝；2. 對網路返回結果的封裝。上面列出來的幾項中除了Observable<HttpResultEntity> 之外都是對請求引數的封裝，即使是對Retrofit不太瞭解的同學應該也是可以很輕鬆的看懂一些引數代表的意義，比如**@POST代表這個網路請求採用post方式，@Field("username")代表post請求域中要包含一個username的請求引數。而與之相對應的Observable<HttpResultEntity>**就是對網路返回結果的封裝，對Rxjava瞭解的同學應該明白，Retrofit把網路返回的原始資料包裝成了一個Observable，便於我們的開發。

• Retrofit流程分析 Retrofit的流程圖如下所示

  

  關於更加詳細的流程我們之後的章節會進行分析，大家先看個大概，心裡有個印象就行。等我們對整個Retrofit的原始碼分析結束之後，相信大家對這幅圖會有更加深入的認知。