我們都知道在OkHttp3中，其靈活性，很大程度上體現(xiàn)在，我們可以 intercept 其任意一個環(huán)節(jié)，而這個優(yōu)勢便是okhttp3整個請求響應(yīng)架構(gòu)體系的精髓所在:

• 在OkHttp3中，每一個請求任務(wù)都封裝為一個 Call ，其實(shí)現(xiàn)為 RealCall 。
• 而所有的策略幾乎都可以通過 OkHttpClient 傳入
• 所有全局策略與數(shù)據(jù)，除了存儲在允許上層訪問的 OkHttpClient 實(shí)例以外，還有一部分是存儲在只允許包可見的 Internal.instance 中（如連接池、路由黑名單等)
• OkHttp中用戶可傳入的 interceptor 分為兩類，一類是全局 interceptor ，該類 interceptor 在請求開始之前最早被調(diào)用，另外一類為非網(wǎng)頁請求的 networkInterceptor ，這類 interceptor 只有在非網(wǎng)頁請求中會被調(diào)用，并且是在組裝完成請求之后，真正發(fā)起請求之前被調(diào)用(這塊具體可以參看 RealCall#getResponseWithInterceptorChain() 方法)
• 整個請求過程通過遞歸 RealInterceptorChain#proceed 來實(shí)現(xiàn)，在每個 interceptor 中調(diào)用遞歸到下一個 interceptor 來完成整個請求流程，并且在遞歸回到當(dāng)前 interceptor 后完成響應(yīng)處理
• 在異步請求中，我們通過 Callback 來獲得簡單清晰的請求回調(diào)( onFailure 、 onResponse )
• 但是在 OkHttpClient 中，我們可以傳入 EventListener 的工廠方法，為每一個請求創(chuàng)建一個 EventListener ，來接收非常細(xì)的事件回調(diào)

連接池

我們知道在OkHttp3存在連接池，并且該連接池是通過與 StreamAllocation 的配合完成連接池的維護(hù)。

• 所有的請求連接都會通過 StreamAllocation 進(jìn)行獲得，并且結(jié)合 ConnectionPool 進(jìn)行引用計(jì)數(shù)，來有效緩存連接
• 而在 StreamAllocation 中，通過 RouteSelector 來根據(jù)請求地址進(jìn)行路由處理，期間就涉及到了 DNS解析 、 協(xié)議處理 、 代理選擇 、 簽名校驗(yàn) 等

默認(rèn)連接池策略:

• 最多64個請求
• 同一個host最多5個請求
• 連接最長閑置5分鐘
• 異步連接所在線程池名: OkHttp Dispatcher
• 常駐清理連接線程池: OkHttp ConnectionPool

獲得連接

連接池

II. 各類線程池分析

OkHttp中的對所有的任務(wù)采用 NamedRunnable ，與我開源的 ThreadDebugger 中通過架構(gòu)層面約束，讓每個執(zhí)行單元給出對應(yīng)的業(yè)務(wù)名稱，以便于線程維護(hù)不謀而合。關(guān)于Android中 ThreadPoolExecutor 的機(jī)制，可以看我之前寫的這篇文章。

1. 異步請求線程池

該線程池名 OkHttp Dispatcher ，該線程用于執(zhí)行異步的請求任務(wù)。

• 該線程池本身: 無任務(wù)上限，自動回收閑置60s的線程
• 但是 Dispatcher 中在進(jìn)口進(jìn)行把關(guān)控制，默認(rèn)情況下保證在當(dāng)前進(jìn)程中 OkHttpClient 最多只有64個請求，池子中相同host的請求不超過5個
• 架構(gòu)上通過兩個雙端隊(duì)列( readyAsyncCalls:Deque<AsyncCall> 與 runningAsyncCals:Dequeue<AsyncCall> )分別用于維護(hù)等待中的任務(wù)與運(yùn)行中的任務(wù)
• 在每一個異步任務(wù)后，都會檢查一遍 readyAsyncCalls ，在滿足條件下，將最先進(jìn)入隊(duì)列的任務(wù)丟入該線程池進(jìn)行執(zhí)行

2. 連接池清理線程池

該線程池名 OkHttp ConnectionPool ，該線程用于自動清理長時間閑置或泄漏的連接。

• 該線程本身: 無任務(wù)上限，自動回收閑置60s的線程
• 但是 ConnectionPool 中通過一個 cleanupRunning 的標(biāo)記，控制當(dāng)前僅有一個清理任務(wù)進(jìn)入隊(duì)列
• 清理任務(wù)，會不斷清理，在所有需要清理的連接都清理完成后，會計(jì)算出最近一次需要清理的時間并阻塞，不斷清理直到連接池中沒有任何連接，方才結(jié)束
• 在每次有連接加入連接池時，如果當(dāng)前沒有清理任務(wù)運(yùn)行，會加入一個清理任務(wù)到清理線程池中執(zhí)行

3. 緩存整理線程池

該線程池名 OkHttp DiskLruCache ，該線程池用于整理本地請求結(jié)果的緩存。

• 該線程池本身: 最多1個運(yùn)行中線程，其余任務(wù)會阻塞住等待，回收閑置60s的線程
• 由于可運(yùn)行僅為一個線程，因此所有操作無需考慮線程安全問題
• 緩存的整理包含: 達(dá)到閥值大小的文件，刪除最近最少使用的記錄；在有關(guān)操作達(dá)到一定數(shù)量以后對記錄進(jìn)行重建

4. HTTP2異步事務(wù)線程池

該線程池名 OkHttp Http2Connection ，我們都知道HTTP2采用了多路復(fù)用(相關(guān)知識可以翻看這篇文章)，因此需要維護(hù)連接有效性，本線程池就是用于維護(hù)相關(guān)的各類HTTP2事務(wù)

• 該線程池本身: 無任務(wù)上限，自動回收閑置60s的線程
• 每一個HTTP2連接都有這么一個線程池存在

回望 FileDownloader ，有一個極大的痛點(diǎn)是，在最早其就引入了多進(jìn)程，雖然在后期實(shí)現(xiàn)了單進(jìn)程與多進(jìn)程的切換，但是整套體系不得不為該多進(jìn)程買單，極大的增加了相關(guān)的復(fù)雜度，以及無法輕量的同步回調(diào)。如果讓我再寫一個下載引擎，我也許也會考慮分拆各個模塊，讓核心代碼保持充分的簡單，也讓每個模塊足夠單一。

 

來自：https://blog.dreamtobe.cn/okhttp3-framework/

 

標(biāo)簽： dns dns解析 isp 安全 代碼

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。