本文來探究一下 OkHttp3 的源碼和其中的設計思想。

關於 OkHttp3 的源碼分析的文章挺多，不過大多還是在為了源碼而源碼。個人覺得如果讀源碼不去分析源碼背後的設計模式或設計思想，那麼讀源碼的意義不大。 同時，如果熟悉的設計模式越多，那麼讀某個框架的源碼的時候就越容易，兩者是相輔相成的，這也是許多大牛認為多讀源碼能提高編程能力的原因。

整體架構

為了方面後面的理解，我這裡簡單畫了個架構圖，圖中畫出了 OkHttp3 核心的功能模塊。為了方便整體理解，這裡分了三個層次： 客戶層、執行層和連接層。

首先，客戶層的OkHttpClient ，使用過 OkHttp 網絡庫的同學應該都熟悉，在發送網絡請求，執行層決定怎麼處理請求，比如同步還是異步，同步請求的話直接在當前線程完成請求， 請求要經過多層攔截器處理； 如果是異步處理，需要 Dispatcher 執行分發策略， 線程池管理執行任務； 又比如，一個請求下來，要不要走緩存，如果不走緩存，進行網絡請求。最後執行層將從連接層進行網絡 IO 獲取數據。

OkHttpClient

使用過 OkHttp 網絡庫的同學應該都熟悉 OkHttpClient ， 許多第三方框架都會提供一個類似的類作為客戶訪問的一個入口。 關於 OkHttpClient 代碼註釋上就說的很清楚：

1. 
   
2. /**
3. * Factory for {@linkplain Call calls}, which can be used to send
4. HTTP requests and read their
5. * responses.
6. *
7. *

   OkHttpClients should be shared

8. *
9. *

   OkHttp performs best when you create a single {@code

10. OkHttpClient} instance and reuse it for
11. * all of your HTTP calls. This is because each client holds its own
12. connection pool and thread
13. * pools. Reusing connections and threads reduces latency and
14. saves memory. Conversely, creating a
15. * client for each request wastes resources on idle pools.
16. *
17. *

    Use {@code new OkHttpClient()} to create a shared instance

18. with the default settings:
19. *

     {@code

20. *
21. * // The singleton HTTP client.
22. * public final OkHttpClient client = new OkHttpClient();
23. * }
24. *
25. *

    Or use {@code new OkHttpClient.Builder()} to create a shared

26. instance with custom settings:
27. *

     {@code

28. *
29. * // The singleton HTTP client.
30. * public final OkHttpClient client = new OkHttpClient.Builder()
31. * .addInterceptor(new HttpLoggingInterceptor())
32. * .cache(new Cache(cacheDir, cacheSize))
33. * .build();
34. * }
35. *
36. .... 省略
37. */

簡單提煉：

1、OkHttpClient， 可以通過 new OkHttpClient() 或 new OkHttpClient.Builder() 來創建對象， 但是—特別注意， OkHttpClient() 對象最好是共享的， 建議使用單例模式創建。 因為每個 OkHttpClient 對象都管理自己獨有的線程池和連接池。 這一點很多同學，甚至在我經歷的團隊中就有人踩過坑， 每一個請求都創建一個 OkHttpClient 導致內存爆掉。

2、 從上面的整體框架圖，其實執行層有很多屬性功能是需要OkHttpClient 來制定，例如緩存、線程池、攔截器等。如果你是設計者你會怎樣設計 OkHttpClient ？ 建造者模式，OkHttpClient 比較複雜， 太多屬性， 而且客戶的組合需求多樣化， 這種情況下就考慮使用建造者模式。 new OkHttpClien() 創建對象， 內部默認指定了很多屬性：

1. 
   
2. public OkHttpClient() {
3. this(new Builder());
4. }

在看看 new Builder() 的默認實現：

1. 
   
2. public Builder() {
3. dispatcher = new Dispatcher();
4. protocols = DEFAULT_PROTOCOLS;
5. connectionSpecs = DEFAULT_CONNECTION_SPECS;
6. eventListenerFactory = EventListener.factory(EventListener.NONE);
7. proxySelector = ProxySelector.getDefault();
8. cookieJar = CookieJar.NO_COOKIES;
9. socketFactory = SocketFactory.getDefault();
10. hostnameVerifier = OkHostnameVerifier.INSTANCE;
11. certificatePinner = CertificatePinner.DEFAULT;
12. proxyAuthenticator = Authenticator.NONE;
13. authenticator = Authenticator.NONE;
14. connectionPool = new ConnectionPool();
15. dns = Dns.SYSTEM;
16. followSslRedirects = true;
17. followRedirects = true;
18. retryOnConnectionFailure = true;
19. connectTimeout = 10_000;
20. readTimeout = 10_000;
21. writeTimeout = 10_000;
22. pingInterval = 0;
23. }

默認指定 Dispatcher （管理線程池）、鏈接池、超時時間等。

3、 內部對於線程池、鏈接池管理有默認的管理策略，例如空閒時候的線程池、連接池會在一定時間自動釋放，但如果你想主動去釋放也可以通過客戶層去釋放。（很少）

執行層

Response response = mOkHttpClient.newCall(request).execute();

這是應用程序中發起網絡請求最頂端的調用，newCall(request) 方法返回 RealCall 對象。RealCall 封裝了一個 request 代表一個請求調用任務，RealCall 有兩個重要的方法 execute() 和 enqueue(Callback responseCallback)。 execute() 是直接在當前線程執行請求，enqueue(Callback responseCallback) 是將當前任務加到任務隊列中，執行異步請求。

同步請求

1. 
   
2. @Override public Response execute() throws IOException {
3. synchronized (this) {
4. if (executed) throw new IllegalStateException("Already Executed");
5. executed = true;
6. }
7. captureCallStackTrace();
8. try {
9. // client.dispatcher().executed(this) 內部只是記錄下執行狀態，
10. client.dispatcher().executed(this);
11. // 真正執行發生在這裡
12. Response result = getResponseWithInterceptorChain();
13. if (result == null) throw new IOException("Canceled");
14. return result;
15. } finally {
16. // 後面再解釋
17. client.dispatcher().finished(this);
18. }
19. }

執行方法關鍵在 getResponseWithInterceptorChain() 這個方法中， 關於 client.dispatcher().executed(this) 和 client.dispatcher().finished(this); 這裡先忽略 ，後面再看。

請求過程要從執行層說到連接層，涉及到 getResponseWithInterceptorChain 方法中組織的各個攔截器的執行過程，內容比較多，後面章節在說。先說說 RealCall 中 enqueue(Callback responseCallback) 方法涉及的異步請求和線程池。

Dispatcher 和線程池

1. 
   
2. @Override public void enqueue(Callback responseCallback) {
3. synchronized (this) {
4. if (executed) throw new IllegalStateException("Already Executed");
5. executed = true;
6. }
7. captureCallStackTrace();
8. client.dispatcher().enqueue(new AsyncCall(responseCallback));
9. }

調用了 dispatcher 的 enqueue()方法

dispatcher 結合線程池完成了所有異步請求任務的調配。

synchronized void enqueue(AsyncCall call) {

if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {

runningAsyncCalls.add(call);

executorService().execute(call);

} else {

readyAsyncCalls.add(call);

}

}

dispatcher 主要維護了三兩個隊列 readyAsyncCalls、runningAsyncCalls 和 runningSyncCalls，分別代表了準備中隊列， 正在執行的異步任務隊列和正在執行的同步隊列， 重點關注下前面兩個。

現在我們可以回頭來看看前面 RealCall 方法 client.dispatcher().finished(this) 這個疑點了。

在每個任務執行完之後要回調 client.dispatcher().finished(this) 方法， 主要是要將當前任務從 runningAsyncCalls 或 runningSyncCalls 中移除， 同時把 readyAsyncCalls 的任務調度到 runningAsyncCalls 中並執行。

線程池

1. 
   
2. public synchronized ExecutorService executorService() {
3. if (executorService == null) {
4. executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
5. new SynchronousQueue(), Util.threadFactory("OkHttp Dispatcher", false));
6. }
7. return executorService;
8. }

默認實現是一個不限容量的線程池 ， 線程空閒時存活時間為 60 秒。線程池實現了對象複用，降低線程創建開銷，從設計模式上來講，使用了享元模式。

責任鏈 （攔截器執行過程）

1. 
   
2. Response getResponseWithInterceptorChain() throws IOException {
3. // Build a full stack of interceptors.
4. List interceptors = new ArrayList<>();
5. interceptors.addAll(client.interceptors());
6. interceptors.add(retryAndFollowUpInterceptor);
7. interceptors.add(new BridgeInterceptor(client.cookieJar()));
8. interceptors.add(new CacheInterceptor(client.internalCache()));
9. interceptors.add(new ConnectInterceptor(client));
10. if (!forWebSocket) {
11. interceptors.addAll(client.networkInterceptors());
12. }
13. interceptors.add(new CallServerInterceptor(forWebSocket));
15. Interceptor.Chain chain = new RealInterceptorChain(
16. interceptors, null, null, null, 0, originalRequest);
17. return chain.proceed(originalRequest);
18. }
19. }

要跟蹤 Okhttp3 的網絡請求任務執行過程 ，需要看懂以上代碼，看懂以上代碼必須理解設計模式-責任鏈。在責任鏈模式裡，很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪一個對象最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織和分配責任。 網絡請求過程，是比較典型的複合責任鏈的場景，比如請求傳遞過程，我們需要做請求重試， 需要執行緩存策略， 需要建立連接等， 每一個處理節點可以由一個鏈上的對象來處理； 同時客戶端使用的時候可能也會在請求過程中做一些應用層需要的事情，比如我要記錄網絡請求的耗時、日誌等， 責任鏈還可以動態的擴展到客戶業務方。

在 OkHttp3 的攔截器鏈中， 內置了5個默認的攔截器，分別用於重試、請求對象轉換、緩存、鏈接、網絡讀寫。

以上方法中先是添加了客戶端自定義的連接器，然後在分別添加內置攔截器。

Okhttp3 攔截器類圖

現在我們把對 OkHttp 網絡請求執行過程的研究轉化對每個攔截器處理的研究。

retryAndFollowUpInterceptor 重試機制

retryAndFollowUpInterceptor 處於內置攔截器鏈的最頂端，在一個循環中執行重試過程：

1、首先下游攔截器在處理網絡請求過程如拋出異常，則通過一定的機制判斷一下當前鏈接是否可恢復的（例如，異常是不是致命的、有沒有更多的線路可以嘗試等），如果可恢復則重試，否則跳出循環。

2、 如果沒什麼異常則校驗下返回狀態、代理鑑權、重定向等，如果需要重定向則繼續，否則直接跳出循環返回結果。

3、 如果重定向，則要判斷下是否已經達到最大可重定向次數， 達到則拋出異常，跳出循環。

@Override public Response intercept(Chain chain) throws IOException {

Request request = chain.request();

// 創建連接池管理對象

streamAllocation = new StreamAllocation(

client.connectionPool(), createAddress(request.url()), callStackTrace);

1. 
   
2. int followUpCount = 0;
3. Response priorResponse = null;
4. while (true) {
5. if (canceled) {
6. streamAllocation.release();
7. throw new IOException("Canceled");
8. }
10. Response response = null;
11. boolean releaseConnection = true;
12. try {
13. // 將請求處理傳遞下游攔截器處理
14. response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
15. releaseConnection = false;
16. } catch (RouteException e) {
17. // The attempt to connect via a route failed. The request will not have been sent.
18. // 線路異常，判斷滿足可恢復條件，滿足則繼續循環重試
19. if (!recover(e.getLastConnectException(), false, request)) {
20. throw e.getLastConnectException();
21. }
22. releaseConnection = false;
23. continue;
24. } catch (IOException e) {
25. // An attempt to communicate with a server failed. The request may have been sent.

// IO異常，判斷滿足可恢復條件，滿足則繼續循環重試

boolean requestSendStarted = !(e instanceof ConnectionShutdownException);

if (!recover(e, requestSendStarted, request)) throw e;

releaseConnection = false;

continue;

} finally {

// We’re throwing an unchecked exception. Release any resources.

if (releaseConnection) {

streamAllocation.streamFailed(null);

streamAllocation.release();

}

}

1. 
   
2. // Attach the prior response if it exists. Such responses never have a body.
3. if (priorResponse != null) {
4. response = response.newBuilder()
5. .priorResponse(priorResponse.newBuilder()
6. .body(null)
7. .build())
8. .build();
9. }
10. // 是否需要重定向
11. Request followUp = followUpRequest(response);
13. if (followUp == null) {
14. if (!forWebSocket) {
15. streamAllocation.release();
16. }
17. // 不需要重定向，正常返回結果
18. return response;
19. }
21. closeQuietly(response.body());
23. if (++followUpCount > MAX_FOLLOW_UPS) {
24. // 達到次數限制
25. streamAllocation.release();
26. throw new ProtocolException("Too many follow-up requests: " + followUpCount);
27. }
29. if (followUp.body() instanceof UnrepeatableRequestBody) {
30. streamAllocation.release();
31. throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
32. }
34. if (!sameConnection(response, followUp.url())) {
35. streamAllocation.release();
36. streamAllocation = new StreamAllocation(
37. client.connectionPool(), createAddress(followUp.url()), callStackTrace);
38. } else if (streamAllocation.codec() != null) {
39. throw new IllegalStateException("Closing the body of " + response
40. + " didn't close its backing stream. Bad interceptor?");
41. }
43. request = followUp;
44. priorResponse = response;
45. }
46. }

BridgeInterceptor

1. 
   
2. /**
3. * Bridges from application code to network code. First it builds a
4. network request from a user
5. * request. Then it proceeds to call the network. Finally it builds a
6. user response from the network
7. * response.
8. */

這個攔截器比較簡單， 一個實現應用層和網絡層直接的數據格式編碼的橋。 第一： 把應用層客戶端傳過來的請求對象轉換為 Http 網絡協議所需字段的請求對象。 第二， 把下游網絡請求結果轉換為應用層客戶所需要的響應對象。 這個設計思想來自適配器設計模式，大家可以去體會一下。

CacheInterceptor 數據策略（策略模式）

CacheInterceptor 實現了數據的選擇策略， 來自網絡還是來自本地？ 這個場景也是比較契合策略模式場景， CacheInterceptor 需要一個策略提供者提供它一個策略（錦囊）， CacheInterceptor 根據這個策略去選擇走網絡數據還是本地緩存。

緩存的策略過程：

1、 請求頭包含 “If-Modified-Since” 或 “If-None-Match” 暫時不走緩存

2、 客戶端通過 cacheControl 指定了無緩存，不走緩存

3、客戶端通過 cacheControl 指定了緩存，則看緩存過期時間，符合要求走緩存。

4、 如果走了網絡請求，響應狀態碼為 304（只有客戶端請求頭包含 “If-Modified-Since” 或 “If-None-Match” ，服務器數據沒變化的話會返回304狀態碼，不會返回響應內容）， 表示客戶端繼續用緩存。

@Override public Response intercept(Chain chain) throws IOException {

Response cacheCandidate = cache != null

? cache.get(chain.request())

: null;

long now = System.currentTimeMillis();

CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();

// 獲取緩存策略

Request networkRequest = strategy.networkRequest;

Response cacheResponse = strategy.cacheResponse;

if (cache != null) {

cache.trackResponse(strategy);

}

if (cacheCandidate != null && cacheResponse == null) {

closeQuietly(cacheCandidate.body()); // The cache candidate wasn’t applicable. Close it.

}

// If we’re forbidden from using the network and the cache is insufficient, fail.

if (networkRequest == null && cacheResponse == null) {

return new Response.Builder()

.request(chain.request())

.protocol(Protocol.HTTP_1_1)

.code(504)

.message(“Unsatisfiable Request (only-if-cached)”)

.body(Util.EMPTY_RESPONSE)

.sentRequestAtMillis(-1L)

.receivedResponseAtMillis(System.currentTimeMillis())

.build();

}

// 走緩存

if (networkRequest == null) {

return cacheResponse.newBuilder()

.cacheResponse(stripBody(cacheResponse))

.build();

}

Response networkResponse = null;

try {

// 執行網絡

networkResponse = chain.proceed(networkRequest);

} finally {

// If we’re crashing on I/O or otherwise, don’t leak the cache body.

if (networkResponse == null && cacheCandidate != null) {

closeQuietly(cacheCandidate.body());

}

}

1. 
   
2. // 返回 304 仍然走本地緩存
3. if (cacheResponse != null) {
4. if (networkResponse.code() == HTTP_NOT_MODIFIED) {
5. Response response = cacheResponse.newBuilder()
6. .headers(combine(cacheResponse.headers(), networkResponse.headers()))
7. .sentRequestAtMillis(networkResponse.sentRequestAtMillis())
8. .receivedResponseAtMillis(networkResponse.receivedResponseAtMillis())
9. .cacheResponse(stripBody(cacheResponse))
10. .networkResponse(stripBody(networkResponse))
11. .build();
12. networkResponse.body().close();
14. // Update the cache after combining headers but before stripping the
15. // Content-Encoding header (as performed by initContentStream()).
16. cache.trackConditionalCacheHit();
17. cache.update(cacheResponse, response);
18. return response;
19. } else {
20. closeQuietly(cacheResponse.body());
21. }
22. }
23. Response response = networkResponse.newBuilder()
24. .cacheResponse(stripBody(cacheResponse))
25. .networkResponse(stripBody(networkResponse))
26. .build();
27. if (cache != null) {
28. if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
29. // 存儲緩存
30. CacheRequest cacheRequest = cache.put(response);
31. return cacheWritingResponse(cacheRequest, response);
32. }
33. if (HttpMethod.invalidatesCache(networkRequest.method())) {
34. try {
35. cache.remove(networkRequest);
36. } catch (IOException ignored) {
37. // The cache cannot be written.
38. }
39. }
40. }
41. return response;
42. }

緩存實現

OkHttp3 內部緩存默認實現是使用的 DiskLruCache， 這部分代碼有點繞：

interceptors.add(new CacheInterceptor(client.internalCache()));

初始化 CacheInterceptor 時候 client.internalCache() 這裡獲取OkHttpClient的緩存。

1. 
   
2. InternalCache internalCache() {
3. return cache != null ? cache.internalCache : internalCache;
4. }

注意到， 這個方法是非公開的。 客戶端只能通過 OkhttpClient.Builder的 cache(cache) 定義緩存， cache 是一個 Cache 對實例。 在看看 Cache 的內部實現， 內部有一個 InternalCache 的內部類實現。 內部調用時使用 InternalCache 實例提供接口,而存儲邏輯在 Cache 中實現。

Cache 為什麼不直接實現 InternalCache ，而通過持有 InternalCache 的一個內部類對象來實現方法？ 是希望控制緩存實現， 不希望用戶外部去實現緩存，同時對內保持一定的擴展。

鏈接層

RealCall 封裝了請求過程， 組織了用戶和內置攔截器，其中內置攔截器 retryAndFollowUpInterceptor -> BridgeInterceptor -> CacheInterceptor 完執行層的大部分邏輯 ，ConnectInterceptor -> CallServerInterceptor 兩個攔截器開始邁向連接層最終完成網絡請求。

---

分享到:

---

閱讀更多 JavaSpring高級進階 的文章

關鍵字: 設計模式 源碼 關於

---