1.引言
面試的時候經常被問及到okhttp3 ，retrofit2實現原理。而自己也只是停留在使用的層次對于內部的機制也是不懂。趁著10.1放假。學習下okhttp3.做下筆記。。參考文獻http://frodoking.github.io/2015/03/12/android-okhttp/， http://www.lxweimin.com/p/aad5aacd79bf
2.正言
okhttp框架的核心類庫：
OkHttpClient:
配置和創建http連接。大多數應用程序可以使用一個單一的okhttpclient他們所有的HTTP請求-受益于一個共享的響應緩存、線程池、連接復用，等。
實例okhttpclient擬完全配置在他們共享曾經分享他們應該被視為一成不變的，可以安全地用于同時打開新的連接。如果需要，線程可以調用克隆做的okhttpclient可以安全地修改與進一步的配置變化淺拷貝。
Request:(構造者模式)
封裝的一個Http請求。
RequestBody:
RequestBody類是請求體類，上傳數據的封裝，它的writeTo方法可以得到流對象，然后將請求體數據寫到服務器。這是上傳數據的核心方法
1，public abstract MediaType contentType()//數據類型
2，public long contentLength()//數據長度
3，public abstract void writeTo(BufferedSink sink)//寫操作
BufferedSink 類是square公司開源的IO框架Okio中的一個類，這個類封裝了OutputStream，即本質是一個輸出流，具有write方法。Okio框架和BufferedSink 類也不是本篇介紹的重點，這兒不做講解。把BufferedSink 當成OutputStream使用即可。
RequestBody的子類有 FormBody，MultipartBody。根據不同的上傳數據類型選擇不同的body。
InternalCache :存儲Response信息的類
//下面一行很重要,這個方法會去獲取client中的Cache。同時Cache在初始化的時候會去讀取緩存目錄中關于曾經請求過的所有信息。
InternalCache responseCache = Internal.instance.internalCache(client);
Response cacheCandidate = responseCache != null? responseCache.get(request): null;
Dispatcher：
當異步請求執行的政策。每個dispatcher里面通過ExecutorService 來執行Call。
- Dispatcher的結構
Dispatcher維護了如下變量，用于控制并發的請求
maxRequests = 64: 最大并發請求數為64
maxRequestsPerHost = 5: 每個主機最大請求數為5
Dispatcher: 分發者，也就是生產者（默認在主線程）
AsyncCall: 隊列中需要處理的Runnable（包裝了異步回調接口）
ExecutorService：消費者池（也就是線程池）
Deque<readyAsyncCalls>：緩存（用數組實現，可自動擴容，無大小限制）
Deque<runningAsyncCalls>：正在運行的任務，僅僅是用來引用正在運行的任務以判斷并發量，注意它并不是消費者緩存
根據生產者消費者模型的模型理論，當入隊(enqueue)請求時，如果滿足(runningRequests<64 && runningRequestsPerHost<5)，那么就直接把AsyncCall直接加到runningCalls的隊列中，并在線程池中執行。如果消費者緩存滿了，就放入readyAsyncCalls進行緩存等待。當任務執行完成后,調用[finished(https://github.com/square/okhttp/blob/7826bcb2fb1facb697a4c512776756c05d8c9deb/okhttp/rc/main/java/okhttp3/Dispatcher.java#L142-L142)的promoteCalls()函數，手動移動緩存區（可以看出這里是主動清理的，因此不會發生死鎖）
RealCall:
Dispatcher中executorService().execute(call)，是執行一個請求。追蹤代碼發現。這代碼的本質上是調用了。RealCall類中的getResponseWithInterceptorChain得到Response 返回對象。。
進一步追蹤ConnectInterceptor 發現：
StreamAllocation類：
StreamAllocation 里面主要是得到RealConnection對象。。跟蹤RealConnection對象。發現RealConnection 有raw socket的操作：
Interceptor:
這個接口很重要，一般都是調用Interceptor.interceptor(Chain chain )。這方法實際上執行的是 chain.proceed(Request request)。 okhttp3 里面得到Response，實際上就是通過chain.proceed() 方法得到的。
。
RealInterceptorChain：
總體請求過程：
上面是OKHttp總體設計圖，主要是通過Diapatcher不斷從RequestQueue中取出請求（Call），根據是否已緩存調用Cache或Network這兩類數據獲取接口之一，從內存緩存或是服務器取得請求的數據。該引擎有同步和異步請求，同步請求通過Call.execute()直接返回當前的Response，而異步請求會把當前的請求Call.enqueue添加（AsyncCall）到請求隊列中，并通過回調（Callback）的方式來獲取最后結果。
詳細類關系圖
由于整個設計類圖比較大，所以本人將從核心入口client、cache、interceptor、網絡配置、連接池、平臺適配性…這些方面來逐一進行分析源代碼的設計。
下面是核心入口OkHttpClient的類設計圖
從OkHttpClient類的整體設計來看，它采用門面模式來。client知曉子模塊的所有配置以及提供需要的參數。client會將所有從客戶端發來的請求委派到相應的子系統去。
在該系統中，有多個子系統、類或者類的集合。例如上面的cache、連接以及連接池相關類的集合、網絡配置相關類集合等等。每個子系統都可以被客戶端直接調用，或者被門面角色調用。子系統并不知道門面的存在，對于子系統而言，門面僅僅是另外一個客戶端而已。同時，OkHttpClient可以看作是整個框架的上下文。
通過類圖，其實很明顯反應了該框架的幾大核心子系統；路由、連接協議、攔截器、代理、安全性認證、連接池以及網絡適配。從client大大降低了開發者使用難度。同時非常明了的展示了該框架在所有需要的配置以及獲取結果的方式。
在接下來的幾個Section中將會結合子模塊核心類的設計，從該框架的整體特性上來分析這些模塊是如何實現各自功能。以及各個模塊之間是如何相互配合來完成客戶端各種復雜請求。
