從設計模式角度看OkHttp原始碼

jimuzz發表於2021-03-16
設計模式HTTP原始碼

前言

說到原始碼，很多朋友都覺得複雜，難理解。

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

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小夥伴，歡迎大家加入～

相關文章