前言
OkHttp是一個非常優(yōu)秀的網(wǎng)絡(luò)請求框架。目前比較流行的Retrofit也是默認使用OkHttp的。所以O(shè)kHttp的源碼是一個不容錯過的學(xué)習資源。
基本使用
從使用方法出發(fā)，首先是怎么使用，其次是我們使用的功能在內(nèi)部是如何實現(xiàn)的.源碼地址
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();
}
Request、Response、Call 基本概念
上面的代碼中涉及到幾個常用的類：Request、Response和Call。下面分別介紹：
Request
每一個HTTP請求包含一個URL、一個方法（GET或POST或其他）、一些HTTP頭。請求還可能包含一個特定內(nèi)容類型的數(shù)據(jù)類的主體部分。
Response
響應(yīng)是對請求的回復(fù)，包含狀態(tài)碼、HTTP頭和主體部分。
Call
OkHttp使用Call抽象出一個滿足請求的模型，盡管中間可能會有多個請求或響應(yīng)。執(zhí)行Call有兩種方式，同步或異步
簡介
在早期的版本中，OkHttp支持Http1.0,1.1,SPDY協(xié)議，但是Http2協(xié)議的問世，導(dǎo)致OkHttp也做出了改變，OkHttp鼓勵開發(fā)者使用HTTP2，不再對SPDY協(xié)議給予支持。另外，新版本的OkHttp還有一個新的亮點就是支持WebScoket，這樣我們就可以非常方便的建立長連接了。
作為一個優(yōu)秀的網(wǎng)絡(luò)框架，OkHttp同樣支持網(wǎng)絡(luò)緩存，OkHttp的緩存基于DiskLruCache,DiskLruCache雖然沒有被收入到Android的源碼中，但也是谷歌推薦的一個優(yōu)秀的緩存框架。有時間可以自己學(xué)習源碼，這里不再敘述。
在安全方便，OkHttp目前支持了如上圖所示的TLS版本，以確保一個安全的Socket連接。
重試及重定向就不再說了，都知道什么意思，左上角給出了各瀏覽器或Http版本支持的重試或重定向次數(shù)。
源碼分析
OKHttpClient
首先，我們生成了一個OKHttpClient對象，注意OKHttpClient對象的構(gòu)建是用Builder（構(gòu)建者）模式來構(gòu)建的。
public OkHttpClient() {
this(new Builder());
}
public Builder() {
dispatcher = new Dispatcher();
protocols = DEFAULT_PROTOCOLS;
connectionSpecs = DEFAULT_CONNECTION_SPECS;
eventListenerFactory = EventListener.factory(EventListener.NONE);
proxySelector = ProxySelector.getDefault();
cookieJar = CookieJar.NO_COOKIES;
socketFactory = SocketFactory.getDefault();
hostnameVerifier = OkHostnameVerifier.INSTANCE;
certificatePinner = CertificatePinner.DEFAULT;
proxyAuthenticator = Authenticator.NONE;
authenticator = Authenticator.NONE;
connectionPool = new ConnectionPool();
dns = Dns.SYSTEM;
followSslRedirects = true;
followRedirects = true;
retryOnConnectionFailure = true;
connectTimeout = 10_000;
readTimeout = 10_000;
writeTimeout = 10_000;
pingInterval = 0;
}
可以看到我們簡單的一句new OkHttpClient()，OkHttp就已經(jīng)為我們做了很多工作，很多我們需要的參數(shù)在這里都獲得默認值。各字段含義如下：
- dispatcher：直譯就是調(diào)度器的意思。主要作用是通過雙端隊列保存Calls（同步&異步Call），同時在線程池中執(zhí)行異步請求。后面會詳細解析該類。
- protocols：默認支持的Http協(xié)議版本 -- Protocol.HTTP_2, Protocol.HTTP_1_1；
- connectionSpecs：OKHttp連接（Connection）配置 -- ConnectionSpec.MODERN_TLS, -ConnectionSpec.CLEARTEXT，我們分別看一下：
/** TLS 連接 */
public static final ConnectionSpec MODERN_TLS = new Builder(true)
.cipherSuites(APPROVED_CIPHER_SUITES)
.tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2, TlsVersion.TLS_1_1, TlsVersion.TLS_1_0)
.supportsTlsExtensions(true)
.build();
/** 未加密、未認證的Http連接. */
public static final ConnectionSpec CLEARTEXT = new Builder(false).build();
可以看出一個是針對TLS連接的配置，一個是針對普通的Http連接的配置；
- eventListenerFactory ：一個Call的狀態(tài)監(jiān)聽器，注意這個是okhttp新添加的功能，目前還不是最終版，在后面的版本中會發(fā)生改變的。
- proxySelector ：使用默認的代理選擇器；
- cookieJar：默認是沒有Cookie的；
- socketFactory：使用默認的Socket工廠產(chǎn)生Socket；
- hostnameVerifier、 certificatePinner、 proxyAuthenticator、 authenticator：安全相關(guān)的設(shè)置；
- connectionPool ：連接池；后面會詳細介紹；
- dns:這個一看就知道，域名解析系統(tǒng) domain name -> ip address；
- pingInterval :這個就和WebSocket有關(guān)了。為了保持長連接，我們必須間隔一段時間發(fā)送一個ping指令進行?；睿?/li>
RealCall
在我們定義了請求對象request之后，我們需要生成一個Call對象，該對象代表了一個準備被執(zhí)行的請求。Call是可以被取消的。Call對象代表了一個request/response 對（Stream）.還有就是一個Call只能被執(zhí)行一次。執(zhí)行同步請求，代碼如下（RealCall的execute方法）：
@Override public Response execute() throws IOException {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
eventListener.callStart(this);
try {
client.dispatcher().executed(this);
Response result = getResponseWithInterceptorChain();
if (result == null) throw new IOException("Canceled");
return result;
} catch (IOException e) {
eventListener.callFailed(this, e);
throw e;
} finally {
client.dispatcher().finished(this);
}
}
首先如果executed等于true，說明已經(jīng)被執(zhí)行，如果再次調(diào)用執(zhí)行就拋出異常。這說明了一個Call只能被執(zhí)行。注意此處同步請求與異步請求生成的Call對象的區(qū)別，執(zhí)行
異步請求代碼如下（RealCall的enqueue方法）：
@Override public void enqueue(Callback responseCallback) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
eventListener.callStart(this);
client.dispatcher().enqueue(new AsyncCall(responseCallback));
}
可以看到同步請求生成的是RealCall對象，而異步請求生成的是AsyncCall對象。AsyncCall說到底其實就是Runnable的子類。
接著上面繼續(xù)分析，如果可以執(zhí)行，則對當前請求添加監(jiān)聽器等操作，然后將請求Call對象放入調(diào)度器Dispatcher中。最后由攔截器鏈中的各個攔截器來對該請求進行處理，返回最終的Response。
Dispatcher -- 調(diào)度器
Dispatcher是保存同步和異步Call的地方，并負責執(zhí)行異步AsyncCall。
public final class Dispatcher {
/** 最大并發(fā)請求數(shù)為64 */
private int maxRequests = 64;
/** 每個主機最大請求數(shù)為5 */
private int maxRequestsPerHost = 5;
/** 線程池 */
private ExecutorService executorService;
/** 準備執(zhí)行的請求 */
private final Deque<AsyncCall> readyAsyncCalls = new ArrayDeque<>();
/** 正在執(zhí)行的異步請求，包含已經(jīng)取消但未執(zhí)行完的請求 */
private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();
/** 正在執(zhí)行的同步請求，包含已經(jīng)取消單未執(zhí)行完的請求 */
private final Deque<RealCall> runningSyncCalls = new ArrayDeque<>();
針對同步請求，Dispatcher使用了一個Deque保存了同步任務(wù)；針對異步請求，Dispatcher使用了兩個Deque，一個保存準備執(zhí)行的請求，一個保存正在執(zhí)行的請求，為什么要用兩個呢？因為Dispatcher默認支持最大的并發(fā)請求是64個，單個Host最多執(zhí)行5個并發(fā)請求，如果超過，則Call會先被放入到readyAsyncCall中，當出現(xiàn)空閑的線程時，再將readyAsyncCall中的線程移入到runningAsynCalls中，執(zhí)行請求。先看Dispatcher的流程，跟著流程讀源碼：
在OkHttp，使用如下構(gòu)造了單例線程池
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;
}
構(gòu)造一個線程池ExecutorService：
executorService = new ThreadPoolExecutor(
//corePoolSize 最小并發(fā)線程數(shù),如果是0的話，空閑一段時間后所有線程將全部被銷毀
0,
//maximumPoolSize: 最大線程數(shù)，當任務(wù)進來時可以擴充的線程最大值，當大于了這個值就會根據(jù)丟棄處理機制來處理
Integer.MAX_VALUE,
//keepAliveTime: 當線程數(shù)大于corePoolSize時，多余的空閑線程的最大存活時間
60,
//單位秒
TimeUnit.SECONDS,
//工作隊列,先進先出
new SynchronousQueue<Runnable>(),
//單個線程的工廠
Util.threadFactory("OkHttp Dispatcher", false));
可以看出，在Okhttp中，構(gòu)建了一個核心為[0, Integer.MAX_VALUE]的線程池，它不保留任何最小線程數(shù)，隨時創(chuàng)建更多的線程數(shù)，當線程空閑時只能活60秒，它使用了一個不存儲元素的阻塞工作隊列，一個叫做”O(jiān)kHttp Dispatcher”的線程工廠。
也就是說，在實際運行中，當收到10個并發(fā)請求時，線程池會創(chuàng)建十個線程，當工作完成后，線程池會在60s后相繼關(guān)閉所有線程。
synchronized void enqueue(AsyncCall call) {
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
runningAsyncCalls.add(call);
executorService().execute(call);
} else {
readyAsyncCalls.add(call);
}
}
可以看到如果正在執(zhí)行的請求總數(shù)<=64 && 單個Host正在執(zhí)行的請求<=5，則將請求加入到runningAsyncCalls集合中，緊接著就是利用線程池執(zhí)行該請求，否則就將該請求放入readyAsyncCalls集合中。上面我們已經(jīng)說了，AsyncCall是Runnable的子類（間接），因此，在線程池中最終會調(diào)用AsyncCall的execute（）方法執(zhí)行異步請求：
@Override protected void execute() {
boolean signalledCallback = false;
try {
Response response = getResponseWithInterceptorChain();//攔截器鏈
if (retryAndFollowUpInterceptor.isCanceled()) {//重試失敗，回調(diào)onFailure方法
signalledCallback = true;
responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
} else {
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 {
eventListener.callFailed(RealCall.this, e);
responseCallback.onFailure(RealCall.this, e);
}
} finally {
client.dispatcher().finished(this);//結(jié)束
}
}
此處的執(zhí)行邏輯和同步的執(zhí)行邏輯基本相同，區(qū)別在最后一句代碼：client.dispatcher().finished(this);因為這是一個異步任務(wù)，所以會調(diào)用另外一個finish方法：
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) {
if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");//將請求移除集合
if (promoteCalls) promoteCalls();
...
}
...
}
可以看到最后一個參數(shù)是true，這意味著需要執(zhí)行promoteCalls方法：
private void promoteCalls() {
if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity.
if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote.
for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {
AsyncCall call = i.next();
if (runningCallsForHost(call) < maxRequestsPerHost) {
i.remove();
runningAsyncCalls.add(call);
executorService().execute(call);
}
if (runningAsyncCalls.size() >= maxRequests) return; // Reached max capacity.
}
}
該方法主要是遍歷執(zhí)行readyRunningCalls集合中待執(zhí)行的請求，當然前提是正在執(zhí)行的Call總數(shù)沒有超過64，并且readyAsyncCalls集合不為空。如果readyAsyncCalls集合為空，則意味著請求差不多都執(zhí)行了。放入runningAsyncCalls集合中的請求會繼續(xù)走上述的流程，直到全部的請求被執(zhí)行。
InterceptorChain（攔截器鏈）
在介紹RealCall 中源碼的時候
client.dispatcher().executed(this);
Response result = getResponseWithInterceptorChain();
上面已經(jīng)介紹了分發(fā)器Dispatcher
下面就介紹核心重點 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、retryAndFollowUpInterceptor、BridgeInterceptor、CacheInterceptor、ConnectInterceptor、 networkInterceptors、CallServerInterceptor，并將這些攔截器傳遞給了這個RealInterceptorChain。
1）在配置 OkHttpClient 時設(shè)置的 interceptors；
2）負責失敗重試以及重定向的 RetryAndFollowUpInterceptor；
3）負責把用戶構(gòu)造的請求轉(zhuǎn)換為發(fā)送到服務(wù)器的請求、把服務(wù)器返回的響應(yīng)轉(zhuǎn)換為用戶友好的響應(yīng)的 BridgeInterceptor；
4）負責讀取緩存直接返回、更新緩存的 CacheInterceptor；
5）負責和服務(wù)器建立連接的 ConnectInterceptor；
6）配置 OkHttpClient 時設(shè)置的 networkInterceptors；
7）負責向服務(wù)器發(fā)送請求數(shù)據(jù)、從服務(wù)器讀取響應(yīng)數(shù)據(jù)的 CallServerInterceptor。
OkHttp的這種攔截器鏈采用的是責任鏈模式，這樣的好處是將請求的發(fā)送和處理分開，并且可以動態(tài)添加中間的處理方實現(xiàn)對請求的處理、短路等操作。
從上述源碼得知，不管okhttp有多少攔截器最后都會走，如下方法：
Interceptor.Chain chain = new RealInterceptorChain(
interceptors, null, null, null, 0, originalRequest);
return chain.proceed(originalRequest);
從方法名字基本可以猜到是干嘛的，調(diào)用 chain.proceed(originalRequest); 將request傳遞進來，從攔截器鏈里拿到返回結(jié)果。那么攔截器Interceptor是干嘛的，Chain是干嘛的呢？繼續(xù)往下看RealInterceptorChain
RealInterceptorChain類
下面是RealInterceptorChain的定義，該類實現(xiàn)了Chain接口，在getResponseWithInterceptorChain調(diào)用時好幾個參數(shù)都傳的null。
public final class RealInterceptorChain implements Interceptor.Chain {
public RealInterceptorChain(List<Interceptor> interceptors, StreamAllocation streamAllocation,
HttpCodec httpCodec, RealConnection connection, int index, Request request) {
this.interceptors = interceptors;
this.connection = connection;
this.streamAllocation = streamAllocation;
this.httpCodec = httpCodec;
this.index = index;
this.request = request;
}
......
@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 {
if (index >= interceptors.size()) throw new AssertionError();
calls++;
......
// 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;
}
protected abstract void execute();
}
主要看proceed方法，proceed方法中判斷index（此時為0）是否大于或者等于client.interceptors(List )的大小。由于httpStream為null，所以首先創(chuàng)建next攔截器鏈，主需要把索引置為index+1即可；然后獲取第一個攔截器，調(diào)用其intercept方法。
Interceptor 代碼如下：
public interface Interceptor {
Response intercept(Chain chain) throws IOException;
interface Chain {
Request request();
Response proceed(Request request) throws IOException;
Connection connection();
}
}
RetryAndFollowUpInterceptor
負責失敗重試以及重定向
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
streamAllocation = new StreamAllocation(
client.connectionPool(), createAddress(request.url()));
int followUpCount = 0;
Response priorResponse = null;
while (true) {
if (canceled) {
streamAllocation.release();
throw new IOException("Canceled");
}
Response response = null;
boolean releaseConnection = true;
try {
response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null); //(1)
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(), true, 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ā)送。
if (!recover(e, false, 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.
// 附加上先前存在的response。這樣的response從來沒有body
// TODO: 2016/8/23 這里沒賦值，豈不是一直為空？
if (priorResponse != null) { // (2)
response = response.newBuilder()
.priorResponse(priorResponse.newBuilder()
.body(null)
.build())
.build();
}
Request followUp = followUpRequest(response); //判斷狀態(tài)碼 (3)
if (followUp == null){
if (!forWebSocket) {
streamAllocation.release();
}
return response;
}
closeQuietly(response.body());
if (++followUpCount > MAX_FOLLOW_UPS) {
streamAllocation.release();
throw new ProtocolException("Too many follow-up requests: " + followUpCount);
}
if (followUp.body() instanceof UnrepeatableRequestBody) {
throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
}
if (!sameConnection(response, followUp.url())) {
streamAllocation.release();
streamAllocation = new StreamAllocation(
client.connectionPool(), createAddress(followUp.url()));
} else if (streamAllocation.codec() != null) {
throw new IllegalStateException("Closing the body of " + response
+ " didn't close its backing stream. Bad interceptor?");
}
request = followUp;
priorResponse = response;
}
}
這里是最關(guān)鍵的代碼，可以看出在response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);中直接調(diào)用了下一個攔截器，然后捕獲可能的異常來進行操作
這里對于返回的response的狀態(tài)碼進行判斷，然后進行處理
BridgeInterceptor
BridgeInterceptor從用戶的請求構(gòu)建網(wǎng)絡(luò)請求，然后提交給網(wǎng)絡(luò)，最后從網(wǎng)絡(luò)響應(yīng)中提取出用戶響應(yīng)。從最上面的圖可以看出，BridgeInterceptor實現(xiàn)了適配的功能。下面是其intercept方法：
public final class BridgeInterceptor implements Interceptor {
......
@Override
public Response intercept(Chain chain) throws IOException {
Request userRequest = chain.request();
Request.Builder requestBuilder = userRequest.newBuilder();
RequestBody body = userRequest.body();
//如果存在請求主體部分，那么需要添加Content-Type、Content-Length首部
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));
}
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.
boolean transparentGzip = false;
if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
transparentGzip = true;
requestBuilder.header("Accept-Encoding", "gzip");
}
List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
if (!cookies.isEmpty()) {
requestBuilder.header("Cookie", cookieHeader(cookies));
}
if (userRequest.header("User-Agent") == null) {
requestBuilder.header("User-Agent", Version.userAgent());
}
Response networkResponse = chain.proceed(requestBuilder.build());
HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
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();
}
/** Returns a 'Cookie' HTTP request header with all cookies, like {@code a=b; c=d}. */
private String cookieHeader(List<Cookie> cookies) {
StringBuilder cookieHeader = new StringBuilder();
for (int i = 0, size = cookies.size(); i < size; i++) {
if (i > 0) {
cookieHeader.append("; ");
}
Cookie cookie = cookies.get(i);
cookieHeader.append(cookie.name()).append('=').append(cookie.value());
}
return cookieHeader.toString();
}
}
上面的代碼可以看出，首先獲取原請求，然后在請求中添加頭，比如Host、Connection、Accept-Encoding參數(shù)等，然后根據(jù)看是否需要填充Cookie，在對原始請求做出處理后，使用chain的procced方法得到響應(yīng)，接下來對響應(yīng)做處理得到用戶響應(yīng)，最后返回響應(yīng)。
CacheInterceptor
@Override
public Response intercept(Chain chain) throws IOException {
Response cacheCandidate = cache != null
? cache.get(chain.request()) //通過request得到緩存
: null;
long now = System.currentTimeMillis();
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get(); //根據(jù)request來得到緩存策略
Request networkRequest = strategy.networkRequest;
Response cacheResponse = strategy.cacheResponse;
if (cache != null) {
cache.trackResponse(strategy);
}
if (cacheCandidate != null && cacheResponse == null) { //存在緩存的response，但是不允許緩存
closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it. 緩存不適合，關(guān)閉
}
// If we're forbidden from using the network and the cache is insufficient, fail.
//如果我們禁止使用網(wǎng)絡(luò)，且緩存為null，失敗
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(EMPTY_BODY)
.sentRequestAtMillis(-1L)
.receivedResponseAtMillis(System.currentTimeMillis())
.build();
}
// If we don't need the network, we're done.
if (networkRequest == null) { //沒有網(wǎng)絡(luò)請求，跳過網(wǎng)絡(luò)，返回緩存
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
Response networkResponse = null;
try {
networkResponse = chain.proceed(networkRequest);//網(wǎng)絡(luò)請求攔截器 //
} finally {
// If we're crashing on I/O or otherwise, don't leak the cache body.
//如果我們因為I/O或其他原因崩潰，不要泄漏緩存體
if (networkResponse == null && cacheCandidate != null) {
closeQuietly(cacheCandidate.body());
}
}
// If we have a cache response too, then we're doing a conditional get.
//如果我們有一個緩存的response，然后我們正在做一個條件GET
if (cacheResponse != null) {
if (validate(cacheResponse, networkResponse)) { //比較確定緩存response可用
Response response = cacheResponse.newBuilder()
.headers(combine(cacheResponse.headers(), networkResponse.headers()))
.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()).
//更新緩存，在剝離content-Encoding之前
cache.trackConditionalCacheHit();
cache.update(cacheResponse, response);
return response;
} else {
closeQuietly(cacheResponse.body());
}
}
Response response = networkResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
if (HttpHeaders.hasBody(response)) {
CacheRequest cacheRequest = maybeCache(response, networkResponse.request(), cache);
response = cacheWritingResponse(cacheRequest, response);
}
return response;
}
- 首先，根據(jù)request來判斷cache中是否有緩存的response，如果有，得到這個response，然后進行判斷當前response是否有效，沒有將cacheCandate賦值為空。
- 根據(jù)request判斷緩存的策略，是否要使用了網(wǎng)絡(luò)，緩存 或兩者都使用
- 調(diào)用下一個攔截器，決定從網(wǎng)絡(luò)上來得到response
- 如果本地已經(jīng)存在cacheResponse，那么讓它和網(wǎng)絡(luò)得到的networkResponse做比較，決定是否來更新緩存的cacheResponse
- 緩存未經(jīng)緩存過的response
ConnectInterceptor
public final class ConnectInterceptor implements Interceptor {
......
@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");
HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks);
RealConnection connection = streamAllocation.connection();
return realChain.proceed(request, streamAllocation, httpCodec, connection);
}
}
實際上建立連接就是創(chuàng)建了一個HttpCodec對象，它將在后面的步驟中被使用，那它又是何方神圣呢？它是對 HTTP 協(xié)議操作的抽象，有兩個實現(xiàn)：Http1Codec和Http2Codec，顧名思義，它們分別對應(yīng) HTTP/1.1 和 HTTP/2 版本的實現(xiàn)。
在Http1Codec中，它利用 Okio 對Socket的讀寫操作進行封裝，Okio 以后有機會再進行分析，現(xiàn)在讓我們對它們保持一個簡單地認識：它對java.io和java.nio進行了封裝，讓我們更便捷高效的進行 IO 操作。
而創(chuàng)建HttpCodec對象的過程涉及到StreamAllocation、RealConnection，代碼較長，這里就不展開，這個過程概括來說，就是找到一個可用的RealConnection，再利用RealConnection的輸入輸出（BufferedSource和BufferedSink）創(chuàng)建HttpCodec對象，供后續(xù)步驟使用。
NetworkInterceptors
配置OkHttpClient時設(shè)置的 NetworkInterceptors。
CallServerInterceptor
CallServerInterceptor是攔截器鏈中最后一個攔截器，負責將網(wǎng)絡(luò)請求提交給服務(wù)器。它的intercept方法實現(xiàn)如下：
@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;
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.
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();
if (responseBuilder == null) {
responseBuilder = httpCodec.readResponseHeaders(false);
}
Response response = responseBuilder
.request(request)
.handshake(streamAllocation.connection().handshake())
.sentRequestAtMillis(sentRequestMillis)
.receivedResponseAtMillis(System.currentTimeMillis())
.build();
int code = response.code();
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 {
response = response.newBuilder()
.body(httpCodec.openResponseBody(response))
.build();
}
if ("close".equalsIgnoreCase(response.request().header("Connection"))
|| "close".equalsIgnoreCase(response.header("Connection"))) {
streamAllocation.noNewStreams();
}
if ((code == 204 || code == 205) && response.body().contentLength() > 0) {
throw new ProtocolException(
"HTTP " + code + " had non-zero Content-Length: " + response.body().contentLength());
}
return response;
}
從上面的代碼中可以看出，首先獲取HttpStream對象，然后調(diào)用writeRequestHeaders方法寫入請求的頭部，然后判斷是否需要寫入請求的body部分，最后調(diào)用finishRequest()方法將所有數(shù)據(jù)刷新給底層的Socket，接下來嘗試調(diào)用readResponseHeaders()方法讀取響應(yīng)的頭部，然后再調(diào)用openResponseBody()方法得到響應(yīng)的body部分，最后返回響應(yīng)。
總結(jié)
OkHttp的底層是通過Java的Socket發(fā)送HTTP請求與接受響應(yīng)的(這也好理解，HTTP就是基于TCP協(xié)議的)，但是OkHttp實現(xiàn)了連接池的概念，即對于同一主機的多個請求，其實可以公用一個Socket連接，而不是每次發(fā)送完HTTP請求就關(guān)閉底層的Socket，這樣就實現(xiàn)了連接池的概念。而OkHttp對Socket的讀寫操作使用的OkIo庫進行了一層封裝。
總體流程圖：
總體架構(gòu)圖：
