使用了好久的okhttp，都沒有對其源碼進行學習拆解，今天開始，有時間就寫一些學習筆記，對okhttp進行分析。
基本請求流程
源碼地址：https://github.com/square/okhttp
如何使用的？
以一個 Post同步 請求為例：
OkHttpClient client = new OkHttpClient();
RequestBody body = RequestBody.create(JSON, json);
Request request = new Request.Builder()
.url(url)
.post(body)
.build();
Response response = client.newCall(request).execute());
根據上面的代碼，使用okhttp，基本就是四步：
第一步，建立一個OkHttpClient 類，這個類包含了一系列的協議路由，攔截器等等，都是后面請求必不可少的變量。（具體解析留在后面）
第二步，創建 RequestBody ，請求的實體，可以指定對應的contentType ，還有具體是實體內容。
第三步，創建請求，指定url, 還有body。Request類使用的是Bulder模式，在okhttp里面比較大面積的使用此模式。
第四步，通過第一步的client 調用 newCall 創建一個Call ，然后execute()，發起一個同步的請求。
如果我們只是使用，拿到結果，請求就已經可以結束了。但是我們需要了解它的內部實現，現在才剛剛開始。
具體流程：
接下來就是從這個OkHttpClient 的 newCall 還有 execute()，開始向下了剖析。
@Override public Call newCall(Request request) {
return new RealCall(this, request, false /* for web socket */);
}
原來這個Call只是一個接口，這里真正是創建了一個實現Call接口的 RealCall對象。可以看看這個RealCall里面的 execute方法接下來是干了什么。
@Override
public Response execute() throws IOException {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
try {
client.dispatcher().executed(this);
Response result = getResponseWithInterceptorChain();
if (result == null) throw new IOException("Canceled");
return result;
} finally {
client.dispatcher().finished(this);
}
}
這個RealCall 里面的執行的方法，首先會把這個Call 加入到 dispatcher 這個調度器里面（Dispatcher這個類也需要好好研究一下，主要是Call請求線程相關的控制）。
由于我們分析的是同步請求，這里的dispatcher作用是可以方便對這個Call進行統一控制，如取消等 。
接下來就是調用了 getResponseWithInterceptorChain();
那我們繼續向下這個方法進發了：
Response getResponseWithInterceptorChain() throws IOException {
// Build a full stack of interceptors.
List<Interceptor> interceptors = new ArrayList<>();
interceptors.addAll(client.interceptors());
interceptors.add(retryAndFollowUpInterceptor);
interceptors.add(new BridgeInterceptor(client.cookieJar()));
interceptors.add(new CacheInterceptor(client.internalCache()));
interceptors.add(new ConnectInterceptor(client));
if (!forWebSocket) {
interceptors.addAll(client.networkInterceptors());
}
interceptors.add(new CallServerInterceptor(forWebSocket));
Interceptor.Chain chain = new RealInterceptorChain(
interceptors, null, null, null, 0, originalRequest);
return chain.proceed(originalRequest);
}
哇，這里好多這個Interceptor ，意為攔截器的意思。其實就是對將要發出去的請求，或者接收到的結果的進行攔截，然后進行一些需要的修改，然后在做下一步操作。例如在發出去前，添加必要的信息，或者回來之后把結果進行統一的處理。
這里把自定義的攔截器，還有內置的必要的攔截器都添加到一個List里面了，最后用List的攔截器創建一個攔截器的鏈—— RealInterceptorChain。而這個RealInterceptorChain 其實是實現了Interceptor 里面的一個Chain 接口。
這里最后調用 chain.proceed(originalRequest); 這里就是返回一個Response 對象了，但是這中間這么多的攔截器，都干了些什么了？ 是如何攔截的？如果連接起來的？帶著問題，我們繼續向這里面剖析。
我們先了解一下RealInterceptorChain 這個類是如何進行工作的。
首先RealInterceptorChain，是實現了Interceptor.Chain 接口的一個類，這個接口有是三個方法，后面會介紹到，其中一個就是前面調用的proceed方法。
那么在它的 proceed中做了什么？
@Override
public Response proceed(Request request) throws IOException {
return proceed(request, streamAllocation, httpCodec, connection);
}
public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
RealConnection connection) throws IOException {
//省略一些前置校驗的代碼
、、、
// Call the next interceptor in the chain.
RealInterceptorChain next = new RealInterceptorChain(
interceptors, streamAllocation, httpCodec, connection, index + 1, request);
Interceptor interceptor = interceptors.get(index);
Response response = interceptor.intercept(next);
//省略一些后續處理代碼
、、、
return response;
}
省略了前后的一些代碼，發現，其實這里又新建一個 RealInterceptorChain，然后調用了這個攔截器的 intercept 的方法。那么在每個攔截器里面做了什么，這個攔截的方法又是做了什么呢？
首先看一下攔截器這個接口：
public interface Interceptor {
Response intercept(Chain chain) throws IOException;
interface Chain {
Request request();
Response proceed(Request request) throws IOException;
Connection connection();
}
}
很明顯，每個實現Interceptor的攔截器。都會實現了intercept，這樣一個攔截的方法。而傳入的就是一個Chain。符合前面RealInterceptorChain的調用。
以一個攔截器的代碼為例：BridgeInterceptor，這個類實現的intercept方法，而這個方法里面，除了那些前置或后續的操作之外，在中間你會發現 下面一句代碼：
Response networkResponse = chain.proceed(requestBuilder.build());
又通過傳進來的Chain ，重新調用了proceed的方法。好吧，到這里應該可以了解到這些攔截器，是如何一個個調用被調用的了，原理都是通過了中間的一個RealInterceptorChain，一個接一個的向下調用。然后得到的結果又一個一個向上傳。
總結一下，這些攔截器的調用：
剛開始getResponseWithInterceptorChain的最后開始調用了 chain.proceed，然后在RealInterceptorChain的里面，又新建一個 RealInterceptorChain，并且調用當前的攔截器的 intercept，并且把新建的Chain傳遞進去，然后攔截器的 intercept方法里面，除了一些自身的操作外，又調用Chain的proceed方法。就這樣一直調用新建Chian, 一直調用到最后一個攔截器。
這里的調用其實是一個迭代，遞歸的結構。請求做了前一步的處理才能到下一級，一級級下去，到最后真正發出去請求，相對做了攔截。而得到結果，只有當最后一個攔截器完全了請求，拿到結果之后，才會把結果往上一級，上一級拿到結果，做了相應的處理之后，再到上一級，這就是對結果的攔截處理。
這么看來，流程最后一個攔截器就是最終拿到結果的一個地方了。
而每個攔截器都有每個的作用，這里只做簡單的按順序進行介紹，后面再對其深入的剖析。
- RetryAndFollowUpInterceptor
這攔截器主要是做重試，網絡錯誤，以及請求重定向的一些操作。 - BridgeInterceptor
這個攔截器，主要把用戶的請求轉換為網絡的請求，添加一些頭部信息等。 - CacheInterceptor
緩存攔截器 - ConnectInterceptor
連接攔截器，主要是處理連接服務器，以及http , https的包裝 - CallServerInterceptor
服務攔截器，主要是發送（write、input）、讀取（read、output）數據。也是攔截器的最后一個環節，這里就真正拿到了網絡的結果了。
最后是一個圖示例來展示一下，發出請求到收到結果的整個流程，是如果進行的：
結束：
到這里為止，其實整個okhttp, 發出請求，到接收請求的流程已經清晰了，但是這僅僅是最基本的流程，你會發現很多有疑問的地方，如：OkHttpClient整個類到底做了些什么？RequestBody，是一個怎么樣的類？每一個Request的結構是如何的？每一個RealCall , 是怎么分配線程的？每一個攔截器都干了什么？等等。帶著問題，繼續剖析下去。
系列：
OKhttp源碼學習（二）—— OkHttpClient
OKhttp源碼學習（三）—— Request, RealCall
OKhttp源碼學習（四）——RetryAndFollowUpInterceptor攔截器分析
OKhttp源碼學習（五）—— BridgeInterceptor攔截器
OKhttp源碼學習（六）—— CacheInterceptor攔截器
OKhttp源碼學習（七）—— ConnectInterceptor攔截器
OKhttp源碼學習（八）——CallServerInterceptor攔截器
OKhttp源碼學習（九）—— 任務管理（Dispatcher）
