如何從設計模式看OkHttp源碼

今天就跟大家聊聊有關如何從設計模式看OkHttp源碼，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

使用

讀源碼，首先就要從它的使用方法開始：

val okHttpClient = OkHttpClient()    val request: Request = Request.Builder()        .url(url)        .build()    okHttpClient.newCall(request).enqueue(object : Callback {        override fun onFailure(call: Call, e: IOException) {            Log.d(TAG, "onFailure: ")        }         override fun onResponse(call: Call, response: Response) {            Log.d(TAG, "onResponse: " + response.body?.string())        }    })

從這個使用方法來看，我抽出了四個重要信息：

• okHttpClient

• Request

• newCall(request)

• enqueue(Callback)

大體意思我們可以先猜猜看：

配置一個客戶端實例okHttpClient和一個Request請求，然后這個請求通過okHttpClient的newCall方法封裝，最后用enqueue方法發送出去，并收到Callback響應。

接下來就一個個去認證，并找找其中的設計模式。

okHttpClient

首先看看這個okhttp的客戶端對象，也就是okHttpClient。

OkHttpClient client = new OkHttpClient.Builder()         .addInterceptor(new HttpLoggingInterceptor())          .readTimeout(500, TimeUnit.MILLISECONDS)         .build();

在這里，我們實例化了一個HTTP的客戶端client，然后配置了它的一些參數，比如攔截器、超時時間。

這種我們通過一個統一的對象，調用一個接口或方法，就能完成我們的需求，而起內部的各種復雜對象的調用和跳轉都不需要我們關心的設計模式就是外觀模式(門面模式)。

外觀模式(Facade  Pattern)隱藏系統的復雜性，并向客戶端提供了一個客戶端可以訪問系統的接口。這種類型的設計模式屬于結構型模式，它向現有的系統添加一個接口，來隱藏系統的復雜性。

其重點就在于系統內部和各個子系統之間的復雜關系我們不需要了解，只需要去差遣這個門面 就可以了，在這里也就是OkHttpClient。

它的存在就像一個接待員，我們告訴它我們的需求，要做的事情。然后接待員去內部處理，各種調度，最終完成。

外觀模式主要解決的就是降低訪問復雜系統的內部子系統時的復雜度，簡化客戶端與之的接口。

這個模式也是三方庫很常用的設計模式，給你一個對象，你只需要對這個對象使喚，就可以完成需求。

當然，這里還有一個比較明顯的設計模式是建造者模式，下面會說到。

Request

val request: Request = Request.Builder()     .url(url)     .build()  //Request.kt open class Builder {     internal var url: HttpUrl? = null     internal var method: String     internal var headers: Headers.Builder     internal var body: RequestBody? = null      constructor() {       this.method = "GET"       this.headers = Headers.Builder()     }      open fun build(): Request {       return Request(           checkNotNull(url) { "url == null" },           method,           headers.build(),           body,           tags.toImmutableMap()       )     } }

從Request的生成代碼中可以看到，用到了其內部類Builder，然后通過Builder類組裝出了一個完整的有著各種參數的Request類。

這也就是典型的 建造者(Builder)模式 。

建造者(Builder)模式，將一個復雜的對象的構建與它的表示分離，是的同樣的構建過程可以創建不同的表示。

我們可以通過Builder，構建了不同的Request請求，只需要傳入不同的請求地址url，請求方法method，頭部信息headers，請求體body即可。(這也就是網絡請求中的請求報文的格式)

這種可以通過構建形成不同的表示的 設計模式 就是 建造者模式，也是用的很多，主要為了方便我們傳入不同的參數進行構建對象。

又比如上面okHttpClient的構建。

newCall(request)

接下來是調用OkHttpClient類的newCall方法獲取一個可以去調用enqueue方法的接口。

//使用 val okHttpClient = OkHttpClient() okHttpClient.newCall(request)  //OkHttpClient.kt open class OkHttpClient internal constructor(builder: Builder) : Cloneable, Call.Factory, WebSocket.Factory {   override fun newCall(request: Request): Call = RealCall(this, request, forWebSocket = false) }  //Call接口 interface Call : Cloneable {   fun execute(): Response    fun enqueue(responseCallback: Callback)    fun interface Factory {     fun newCall(request: Request): Call   } }

newCall方法，其實是Call.Factory接口里面的方法。

也就是創建Call的過程，是通過Call.Factory接口的newCall方法創建的，而真正實現這個方法交給了這個接口的子類OkHttpClient。

那這種定義了統一創建對象的接口，然后由子類來決定實例化這個對象的設計模式就是 工廠模式。

在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，并且是通過使用一個共同的接口來指向新創建的對象。

當然，okhttp這里的工廠有點小，只有一條生產線，就是Call接口，而且只有一個產品，RealCall。

enqueue(Callback)

接下來這個方法enqueue，肯定就是okhttp源碼的重中之重了，剛才說到newCall方法其實是獲取了RealCall對象，所以就走到了RealCall的enqueue方法：

override fun enqueue(responseCallback: Callback) {   client.dispatcher.enqueue(AsyncCall(responseCallback)) }

再轉向dispatcher。

//Dispatcher.kt    val executorService: ExecutorService     get() {       if (executorServiceOrNull == null) {         executorServiceOrNull = ThreadPoolExecutor(0, Int.MAX_VALUE, 60, TimeUnit.SECONDS,             SynchronousQueue(), threadFactory("$okHttpName Dispatcher", false))       }       return executorServiceOrNull!!     }     internal fun enqueue(call: AsyncCall) {     promoteAndExecute()   }     private fun promoteAndExecute(): Boolean {     //通過線程池切換線程     for (i in 0 until executableCalls.size) {       val asyncCall = executableCalls[i]       asyncCall.executeOn(executorService)     }      return isRunning   }   //RealCall.kt   fun executeOn(executorService: ExecutorService) {        try {         executorService.execute(this)         success = true       }      }

這里用到了一個新的類Dispatcher，調用到的方法是asyncCall.executeOn(executorService)

這個executorService參數大家應該都熟悉吧，線程池。最后是調用executorService.execute方法執行線程池任務。

而線程池的概念其實也是用到了一種設計模式，叫做享元模式。

享元模式(Flyweight  Pattern)主要用于減少創建對象的數量，以減少內存占用和提高性能。這種類型的設計模式屬于結構型模式，它提供了減少對象數量從而改善應用所需的對象結構的方式。

其核心就在于共享對象，所有很多的池類對象，比如線程池、連接池等都是采用了享元模式  這一設計模式。當然，okhttp中不止是有線程池，還有連接池提供連接復用，管理所有的socket連接。

再回到Dispatcher，所以這個類是干嘛的呢?就是切換線程用的，因為我們調用的enqueue是異步方法，所以最后會用到線程池切換線程，執行任務。

繼續看看execute(this)中的this任務。

execute(this)

override fun run() {       threadName("OkHttp ${redactedUrl()}") {         try {           //獲取響應報文，并回調給Callback           val response = getResponseWithInterceptorChain()           responseCallback.onResponse(this@RealCall, response)         } catch (e: IOException) {           if (!signalledCallback) {             responseCallback.onFailure(this@RealCall, e)           }          } catch (t: Throwable) {           cancel()           if (!signalledCallback) {                          responseCallback.onFailure(this@RealCall, canceledException)           }         }        }

沒錯，這里就是請求接口的地方了，通過getResponseWithInterceptorChain方法獲取響應報文response，然后通過Callback的onResponse方法回調，或者是有異常就通過onFailure方法回調。

那同步方法是不是就沒用到線程池呢?去找找execute方法：

override fun execute(): Response {   //...   return getResponseWithInterceptorChain() }

果然，通過execute方法就直接返回了getResponseWithInterceptorChain，也就是響應報文。

到這里，okhttp的大體流程就結束了，這部分的流程大概就是：

設置請求報文 -> 配置客戶端參數 -> 根據同步或異步判斷是否用子線程 -> 發起請求并獲取響應報文 ->  通過Callback接口回調結果

剩下的內容就全部在getResponseWithInterceptorChain方法中，這也就是okhttp的核心。

getResponseWithInterceptorChain

internal fun getResponseWithInterceptorChain(): Response {     // Build a full stack of interceptors.     val interceptors = mutableListOf<Interceptor>()     interceptors += client.interceptors     interceptors += RetryAndFollowUpInterceptor(client)     interceptors += BridgeInterceptor(client.cookieJar)     interceptors += CacheInterceptor(client.cache)     interceptors += ConnectInterceptor     if (!forWebSocket) {       interceptors += client.networkInterceptors     }     interceptors += CallServerInterceptor(forWebSocket)      val chain = RealInterceptorChain(         interceptors = interceptors         //...     )      val response = chain.proceed(originalRequest)   }

代碼不是很復雜，就是 加加加 攔截器，然后組裝成一個chain類，調用proceed方法，得到響應報文response。

override fun proceed(request: Request): Response {    //找到下一個攔截器   val next = copy(index = index + 1, request = request)   val interceptor = interceptors[index]      val response = interceptor.intercept(next)   return response }

簡化了下代碼，主要邏輯就是獲取下一個攔截器(index+1)，然后調用攔截器的intercept方法。

然后在攔截器里面的代碼統一都是這種格式：

override fun intercept(chain: Interceptor.Chain): Response {    //做事情A     response = realChain.proceed(request)     //做事情B  }

結合兩段代碼，會形成一條鏈，這條鏈組織了所有連接器的工作。類似這樣：

攔截器1做事情A -> 攔截器2做事情A -> 攔截器3做事情A -> 攔截器3做事情B -> 攔截器2做事情B ->  攔截器1做事情B

應該是好理解的吧，通過proceed方法把每個攔截器連接起來了。

而最后一個攔截器ConnectInterceptor就是分割事情A和事情B，其作用就是進行真正的與服務器的通信，向服務器發送數據，解析讀取的響應數據。

所以事情A和事情B是什么意思呢?其實就代表了通信之前的事情和通信之后的事情。

再來個動畫：

這種思想是不是有點像..遞歸?沒錯，就是遞歸，先遞進執行事情A，再回歸做事情B。

而這種遞歸循環，其實也就是用到了設計模式中的 責任鏈模式。

責任鏈模式(Chain of Responsibility  Pattern)為請求創建了一個接收者對象的鏈。這種模式給予請求的類型，對請求的發送者和接收者進行解耦。

簡單的說，就是讓每個對象都能有機會處理這個請求，然后各自完成自己的事情，一直到事件被處理。Android中的事件分發機制也是用到了這種設計模式。

接下來就是了解每個攔截器到底做了什么事，就可以了解到okhttp的整個流程了，這就是下期的內容了。

先預告一波：

• addInterceptor(Interceptor)，這是由開發者設置的，會按照開發者的要求，在所有的攔截器處理之前進行最早的攔截處理，比如一些公共參數，Header都可以在這里添加。

• RetryAndFollowUpInterceptor，這里會對連接做一些初始化工作，以及請求失敗的重試工作，重定向的后續請求工作。

• BridgeInterceptor，這里會為用戶構建一個能夠進行網絡訪問的請求，同時后續工作將網絡請求回來的響應Response轉化為用戶可用的Response，比如添加文件類型，content-length計算添加，gzip解包。

• CacheInterceptor，這里主要是處理cache相關處理，會根據OkHttpClient對象的配置以及緩存策略對請求值進行緩存，而且如果本地有了可?的Cache，就可以在沒有網絡交互的情況下就返回緩存結果。

• ConnectInterceptor，這里主要就是負責建立連接了，會建立TCP連接或者TLS連接，以及負責編碼解碼的HttpCodec。

• networkInterceptors，這里也是開發者自己設置的，所以本質上和第一個攔截器差不多，但是由于位置不同，用處也不同。這個位置添加的攔截器可以看到請求和響應的數據了，所以可以做一些網絡調試。

• CallServerInterceptor，這里就是進行網絡數據的請求和響應了，也就是實際的網絡I/O操作，通過socket讀寫數據。

看完上述內容，你們對如何從設計模式看OkHttp源碼有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。