從設計模式角度看OkHttp源碼

前言

說到源碼，很多朋友都覺得復雜，難理解。

但是，如果是一個結構清晰且完全解耦的優質源碼庫呢？

OkHttp就是這樣一個存在，對於這個原生網絡框架，想必大家也看過很多很多相關的源碼解析了。

它的源碼好看，易讀，清晰，所以今天我准備從設計模式的角度再來讀一遍 OkHttp的源碼。

主要內容就分為兩類：

• okhttp的基本運作流程
• 涉及到的設計模式

（本文源碼版本為okhttp:4.9.0，攔截器會放到下期再講）

使用

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

	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的源碼，感覺就一個字：舒服。

一份好的代碼應該就是這樣，各模塊之間通過各種設計模式進行解耦，閱讀者可以每個模塊分別去去閱讀了解，而不是各個模塊纏綿在一起，雜亂無章。

最后再總結下okhttp中涉及到的設計模式：

• 外觀模式。通過okHttpClient這個外觀去實現內部各種功能。
• 建造者模式。構建不同的Request對象。
• 工廠模式。通過OkHttpClient生產出產品RealCall。
• 享元模式。通過線程池、連接池共享對象。
• 責任鏈模式。將不同功能的攔截器形成一個鏈。

其實還是有一些設計模式沒說到的，比如

• websocket相關用到的觀察者模式。
• Cache集合相關的迭代器模式。

以后遇到了再做補充吧。

參考

https://www.runoob.com/design-pattern/design-pattern-tutorial.html
https://www.jianshu.com/p/ae2fe5481994
https://juejin.cn/post/6895369745445748749

拜拜

感謝大家的閱讀，有一起學習的小伙伴可以關注下我的公眾號——碼上積木❤️❤️
每日一個知識點，積少成多，建立知識體系架構。
這里有一群很好的Android小伙伴，歡迎大家加入～