博文出處：OkHttp源碼解析朽合，歡迎大家關(guān)注我的博客，謝謝饱狂！
Header
注：本文 OkHttp 源碼解析基于 v3.8.1 曹步。
OkHttp in GitHub：https://github.com/square/okhttp
現(xiàn)如今，在 Android 開發(fā)領(lǐng)域大多數(shù)都是選擇以 OkHttp 作為網(wǎng)絡(luò)框架休讳。
然而讲婚，簡單地會使用 OkHttp 并不能讓我們得到滿足。更深層次的俊柔，我們需要閱讀框架的源碼筹麸，才能用起來得心應(yīng)手，融會貫通婆咸。
An HTTP & HTTP/2 client for Android and Java applications.
這是官網(wǎng)上對于 OkHttp 的介紹竹捉，簡單明了。同時尚骄，也印證了那句經(jīng)典的話：
Talk is cheap, show me the code.
OkHttp的簡單使用方法
OkHttp 使用方法块差，直接抄官網(wǎng)的 \(╯-╰)/ 。
GET 請求：
OkHttpClient client = new OkHttpClient();
String run(String url) throws IOException {
Request request = new Request.Builder()
.url(url)
.build();
Response response = client.newCall(request).execute();
return response.body().string();
}
POST 請求：
public static final MediaType JSON
= MediaType.parse("application/json; charset=utf-8");
OkHttpClient client = new OkHttpClient();
String post(String url, String json) throws IOException {
RequestBody body = RequestBody.create(JSON, json);
Request request = new Request.Builder()
.url(url)
.post(body)
.build();
Response response = client.newCall(request).execute();
return response.body().string();
}
深入源碼
在這里倔丈，先分析下同步請求的源碼憨闰，之后再回過頭來看異步請求的源碼炸客。
Let's go !
同步請求
OkHttpClient
首先創(chuàng)建一個 OkHttpClient 對象肢专，那我們看看在構(gòu)造器中做了什么：
public OkHttpClient() {
this(new Builder());
}
OkHttpClient(Builder builder) {
this.dispatcher = builder.dispatcher; // 分發(fā)器
this.proxy = builder.proxy; // 代理
this.protocols = builder.protocols; // 協(xié)議
this.connectionSpecs = builder.connectionSpecs;
this.interceptors = Util.immutableList(builder.interceptors); // 攔截器
this.networkInterceptors = Util.immutableList(builder.networkInterceptors); // 網(wǎng)絡(luò)攔截器
this.eventListenerFactory = builder.eventListenerFactory;
this.proxySelector = builder.proxySelector; // 代理選擇
this.cookieJar = builder.cookieJar; // cookie
this.cache = builder.cache; // 緩存
this.internalCache = builder.internalCache;
this.socketFactory = builder.socketFactory;
boolean isTLS = false;
for (ConnectionSpec spec : connectionSpecs) {
isTLS = isTLS || spec.isTls();
}
if (builder.sslSocketFactory != null || !isTLS) {
this.sslSocketFactory = builder.sslSocketFactory;
this.certificateChainCleaner = builder.certificateChainCleaner;
} else {
X509TrustManager trustManager = systemDefaultTrustManager();
this.sslSocketFactory = systemDefaultSslSocketFactory(trustManager);
this.certificateChainCleaner = CertificateChainCleaner.get(trustManager);
}
this.hostnameVerifier = builder.hostnameVerifier;
this.certificatePinner = builder.certificatePinner.withCertificateChainCleaner(
certificateChainCleaner);
this.proxyAuthenticator = builder.proxyAuthenticator;
this.authenticator = builder.authenticator;
this.connectionPool = builder.connectionPool; // 連接復(fù)用池
this.dns = builder.dns;
this.followSslRedirects = builder.followSslRedirects;
this.followRedirects = builder.followRedirects;
this.retryOnConnectionFailure = builder.retryOnConnectionFailure;
this.connectTimeout = builder.connectTimeout; // 連接超時時間
this.readTimeout = builder.readTimeout; // 讀取超時時間
this.writeTimeout = builder.writeTimeout; // 寫入超時時間
this.pingInterval = builder.pingInterval;
}
在構(gòu)造器中利用建造者模式來構(gòu)建 OkHttpClient 的對象难审。當(dāng)然楼镐，如果你想自定義 OkHttpClient 配置的話，就要 new 一個 OkHttpClient.Builder 來配置自己的參數(shù)了二庵。相信大家都干過這種事情了(∩_∩)钳幅。
OkHttpClient 的構(gòu)造器中主要是扎堆扎堆的配置秉剑，沒別的蜜氨。
之后再調(diào)用 newCall(Request request) ：
@Override
public Call newCall(Request request) {
return RealCall.newRealCall(this, request, false /* for web socket */);
}
在方法里面其實(shí)是創(chuàng)建了一個 RealCall 的對象械筛，那么我們就進(jìn)入 RealCall 中去看看吧。
RealCall
在 RealCall 的構(gòu)造器中只是給一些變量賦值或初始化而已飒炎，沒什么：
static RealCall newRealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
// Safely publish the Call instance to the EventListener.
RealCall call = new RealCall(client, originalRequest, forWebSocket);
call.eventListener = client.eventListenerFactory().create(call);
return call;
}
private RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
this.client = client;
this.originalRequest = originalRequest;
this.forWebSocket = forWebSocket;
this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket);
}
然后再把目光轉(zhuǎn)向 RealCall 中的 execute() 方法：
@Override
public Response execute() throws IOException {
synchronized (this) {
// 如果該 call 已經(jīng)被執(zhí)行過了埋哟，就設(shè)置 executed 為 true
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
try {
// 加入 runningSyncCalls 隊列中
client.dispatcher().executed(this);
// 得到響應(yīng) result
Response result = getResponseWithInterceptorChain();
if (result == null) throw new IOException("Canceled");
return result;
} finally {
// 從 runningSyncCalls 隊列中移除
client.dispatcher().finished(this);
}
}
execute() 方法為執(zhí)行該 RealCall，在方法里面一開始檢查了該 call 時候被執(zhí)行郎汪。
然后又加入了 Dispatcher 的 runningSyncCalls 中赤赊。runningSyncCalls 隊列只是用來記錄正在同步請求中的 call 闯狱，在 call 完成請求后又會從 runningSyncCalls 中移除。
可見抛计，在同步請求中 Dispatcher 參與的部分很少哄孤。但是在異步請求中， Dispatcher 可謂是大展身手吹截。
最重要的方法录豺，那就是 getResponseWithInterceptorChain() 。我們可以看到這方法是直接返回 Response 對象的饭弓，所以，在這個方法中一定做了很多很多的事情媒抠。
那就繼續(xù)深入吧：
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())); // 加入轉(zhuǎn)化請求響應(yīng)的攔截器
interceptors.add(new CacheInterceptor(client.internalCache())); // 加入緩存攔截器
interceptors.add(new ConnectInterceptor(client)); // 加入連接攔截器
if (!forWebSocket) {
interceptors.addAll(client.networkInterceptors()); // 加入用戶自定義的網(wǎng)絡(luò)攔截器
}
interceptors.add(new CallServerInterceptor(forWebSocket)); // 加入發(fā)出請求和讀取響應(yīng)的攔截器
Interceptor.Chain chain = new RealInterceptorChain(interceptors, null, null, null, 0,
originalRequest, this, eventListener, client.readTimeoutMillis());
// 利用 chain 來鏈?zhǔn)秸{(diào)用攔截器弟断，最后的返回結(jié)果就是 Response 對象
return chain.proceed(originalRequest);
}
在 getResponseWithInterceptorChain() 方法中有一堆的攔截器！Ｅ可阀趴！
關(guān)于攔截器，之前在 一起來寫OKHttp的攔截器 這篇博客中有講過苍匆，若不了解的同學(xué)可以先看下刘急。
我們都知道，攔截器是 OkHttp 的精髓浸踩。
-
client.interceptors()叔汁，首先加入interceptors的是用戶自定義的攔截器，比如修改請求頭的攔截器等检碗； -
RetryAndFollowUpInterceptor是用來重試和重定向的攔截器据块，在下面我們會講到； -
BridgeInterceptor是用來將用戶友好的請求轉(zhuǎn)化為向服務(wù)器的請求折剃，之后又把服務(wù)器的響應(yīng)轉(zhuǎn)化為對用戶友好的響應(yīng)另假； -
CacheInterceptor是緩存攔截器，若存在緩存并且可用就直接返回該緩存怕犁，否則會向服務(wù)器請求边篮； -
ConnectInterceptor用來建立連接的攔截器； -
client.networkInterceptors()加入用戶自定義的networkInterceptors; -
CallServerInterceptor是真正向服務(wù)器發(fā)出請求且得到響應(yīng)的攔截器奏甫；
最后在聚合了這些攔截器后戈轿，利用 RealInterceptorChain 來鏈?zhǔn)秸{(diào)用這些攔截器，利用的就是責(zé)任鏈模式扶檐。
RealInterceptorChain
RealInterceptorChain 可以說是真正把這些攔截器串起來的一個角色凶杖。一個個攔截器就像一顆顆珠子，而 RealInterceptorChain 就是把這些珠子串連起來的那根繩子款筑。
進(jìn)入 RealInterceptorChain 智蝠，主要是 proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec, RealConnection connection) 這個方法：
public Response proceed(Request request, StreamAllocation streamAllocation, HttpCodec httpCodec,
RealConnection connection) throws IOException {
if (index >= interceptors.size()) throw new AssertionError();
calls++;
// If we already have a stream, confirm that the incoming request will use it.
if (this.httpCodec != null && !this.connection.supportsUrl(request.url())) {
throw new IllegalStateException("network interceptor " + interceptors.get(index - 1)
+ " must retain the same host and port");
}
// If we already have a stream, confirm that this is the only call to chain.proceed().
if (this.httpCodec != null && calls > 1) {
throw new IllegalStateException("network interceptor " + interceptors.get(index - 1)
+ " must call proceed() exactly once");
}
// 得到下一次對應(yīng)的 RealInterceptorChain
RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec,
connection, index + 1, request, call, eventListener, readTimeout);
// 當(dāng)前次數(shù)的 interceptor
Interceptor interceptor = interceptors.get(index);
// 進(jìn)行攔截處理腾么，并且在 interceptor 鏈?zhǔn)秸{(diào)用 next 的 proceed 方法
Response response = interceptor.intercept(next);
// 確認(rèn)下一次的 interceptor 調(diào)用過 chain.proceed()
if (httpCodec != null && index + 1 < interceptors.size() && next.calls != 1) {
throw new IllegalStateException("network interceptor " + interceptor
+ " must call proceed() exactly once");
}
// Confirm that the intercepted response isn't null.
if (response == null) {
throw new NullPointerException("interceptor " + interceptor + " returned null");
}
if (response.body() == null) {
throw new IllegalStateException(
"interceptor " + interceptor + " returned a response with no body");
}
return response;
}
在代碼中是一次次鏈?zhǔn)秸{(diào)用攔截器，可能有些同學(xué)還是看不懂杈湾。那么解虱，我就捉急地畫了一張示意圖：
interceptors
有了這張圖就好懂多了，如果還沒懂的話就只能自己慢慢體會了漆撞。
下面就要進(jìn)入分析攔截器的步驟了殴泰，至于用戶自定義的攔截器在這就略過了。還有浮驳，攔截器只分析主要的 intercept(Chain chain) 代碼悍汛。
RetryAndFollowUpInterceptor
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
RealInterceptorChain realChain = (RealInterceptorChain) chain;
Call call = realChain.call();
EventListener eventListener = realChain.eventListener();
streamAllocation = new StreamAllocation(client.connectionPool(), createAddress(request.url()),
call, eventListener, callStackTrace);
int followUpCount = 0;
Response priorResponse = null;
// 如果取消，就釋放資源
while (true) {
if (canceled) {
streamAllocation.release();
throw new IOException("Canceled");
}
Response response = null;
boolean releaseConnection = true;
try {
// 調(diào)用下一個攔截器
response = realChain.proceed(request, streamAllocation, null, null);
releaseConnection = false;
} catch (RouteException e) {
// The attempt to connect via a route failed. The request will not have been sent.
// 路由連接失敗至会，請求將不會被發(fā)送
if (!recover(e.getLastConnectException(), false, request)) {
throw e.getLastConnectException();
}
releaseConnection = false;
continue;
} catch (IOException e) {
// An attempt to communicate with a server failed. The request may have been sent.
// 服務(wù)器連接失敗离咐，請求可能已被發(fā)送
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();
}
}
// Attach the prior response if it exists. Such responses never have a body.
if (priorResponse != null) {
response = response.newBuilder()
.priorResponse(priorResponse.newBuilder()
.body(null)
.build())
.build();
}
// 如果不需要重定向奉件，那么 followUp 為空宵蛀，會根據(jù)響應(yīng)碼判斷
Request followUp = followUpRequest(response);
// 釋放資源，返回 response
if (followUp == null) {
if (!forWebSocket) {
streamAllocation.release();
}
return response;
}
// 關(guān)閉 response 的 body
closeQuietly(response.body());
if (++followUpCount > MAX_FOLLOW_UPS) {
streamAllocation.release();
throw new ProtocolException("Too many follow-up requests: " + followUpCount);
}
if (followUp.body() instanceof UnrepeatableRequestBody) {
streamAllocation.release();
throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
}
// response 和 followUp 比較是否為同一個連接
// 若為重定向就銷毀舊連接县貌，創(chuàng)建新連接
if (!sameConnection(response, followUp.url())) {
streamAllocation.release();
streamAllocation = new StreamAllocation(client.connectionPool(),
createAddress(followUp.url()), call, eventListener, callStackTrace);
} else if (streamAllocation.codec() != null) {
throw new IllegalStateException("Closing the body of " + response
+ " didn't close its backing stream. Bad interceptor?");
}
// 將重定向操作得到的新請求設(shè)置給 request
request = followUp;
priorResponse = response;
}
}
總體來說术陶，RetryAndFollowUpInterceptor 是用來失敗重試以及重定向的攔截器。
BridgeInterceptor
@Override
public Response intercept(Chain chain) throws IOException {
Request userRequest = chain.request();
Request.Builder requestBuilder = userRequest.newBuilder();
// 將用戶友好的 request 構(gòu)造為發(fā)送給服務(wù)器的 request
RequestBody body = userRequest.body();
// 若有請求體煤痕，則構(gòu)造
if (body != null) {
MediaType contentType = body.contentType();
if (contentType != null) {
requestBuilder.header("Content-Type", contentType.toString());
}
long contentLength = body.contentLength();
if (contentLength != -1) {
requestBuilder.header("Content-Length", Long.toString(contentLength));
requestBuilder.removeHeader("Transfer-Encoding");
} else {
requestBuilder.header("Transfer-Encoding", "chunked");
requestBuilder.removeHeader("Content-Length");
}
}
if (userRequest.header("Host") == null) {
requestBuilder.header("Host", hostHeader(userRequest.url(), false));
}
// Keep Alive
if (userRequest.header("Connection") == null) {
requestBuilder.header("Connection", "Keep-Alive");
}
// If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing
// the transfer stream.
// 使用 gzip 壓縮
boolean transparentGzip = false;
if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
transparentGzip = true;
requestBuilder.header("Accept-Encoding", "gzip");
}
// 設(shè)置 cookie
List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
if (!cookies.isEmpty()) {
requestBuilder.header("Cookie", cookieHeader(cookies));
}
// UA
if (userRequest.header("User-Agent") == null) {
requestBuilder.header("User-Agent", Version.userAgent());
}
// 構(gòu)造完后梧宫，將 request 交給下一個攔截器去處理。最后又得到服務(wù)端響應(yīng) networkResponse
Response networkResponse = chain.proceed(requestBuilder.build());
// 保存 networkResponse 的 cookie
HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());
// 將 networkResponse 構(gòu)造為對用戶友好的 response
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
// 如果 networkResponse 使用 gzip 并且有響應(yīng)體的話摆碉，給用戶友好的 response 設(shè)置響應(yīng)體
if (transparentGzip
&& "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))
&& HttpHeaders.hasBody(networkResponse)) {
GzipSource responseBody = new GzipSource(networkResponse.body().source());
Headers strippedHeaders = networkResponse.headers().newBuilder()
.removeAll("Content-Encoding")
.removeAll("Content-Length")
.build();
responseBuilder.headers(strippedHeaders);
responseBuilder.body(new RealResponseBody(strippedHeaders, Okio.buffer(responseBody)));
}
return responseBuilder.build();
}
在 BridgeInterceptor 這一步祟敛，先把用戶友好的請求進(jìn)行重新構(gòu)造，變成了向服務(wù)器發(fā)送的請求兆解。
之后調(diào)用 chain.proceed(requestBuilder.build()) 進(jìn)行下一個攔截器的處理馆铁。
等到后面的攔截器都處理完畢，得到響應(yīng)锅睛。再把 networkResponse 轉(zhuǎn)化成對用戶友好的 response 埠巨。
CacheInterceptor
@Override
public Response intercept(Chain chain) throws IOException {
// 得到 request 對應(yīng)緩存中的 response
Response cacheCandidate = cache != null
? cache.get(chain.request())
: null;
// 獲取當(dāng)前時間，會和之前緩存的時間進(jìn)行比較
long now = System.currentTimeMillis();
// 得到緩存策略
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
Request networkRequest = strategy.networkRequest;
Response cacheResponse = strategy.cacheResponse;
// 追蹤緩存现拒，其實(shí)就是計數(shù)
if (cache != null) {
cache.trackResponse(strategy);
}
// 緩存不適用辣垒，關(guān)閉
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.
// 禁止網(wǎng)絡(luò)并且沒有緩存的話，返回失敗
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 we don't need the network, we're done.
// 不用網(wǎng)絡(luò)請求印蔬，返回緩存
if (networkRequest == null) {
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
Response networkResponse = null;
try {
// 交給下一個攔截器勋桶，返回 networkResponse
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());
}
}
// 如果我們同時有緩存和 networkResponse ，根據(jù)情況使用
if (cacheResponse != null) {
if (networkResponse.code() == HTTP_NOT_MODIFIED) {
Response response = cacheResponse.newBuilder()
.headers(combine(cacheResponse.headers(), networkResponse.headers()))
.sentRequestAtMillis(networkResponse.sentRequestAtMillis())
.receivedResponseAtMillis(networkResponse.receivedResponseAtMillis())
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
networkResponse.body().close();
// 更新原來的緩存至最新
// Update the cache after combining headers but before stripping the
// Content-Encoding header (as performed by initContentStream()).
cache.trackConditionalCacheHit();
cache.update(cacheResponse, response);
return response;
} else {
closeQuietly(cacheResponse.body());
}
}
Response response = networkResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
// 保存之前未緩存的緩存
if (cache != null) {
if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
// Offer this request to the cache.
CacheRequest cacheRequest = cache.put(response);
return cacheWritingResponse(cacheRequest, response);
}
if (HttpMethod.invalidatesCache(networkRequest.method())) {
try {
cache.remove(networkRequest);
} catch (IOException ignored) {
// The cache cannot be written.
}
}
}
return response;
}
CacheInterceptor 做的事情就是根據(jù)請求拿到緩存，若沒有緩存或者緩存失效例驹，就進(jìn)入網(wǎng)絡(luò)請求階段捐韩，否則會返回緩存。
ConnectInterceptor
@Override
public Response intercept(Chain chain) throws IOException {
RealInterceptorChain realChain = (RealInterceptorChain) chain;
Request request = realChain.request();
StreamAllocation streamAllocation = realChain.streamAllocation();
// We need the network to satisfy this request. Possibly for validating a conditional GET.
boolean doExtensiveHealthChecks = !request.method().equals("GET");
// 創(chuàng)建 httpCodec （抽象類）鹃锈，分別對應(yīng)著 http1.1 和 http 2
HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks);
RealConnection connection = streamAllocation.connection();
return realChain.proceed(request, streamAllocation, httpCodec, connection);
}
這里調(diào)用了 streamAllocation.newStream 創(chuàng)建了一個 HttpCodec 的對象荤胁。
而 HttpCodec 是一個抽象類，其實(shí)現(xiàn)類分別是 Http1Codec 和 Http2Codec 屎债。相對應(yīng)的就是 HTTP/1.1 和 HTTP/2.0 仅政。
我們來看下 streamAllocation.newStream 的代碼：
public HttpCodec newStream(OkHttpClient client, boolean doExtensiveHealthChecks) {
int connectTimeout = client.connectTimeoutMillis();
int readTimeout = client.readTimeoutMillis();
int writeTimeout = client.writeTimeoutMillis();
boolean connectionRetryEnabled = client.retryOnConnectionFailure();
try {
// 在連接池中找到一個可用的連接，然后創(chuàng)建出 HttpCodec 對象
RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout,
writeTimeout, connectionRetryEnabled, doExtensiveHealthChecks);
HttpCodec resultCodec = resultConnection.newCodec(client, this);
synchronized (connectionPool) {
codec = resultCodec;
return resultCodec;
}
} catch (IOException e) {
throw new RouteException(e);
}
}
在 newStream(OkHttpClient client, boolean doExtensiveHealthChecks) 中先在連接池中找到可用的連接 resultConnection 盆驹，再結(jié)合 sink 和 source 創(chuàng)建出 HttpCodec 的對象圆丹。
CallServerInterceptor
@Override
public Response intercept(Chain chain) throws IOException {
RealInterceptorChain realChain = (RealInterceptorChain) chain;
HttpCodec httpCodec = realChain.httpStream();
StreamAllocation streamAllocation = realChain.streamAllocation();
RealConnection connection = (RealConnection) realChain.connection();
Request request = realChain.request();
long sentRequestMillis = System.currentTimeMillis();
// 整理請求頭并寫入
httpCodec.writeRequestHeaders(request);
Response.Builder responseBuilder = null;
// 檢查是否為有 body 的請求方法
if (HttpMethod.permitsRequestBody(request.method()) && request.body() != null) {
// If there's a "Expect: 100-continue" header on the request, wait for a "HTTP/1.1 100
// Continue" response before transmitting the request body. If we don't get that, return what
// we did get (such as a 4xx response) without ever transmitting the request body.
// 如果有 Expect: 100-continue 在請求頭中，那么要等服務(wù)器的響應(yīng)
if ("100-continue".equalsIgnoreCase(request.header("Expect"))) {
httpCodec.flushRequest();
responseBuilder = httpCodec.readResponseHeaders(true);
}
if (responseBuilder == null) {
// Write the request body if the "Expect: 100-continue" expectation was met.
// 寫入請求體
Sink requestBodyOut = httpCodec.createRequestBody(request, request.body().contentLength());
BufferedSink bufferedRequestBody = Okio.buffer(requestBodyOut);
request.body().writeTo(bufferedRequestBody);
bufferedRequestBody.close();
} else if (!connection.isMultiplexed()) {
// If the "Expect: 100-continue" expectation wasn't met, prevent the HTTP/1 connection from
// being reused. Otherwise we're still obligated to transmit the request body to leave the
// connection in a consistent state.
streamAllocation.noNewStreams();
}
}
httpCodec.finishRequest();
// 得到響應(yīng)頭
if (responseBuilder == null) {
responseBuilder = httpCodec.readResponseHeaders(false);
}
// 構(gòu)造 response
Response response = responseBuilder
.request(request)
.handshake(streamAllocation.connection().handshake())
.sentRequestAtMillis(sentRequestMillis)
.receivedResponseAtMillis(System.currentTimeMillis())
.build();
int code = response.code();
// 如果為 web socket 且狀態(tài)碼是 101 躯喇，那么 body 為空
if (forWebSocket && code == 101) {
// Connection is upgrading, but we need to ensure interceptors see a non-null response body.
response = response.newBuilder()
.body(Util.EMPTY_RESPONSE)
.build();
} else {
// 讀取 body
response = response.newBuilder()
.body(httpCodec.openResponseBody(response))
.build();
}
// 如果請求頭中有 close 那么斷開連接
if ("close".equalsIgnoreCase(response.request().header("Connection"))
|| "close".equalsIgnoreCase(response.header("Connection"))) {
streamAllocation.noNewStreams();
}
// 拋出協(xié)議異常
if ((code == 204 || code == 205) && response.body().contentLength() > 0) {
throw new ProtocolException(
"HTTP " + code + " had non-zero Content-Length: " + response.body().contentLength());
}
return response;
}
在 CallServerInterceptor 中可見运褪，關(guān)于請求和響應(yīng)部分都是通過 HttpCodec 來實(shí)現(xiàn)的。而在 HttpCodec 內(nèi)部又是通過 sink 和 source 來實(shí)現(xiàn)的玖瘸。所以說到底還是 IO 流在起作用。
小結(jié)
到這里檀咙，我們也完全明白了 OkHttp 中的分層思想雅倒，每一個 interceptor 只處理自己的事，而剩余的就交給其他的 interceptor 弧可。這種思想可以簡化一些繁瑣復(fù)雜的流程蔑匣，從而達(dá)到邏輯清晰、互不干擾的效果棕诵。
異步請求
與同步請求直接調(diào)用 execute() 不同的是裁良，異步請求是調(diào)用了 enqueue(Callback responseCallback) 這個方法。那么我們對異步請求探究的入口就是 enqueue(Callback responseCallback) 了校套。
RealCall
@Override
public void enqueue(Callback responseCallback) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
// 加入到 dispatcher 中价脾，這里包裝成了 AsyncCall
client.dispatcher().enqueue(new AsyncCall(responseCallback));
}
主要的方法就是調(diào)用了 Dispatcher 的 enqueue(AsyncCall call) 方法。這里需要注意的是笛匙，傳入的是 AsyncCall 對象侨把，而不是同步中的 RealCall 。
那么我們就跟進(jìn)到 Dispatcher 的源碼中吧妹孙，至于 AsyncCall 我們會在下面詳細(xì)講到秋柄。
Dispatcher
synchronized void enqueue(AsyncCall call) {
// 如果當(dāng)前正在運(yùn)行的異步 call 數(shù) < 64 && 隊列中請求同一個 host 的異步 call 數(shù) < 5
// maxRequests = 64，maxRequestsPerHost = 5
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
// 加入正在運(yùn)行異步隊列
runningAsyncCalls.add(call);
// 加入到線程池中
executorService().execute(call);
} else {
// 加入預(yù)備異步隊列
readyAsyncCalls.add(call);
}
}
// 創(chuàng)建線程池
public synchronized ExecutorService executorService() {
if (executorService == null) {
executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
}
return executorService;
}
從 enqueue(AsyncCall call) 中可以知道蠢正，OkHttp 在運(yùn)行中的異步請求數(shù)最多為 63 骇笔，而同一個 host 的異步請求數(shù)最多為 4 。否則會加入到 readyAsyncCalls 中。
在加入到 runningAsyncCalls 后笨触，就會進(jìn)入線程池中被執(zhí)行懦傍。到了這里持寄，我們就要到 AsyncCall 中一探究竟了。
AsyncCall
final class AsyncCall extends NamedRunnable {
private final Callback responseCallback;
AsyncCall(Callback responseCallback) {
super("OkHttp %s", redactedUrl());
this.responseCallback = responseCallback;
}
String host() {
return originalRequest.url().host();
}
Request request() {
return originalRequest;
}
RealCall get() {
return RealCall.this;
}
@Override
protected void execute() {
boolean signalledCallback = false;
try {
// 調(diào)用一連串的攔截器怜姿，得到響應(yīng)
Response response = getResponseWithInterceptorChain();
if (retryAndFollowUpInterceptor.isCanceled()) {
// 回調(diào)失敗
signalledCallback = true;
responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
} else {
// 回調(diào)結(jié)果
signalledCallback = true;
responseCallback.onResponse(RealCall.this, response);
}
} catch (IOException e) {
if (signalledCallback) {
// Do not signal the callback twice!
Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e);
} else {
// 回調(diào)失敗
responseCallback.onFailure(RealCall.this, e);
}
} finally {
// 在 runningAsyncCalls 中移除，并作推進(jìn)其他 call 的工作
client.dispatcher().finished(this);
}
}
}
在 AsyncCall 的 execute() 方法中迈喉，也是調(diào)用了 getResponseWithInterceptorChain() 方法來得到 Response 對象。從這里開始推沸，就和同步請求的流程是一樣的课舍，就沒必要講了庵寞。
在得到 Response 后太颤，進(jìn)行結(jié)果的回調(diào)。
最后，調(diào)用了 Dispatcher 的 finished 方法：
void finished(AsyncCall call) {
finished(runningAsyncCalls, call, true);
}
private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
int runningCallsCount;
Runnable idleCallback;
synchronized (this) {
// 移除該 call
if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
// 將 readyAsyncCalls 中的 call 移動到 runningAsyncCalls 中，并加入到線程池中
if (promoteCalls) promoteCalls();
runningCallsCount = runningCallsCount();
idleCallback = this.idleCallback;
}
if (runningCallsCount == 0 && idleCallback != null) {
idleCallback.run();
}
}
在 finished(Deque<T> calls, T call, boolean promoteCalls) 中對該 call 移除。
若在 readyAsyncCalls 中其他的 call 添履，就移動到 runningAsyncCalls 中并加入線程池中锐借。
這樣，完整的流程就循環(huán)起來了往衷。
Footer
基本上 OkHttp 的請求響應(yīng)的流程就講完了钞翔，篇幅有點(diǎn)長長長啊。
不過還有很多點(diǎn)沒有涉及到的席舍，比如連接池布轿、緩存策略等等，都是值得我們?nèi)ド罹康睦床Ｒ彩切枰ê艽蟮墓Ψ虿拍芰私馔笍亍?/p>
好了汰扭，那就到這里吧，有問題的同學(xué)可以留言福铅。
Goodbye !
