關於作者
郭孝星，程式設計師，吉他手，主要從事Android平臺基礎架構方面的工作，歡迎交流技術方面的問題，可以去我的Github提issue或者發郵件至guoxiaoxingse@163.com與我交流。
文章目錄
- 一 請求與響應流程
- 1.1 請求的封裝
- 1.2 請求的傳送
- 1.3 請求的排程
- 二 攔截器
- 2.1 RetryAndFollowUpInterceptor
- 2.2 BridgeInterceptor
- 2.3 CacheInterceptor
- 2.4 ConnectInterceptor
- 2.5 CallServerInterceptor
- 三 連線機制
- 3.1 建立連線
- 3.2 連線池
- 四 快取機制
- 4.1 快取策略
- 4.2 快取管理
更多Android開源框架原始碼分析文章請參見Android open framework analysis。
在Android刀耕火種的哪個年代，我們做網路請求通常會選用HttpURLConnection或者Apache HTTP Client，這兩者均支援HTTPS、流的上傳和下載、配置超時和連線池等特性，但隨著業務場景的負責化以及 對流量消耗的優化需求，Okhttp應運而生，自誕生起，口碑就一直很好。
但是，大家都說好，好在哪裡？既然這麼好，它的設計理念和實現思路有哪些值得我們學習的地方？?
今天就帶著這些問題，一探究竟。
An HTTP+HTTP/2 client for Android and Java applications.
官方網站：https://github.com/square/okhttp
原始碼版本：3.9.1
在正式分析原始碼之前，我們先來看個簡單的小例子，從例子入手，逐步分析Okhttp的實現。
? 舉例
OkHttpClient okHttpClient = new OkHttpClient.Builder()
.build();
Request request = new Request.Builder()
.url(url)
.build();
okHttpClient.newCall(request).enqueue(new Callback() {
@Override
public void onFailure(Call call, IOException e) {
}
@Override
public void onResponse(Call call, Response response) throws IOException {
}
});
複製程式碼在上面的例子中，我們構建了一個客戶端OkHttpClient和一個請求Request，然後呼叫newCall()方法將請求傳送了出去。從這個小例子中，我們可以發現 OkHttpClient相當於是個上下文或者說是大管家，它接到我們給的任務以後，將具體的工作分發到各個子系統中去完成。
Okhttp的子系統層級結構圖如下所示：
? 點選圖片檢視大圖
- 網路配置層：利用Builder模式配置各種引數，例如：超時時間、攔截器等，這些引數都會由Okhttp分發給各個需要的子系統。
- 重定向層：負責重定向。
- Header拼接層：負責把使用者構造的請求轉換為傳送給伺服器的請求，把伺服器返回的響應轉換為對使用者友好的響應。
- HTTP快取層：負責讀取快取以及更新快取。
- 連線層：連線層是一個比較複雜的層級，它實現了網路協議、內部的攔截器、安全性認證，連線與連線池等功能，但這一層還沒有發起真正的連線，它只是做了聯結器一些引數的處理。
- 資料響應層：負責從伺服器讀取響應的資料。
在整個Okhttp的系統中，我們還要理解以下幾個關鍵角色：
- OkHttpClient：通訊的客戶端，用來統一管理髮起請求與解析響應。
- Call：Call是一個介面，它是HTTP請求的抽象描述，具體實現類是RealCall，它由CallFactory建立。
- Request：請求，封裝請求的具體資訊，例如：url、header等。
- RequestBody：請求體，用來提交流、表單等請求資訊。
- Response：HTTP請求的響應，獲取響應資訊，例如：響應header等。
- ResponseBody：HTTP請求的響應體，被讀取一次以後就會關閉，所以我們重複呼叫responseBody.string()獲取請求結果是會報錯的。
- Interceptor：Interceptor是請求攔截器，負責攔截並處理請求，它將網路請求、快取、透明壓縮等功能都統一起來，每個功能都是一個Interceptor，所有的Interceptor最 終連線成一個Interceptor.Chain。典型的責任鏈模式實現。
- StreamAllocation：用來控制Connections與Streas的資源分配與釋放。
- RouteSelector：選擇路線與自動重連。
- RouteDatabase：記錄連線失敗的Route黑名單。
我們首先來分析連線的請求與響應流程，這樣我們就可以對整個Okhttp系統有一個整體的認識。
一 請求與響應流程
Okhttp的整個請求與響應的流程就是Dispatcher不斷從Request Queue裡取出請求（Call），根據是否已經存存快取，從記憶體快取或者伺服器獲取請求的資料，請求分為同步和非同步兩種，同步請求通過 呼叫Call.exectute()方法直接返回當前請求的Response，非同步請求呼叫Call.enqueue()方法將請求（AsyncCall）新增到請求佇列中去，並通過回撥（Callback）獲取伺服器返回的結果。
一圖勝千言，我們來看一下整個的流程圖，如下所示：
? 點選圖片檢視大圖
讀者仔細看一下這個流程圖，是不是很像計算機網路的OSI七層模型，Okhttp正式採用這種思路，利用攔截器Interceptor將整套框架縱向分層，簡化了設計邏輯，提升了框架擴充套件性。
通過上面的流程圖，我們可以知道在整個請求與響應流程中，以下幾點是我們需要重點關注的：
- Dispatcher是如何進行請求排程的？
- 各個攔截器是如何實現的？
- 連線與連線池是如何建立和維護的？
帶著以上問題，我們去原始碼中一探究竟。
我們先來看一下具體的函式呼叫鏈，請求與響應的序列圖如下所示：
? 點選圖片檢視大圖
上述序列圖可以幫助我們理解整個請求與響應流程的具體細節，我們首先來看一下一個請求和如何被封裝併發出的。
1.1 請求的封裝
請求是由Okhttp發出，真正的請求都被封裝了在了介面Call的實現類RealCall中，如下所示：
Call介面如下所示：
public interface Call extends Cloneable {
//返回當前請求
Request request();
//同步請求方法，此方法會阻塞當前執行緒知道請求結果放回
Response execute() throws IOException;
//非同步請求方法，此方法會將請求新增到佇列中，然後等待請求返回
void enqueue(Callback responseCallback);
//取消請求
void cancel();
//請求是否在執行，當execute()或者enqueue(Callback responseCallback)執行後該方法返回true
boolean isExecuted();
//請求是否被取消
boolean isCanceled();
//建立一個新的一模一樣的請求
Call clone();
interface Factory {
Call newCall(Request request);
}
}
複製程式碼RealCall的構造方法如下所示：
final class RealCall implements Call {
private RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
//我們構建的OkHttpClient，用來傳遞引數
this.client = client;
this.originalRequest = originalRequest;
//是不是WebSocket請求，WebSocket是用來建立長連線的，後面我們會說。
this.forWebSocket = forWebSocket;
//構建RetryAndFollowUpInterceptor攔截器
this.retryAndFollowUpInterceptor = new RetryAndFollowUpInterceptor(client, forWebSocket);
}
}
複製程式碼RealCall實現了Call介面，它封裝了請求的呼叫，這個建構函式的邏輯也很簡單：賦值外部傳入的OkHttpClient、Request與forWebSocket，並 建立了重試與重定向攔截器RetryAndFollowUpInterceptor。
1.2 請求的傳送
RealCall將請求分為兩種：
- 同步請求
- 非同步請求
非同步請求只是比同步請求多了個Callback，分別呼叫的方法如下所示：
非同步請求
final class RealCall implements Call {
@Override public void enqueue(Callback responseCallback) {
synchronized (this) {
if (executed) throw new IllegalStateException("Already Executed");
executed = true;
}
captureCallStackTrace();
client.dispatcher().enqueue(new AsyncCall(responseCallback));
}
}
複製程式碼同步請求
final class RealCall implements Call {
@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);
}
}
}
複製程式碼從上面實現可以看出，不管是同步請求還是非同步請求都是Dispatcher在處理：
- 同步請求：直接執行，並返回請求結果
- 非同步請求：構造一個AsyncCall，並將自己加入處理佇列中。
AsyncCall本質上是一個Runable，Dispatcher會排程ExecutorService來執行這些Runable。
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 {
Response response = getResponseWithInterceptorChain();
if (retryAndFollowUpInterceptor.isCanceled()) {
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 {
responseCallback.onFailure(RealCall.this, e);
}
} finally {
client.dispatcher().finished(this);
}
}
}
複製程式碼從上面程式碼可以看出，不管是同步請求還是非同步請求最後都會通過getResponseWithInterceptorChain()獲取Response，只不過非同步請求多了個執行緒排程，非同步 執行的過程。
我們先來來看看Dispatcher裡的實現。
1.3 請求的排程
public final class Dispatcher {
private int maxRequests = 64;
private int maxRequestsPerHost = 5;
/** Ready async calls in the order they'll be run. */
private final Deque<AsyncCall> readyAsyncCalls = new ArrayDeque<>();
/** Running asynchronous calls. Includes canceled calls that haven't finished yet. */
private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();
/** Running synchronous calls. Includes canceled calls that haven't finished yet. */
private final Deque<RealCall> runningSyncCalls = new ArrayDeque<>();
/** Used by {@code Call#execute} to signal it is in-flight. */
synchronized void executed(RealCall call) {
runningSyncCalls.add(call);
}
synchronized void enqueue(AsyncCall call) {
//正在執行的非同步請求不得超過64，同一個host下的非同步請求不得超過5個
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
runningAsyncCalls.add(call);
executorService().execute(call);
} else {
readyAsyncCalls.add(call);
}
}
}
複製程式碼Dispatcher是一個任務排程器，它內部維護了三個雙端佇列：
- readyAsyncCalls：準備執行的非同步請求
- runningAsyncCalls：正在執行的非同步請求
- runningSyncCalls：正在執行的同步請求
記得非同步請求與同步騎牛，並利用ExecutorService來排程執行AsyncCall。
同步請求就直接把請求新增到正在執行的同步請求佇列runningSyncCalls中，非同步請求會做個判斷：
如果正在執行的非同步請求不超過64，而且同一個host下的非同步請求不得超過5個則將請求新增到正在執行的同步請求佇列中runningAsyncCalls並開始 執行請求，否則就新增到readyAsyncCalls繼續等待。
講完Dispatcher裡的實現，我們繼續來看getResponseWithInterceptorChain()的實現，這個方法才是真正發起請求並處理請求的地方。
1.4 請求的處理
final class RealCall implements Call {
Response getResponseWithInterceptorChain() throws IOException {
// Build a full stack of interceptors.
List<Interceptor> interceptors = new ArrayList<>();
//這裡可以看出，我們自定義的Interceptor會被優先執行
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將網路請求、快取、透明壓縮等功能統一了起來，它的實現採用責任鏈模式，各司其職， 每個功能都是一個Interceptor，上一級處理完成以後傳遞給下一級，它們最後連線成了一個Interceptor.Chain。它們的功能如下：
- RetryAndFollowUpInterceptor：負責重定向。
- BridgeInterceptor：負責把使用者構造的請求轉換為傳送給伺服器的請求，把伺服器返回的響應轉換為對使用者友好的響應。
- CacheInterceptor：負責讀取快取以及更新快取。
- ConnectInterceptor：負責與伺服器建立連線。
- CallServerInterceptor：負責從伺服器讀取響應的資料。
位置決定功能，位置靠前的先執行，最後一個則複製與伺服器通訊，請求從RetryAndFollowUpInterceptor開始層層傳遞到CallServerInterceptor，每一層 都對請求做相應的處理，處理的結構再從CallServerInterceptor層層返回給RetryAndFollowUpInterceptor，最紅請求的發起者獲得了伺服器返回的結果。
以上便是Okhttp整個請求與響應的具體流程，可以發現攔截器才是Okhttp核心功能所在，我們來逐一分析每個攔截器的實現。
二 攔截器
從上面的流程可以看出，各個環節都是由相應的攔截器進行處理，所有的攔截器（包括我們自定義的）都實現了Interceptor介面，如下所示：
public interface Interceptor {
Response intercept(Chain chain) throws IOException;
interface Chain {
Request request();
Response proceed(Request request) throws IOException;
//返回Request執行後返回的連線
@Nullable Connection connection();
}
}
複製程式碼Okhttp內建的攔截器如下所示：
- RetryAndFollowUpInterceptor：負責失敗重試以及重定向。
- BridgeInterceptor：負責把使用者構造的請求轉換為傳送給伺服器的請求，把伺服器返回的響應轉換為對使用者友好的響應。
- CacheInterceptor：負責讀取快取以及更新快取。
- ConnectInterceptor：負責與伺服器建立連線。
- CallServerInterceptor：負責從伺服器讀取響應的資料。
我們繼續來看看RealInterceptorChain裡是怎麼一級級處理的。
public final class RealInterceptorChain implements Interceptor.Chain {
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");
}
// 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);
// Confirm that the next interceptor made its required call to 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");
}
return response;
}
}
複製程式碼這個方法比較有意思，在呼叫proceed方法之後，會繼續構建一個新的RealInterceptorChain物件，呼叫下一個interceptor來繼續請求，直到所有interceptor都處理完畢，將 得到的response返回。
每個攔截器的方法都遵循這樣的規則：
@Override public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
//1 Request階段，該攔截器在Request階段負責做的事情
//2 呼叫RealInterceptorChain.proceed()，其實是在遞迴呼叫下一個攔截器的intercept()方法
response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
//3 Response階段，完成了該攔截器在Response階段負責做的事情，然後返回到上一層的攔截器。
return response;
}
}
複製程式碼從上面的描述可知，Request是按照interpretor的順序正向處理，而Response是逆向處理的。這參考了OSI七層模型的原理。上面我們也提到過。CallServerInterceptor相當於最底層的物理層， 請求從上到逐層包裝下發，響應從下到上再逐層包裝返回。很漂亮的設計。
interceptor的執行順序：RetryAndFollowUpInterceptor -> BridgeInterceptor -> CacheInterceptor -> ConnectInterceptor -> CallServerInterceptor。
2.1 RetryAndFollowUpInterceptor
RetryAndFollowUpInterceptor負責失敗重試以及重定向。
public final class RetryAndFollowUpInterceptor implements Interceptor {
private static final int MAX_FOLLOW_UPS = 20;
@Override public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
//1. 構建一個StreamAllocation物件，StreamAllocation相當於是個管理類，維護了
//Connections、Streams和Calls之間的管理，該類初始化一個Socket連線物件，獲取輸入/輸出流物件。
streamAllocation = new StreamAllocation(
client.connectionPool(), createAddress(request.url()), callStackTrace);
//重定向次數
int followUpCount = 0;
Response priorResponse = null;
while (true) {
if (canceled) {
streamAllocation.release();
throw new IOException("Canceled");
}
Response response = null;
boolean releaseConnection = true;
try {
//2. 繼續執行下一個Interceptor，即BridgeInterceptor
response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
releaseConnection = false;
} catch (RouteException e) {
//3. 丟擲異常，則檢測連線是否還可以繼續。
if (!recover(e.getLastConnectException(), false, request)) {
throw e.getLastConnectException();
}
releaseConnection = false;
continue;
} catch (IOException e) {
// 和服務端建立連線失敗
boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
if (!recover(e, requestSendStarted, request)) throw e;
releaseConnection = false;
continue;
} finally {
//檢測到其他未知異常，則釋放連線和資源
if (releaseConnection) {
streamAllocation.streamFailed(null);
streamAllocation.release();
}
}
//構建響應體，這個響應體的body為空。
if (priorResponse != null) {
response = response.newBuilder()
.priorResponse(priorResponse.newBuilder()
.body(null)
.build())
.build();
}
//4。根據響應碼處理請求，返回Request不為空時則進行重定向處理。
Request followUp = followUpRequest(response);
if (followUp == null) {
if (!forWebSocket) {
streamAllocation.release();
}
return response;
}
closeQuietly(response.body());
//重定向的次數不能超過20次
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());
}
if (!sameConnection(response, followUp.url())) {
streamAllocation.release();
streamAllocation = new StreamAllocation(
client.connectionPool(), createAddress(followUp.url()), callStackTrace);
} 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;
}
}
}
複製程式碼我們先來說說StreamAllocation這個類的作用，這個類協調了三個實體類的關係：
- Connections：連線到遠端伺服器的物理套接字，這個套接字連線可能比較慢，所以它有一套取消機制。
- Streams：定義了邏輯上的HTTP請求/響應對，每個連線都定義了它們可以攜帶的最大併發流，HTTP/1.x每次只可以攜帶一個，HTTP/2每次可以攜帶多個。
- Calls：定義了流的邏輯序列，這個序列通常是一個初始請求以及它的重定向請求，對於同一個連線，我們通常將所有流都放在一個呼叫中，以此來統一它們的行為。
我們再來看看整個方法的流程：
- 構建一個StreamAllocation物件，StreamAllocation相當於是個管理類，維護了Connections、Streams和Calls之間的管理，該類初始化一個Socket連線物件，獲取輸入/輸出流物件。
- 繼續執行下一個Interceptor，即BridgeInterceptor
- 丟擲異常，則檢測連線是否還可以繼續，以下情況不會重試：
- 客戶端配置出錯不再重試
- 出錯後，request body不能再次傳送
- 發生以下Exception也無法恢復連線：
- ProtocolException：協議異常
- InterruptedIOException：中斷異常
- SSLHandshakeException：SSL握手異常
- SSLPeerUnverifiedException：SSL握手未授權異常
- 沒有更多線路可以選擇 4。根據響應碼處理請求，返回Request不為空時則進行重定向處理，重定向的次數不能超過20次。
最後是根據響應碼來處理請求頭，由followUpRequest()方法完成，具體如下所示：
public final class RetryAndFollowUpInterceptor implements Interceptor {
private Request followUpRequest(Response userResponse) throws IOException {
if (userResponse == null) throw new IllegalStateException();
Connection connection = streamAllocation.connection();
Route route = connection != null
? connection.route()
: null;
int responseCode = userResponse.code();
final String method = userResponse.request().method();
switch (responseCode) {
//407，代理認證
case HTTP_PROXY_AUTH:
Proxy selectedProxy = route != null
? route.proxy()
: client.proxy();
if (selectedProxy.type() != Proxy.Type.HTTP) {
throw new ProtocolException("Received HTTP_PROXY_AUTH (407) code while not using proxy");
}
return client.proxyAuthenticator().authenticate(route, userResponse);
//401，未經認證
case HTTP_UNAUTHORIZED:
return client.authenticator().authenticate(route, userResponse);
//307，308
case HTTP_PERM_REDIRECT:
case HTTP_TEMP_REDIRECT:
// "If the 307 or 308 status code is received in response to a request other than GET
// or HEAD, the user agent MUST NOT automatically redirect the request"
if (!method.equals("GET") && !method.equals("HEAD")) {
return null;
}
// fall-through
//300，301，302，303
case HTTP_MULT_CHOICE:
case HTTP_MOVED_PERM:
case HTTP_MOVED_TEMP:
case HTTP_SEE_OTHER:
//客戶端在配置中是否允許重定向
if (!client.followRedirects()) return null;
String location = userResponse.header("Location");
if (location == null) return null;
HttpUrl url = userResponse.request().url().resolve(location);
// url為null，不允許重定向
if (url == null) return null;
//查詢是否存在http與https之間的重定向
boolean sameScheme = url.scheme().equals(userResponse.request().url().scheme());
if (!sameScheme && !client.followSslRedirects()) return null;
// Most redirects don't include a request body.
Request.Builder requestBuilder = userResponse.request().newBuilder();
if (HttpMethod.permitsRequestBody(method)) {
final boolean maintainBody = HttpMethod.redirectsWithBody(method);
if (HttpMethod.redirectsToGet(method)) {
requestBuilder.method("GET", null);
} else {
RequestBody requestBody = maintainBody ? userResponse.request().body() : null;
requestBuilder.method(method, requestBody);
}
if (!maintainBody) {
requestBuilder.removeHeader("Transfer-Encoding");
requestBuilder.removeHeader("Content-Length");
requestBuilder.removeHeader("Content-Type");
}
}
// When redirecting across hosts, drop all authentication headers. This
// is potentially annoying to the application layer since they have no
// way to retain them.
if (!sameConnection(userResponse, url)) {
requestBuilder.removeHeader("Authorization");
}
return requestBuilder.url(url).build();
//408，超時
case HTTP_CLIENT_TIMEOUT:
// 408's are rare in practice, but some servers like HAProxy use this response code. The
// spec says that we may repeat the request without modifications. Modern browsers also
// repeat the request (even non-idempotent ones.)
if (userResponse.request().body() instanceof UnrepeatableRequestBody) {
return null;
}
return userResponse.request();
default:
return null;
}
}
}
複製程式碼重定向會涉及到一些網路程式設計的知識，這裡如果沒有完成理解，你只要知道RetryAndFollowUpInterceptor的作用就是處理了一些連線異常以及重定向就可以了。我們接著來看看下一個BridgeInterceptor。
2.2 BridgeInterceptor
BridgeInterceptor就跟它的名字那樣，它是一個連線橋，它負責把使用者構造的請求轉換為傳送給伺服器的請求，把伺服器返回的響應轉換為對使用者友好的響應。 轉換的過程就是新增一些服務端需要的header資訊。
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();
if (body != null) {
//1 進行Header的包裝
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");
}
//這裡有個坑：如果你在請求的時候主動新增了"Accept-Encoding: gzip" ，transparentGzip=false，那你就要自己解壓，如果
// 你沒有吹解壓，或導致response.string()亂碼。
// 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");
}
//建立OkhttpClient配置的cookieJar
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());
//解析伺服器返回的Header，如果沒有這事cookie，則不進行解析
HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
//判斷伺服器是否支援gzip壓縮，如果支援，則將壓縮提交給Okio庫來處理
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();
}
}
複製程式碼就跟它的名字描述的那樣，它是一個橋樑，負責把使用者構造的請求轉換為傳送給伺服器的請求，把伺服器返回的響應轉換為對使用者友好的響應。 在Request階段配置使用者資訊，並新增一些請求頭。在Response階段，進行gzip解壓。
這個方法主要是針對Header做了一些處理，這裡主要提一下"Accept-Encoding", "gzip"，關於它有以下幾點需要注意：
- 開發者沒有新增Accept-Encoding時，自動新增Accept-Encoding: gzip
- 自動新增Accept-Encoding，會對request，response進行自動解壓
- 手動新增Accept-Encoding，不負責解壓縮
- 自動解壓時移除Content-Length，所以上層Java程式碼想要contentLength時為-1
- 自動解壓時移除 Content-Encoding
- 自動解壓時，如果是分塊傳輸編碼，Transfer-Encoding: chunked不受影響。
BridgeInterceptor主要就是針對Header做了一些處理，我們接著來看CacheInterceptor。
2.3 CacheInterceptor
我們知道為了節省流量和提高響應速度，Okhttp是有自己的一套快取機制的，CacheInterceptor就是用來負責讀取快取以及更新快取的。
public final class CacheInterceptor implements Interceptor {
@Override public Response intercept(Chain chain) throws IOException {
//1. 讀取候選快取，具體如何讀取的我們下面會講。
Response cacheCandidate = cache != null
? cache.get(chain.request())
: null;
long now = System.currentTimeMillis();
//2. 建立快取策略，強制快取、對比快取等，關於快取策略我們下面也會講。
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
Request networkRequest = strategy.networkRequest;
Response cacheResponse = strategy.cacheResponse;
if (cache != null) {
cache.trackResponse(strategy);
}
if (cacheCandidate != null && cacheResponse == null) {
closeQuietly(cacheCandidate.body());
}
//3. 根據策略，不使用網路，又沒有快取的直接報錯，並返回錯誤碼504。
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();
}
//4. 根據策略，不使用網路，有快取的直接返回。
if (networkRequest == null) {
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
Response networkResponse = null;
try {
//5. 前面兩個都沒有返回，繼續執行下一個Interceptor，即ConnectInterceptor。
networkResponse = chain.proceed(networkRequest);
} finally {
//如果發生IO異常，則釋放掉快取
if (networkResponse == null && cacheCandidate != null) {
closeQuietly(cacheCandidate.body());
}
}
//6. 接收到網路結果，如果響應code式304，則使用快取，返回快取結果。
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();
cache.trackConditionalCacheHit();
cache.update(cacheResponse, response);
return response;
} else {
closeQuietly(cacheResponse.body());
}
}
//7. 讀取網路結果。
Response response = networkResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
//8. 對資料進行快取。
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.
}
}
}
//9. 返回網路讀取的結果。
return response;
}
}
複製程式碼整個方法的流程如下所示：
- 讀取候選快取，具體如何讀取的我們下面會講。
- 建立快取策略，強制快取、對比快取等，關於快取策略我們下面也會講。
- 根據策略，不使用網路，又沒有快取的直接報錯，並返回錯誤碼504。
- 根據策略，不使用網路，有快取的直接返回。
- 前面兩個都沒有返回，繼續執行下一個Interceptor，即ConnectInterceptor。
- 接收到網路結果，如果響應code式304，則使用快取，返回快取結果。
- 讀取網路結果。
- 對資料進行快取。
- 返回網路讀取的結果。
我們再接著來看ConnectInterceptor。
2.4 ConnectInterceptor
在RetryAndFollowUpInterceptor裡初始化了一個StreamAllocation物件，我們說在這個StreamAllocation物件裡初始化了一個Socket物件用來做連線，但是並沒有 真正的連線，等到處理完hader和快取資訊之後，才呼叫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();
boolean doExtensiveHealthChecks = !request.method().equals("GET");
//建立輸出流
HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks);
//建立連線
RealConnection connection = streamAllocation.connection();
return realChain.proceed(request, streamAllocation, httpCodec, connection);
}
}
複製程式碼ConnectInterceptor在Request階段建立連線，處理方式也很簡單，建立了兩個物件：
- HttpCodec：用來編碼HTTP requests和解碼HTTP responses
- RealConnection：連線物件，負責發起與伺服器的連線。
這裡事實上包含了連線、連線池等一整套的Okhttp的連線機制，我們放在下面單獨講，先來繼續看最後一個Interceptor：CallServerInterceptor。
2.5 CallServerInterceptor
CallServerInterceptor負責從伺服器讀取響應的資料。
public final class CallServerInterceptor implements Interceptor {
@Override public Response intercept(Chain chain) throws IOException {
//這些物件在前面的Interceptor都已經建立完畢
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();
//1. 寫入請求頭
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);
}
//2 寫入請求體
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();
//3 讀取響應頭
if (responseBuilder == null) {
responseBuilder = httpCodec.readResponseHeaders(false);
}
Response response = responseBuilder
.request(request)
.handshake(streamAllocation.connection().handshake())
.sentRequestAtMillis(sentRequestMillis)
.receivedResponseAtMillis(System.currentTimeMillis())
.build();
//4 讀取響應體
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;
}
}
複製程式碼我們通過ConnectInterceptor已經連線到伺服器了，接下來我們就是寫入請求資料以及讀出返回資料了。整個流程：
- 寫入請求頭
- 寫入請求體
- 讀取響應頭
- 讀取響應體
這篇文章就到這裡，後續的文章我們會來分析Okhttp的快取機制、連線機制、編輯嗎機制等實現。
三 連線機制
連線的建立是在StreamAllocation物件統籌下完成的，我們前面也說過它早在RetryAndFollowUpInterceptor就被建立了，StreamAllocation物件 主要用來管理兩個關鍵角色：
- RealConnection：真正建立連線的物件，利用Socket建立連線。
- ConnectionPool：連線池，用來管理和複用連線。
在裡初始化了一個StreamAllocation物件，我們說在這個StreamAllocation物件裡初始化了一個Socket物件用來做連線，但是並沒有
3.1 建立連線
我們在前面的ConnectInterceptor分析中已經說過，onnectInterceptor用來完成連線。而真正的連線在RealConnect中實現，連線由連線池ConnectPool來管理，連線池最多保 持5個地址的連線keep-alive，每個keep-alive時長為5分鐘，並有非同步執行緒清理無效的連線。
主要由以下兩個方法完成：
- HttpCodec httpCodec = streamAllocation.newStream(client, doExtensiveHealthChecks);
- RealConnection connection = streamAllocation.connection();
我們來具體的看一看。
StreamAllocation.newStream()最終調動findConnect()方法來建立連線。
public final class StreamAllocation {
/**
* Returns a connection to host a new stream. This prefers the existing connection if it exists,
* then the pool, finally building a new connection.
*/
private RealConnection findConnection(int connectTimeout, int readTimeout, int writeTimeout,
boolean connectionRetryEnabled) throws IOException {
Route selectedRoute;
synchronized (connectionPool) {
if (released) throw new IllegalStateException("released");
if (codec != null) throw new IllegalStateException("codec != null");
if (canceled) throw new IOException("Canceled");
//1 檢視是否有完好的連線
RealConnection allocatedConnection = this.connection;
if (allocatedConnection != null && !allocatedConnection.noNewStreams) {
return allocatedConnection;
}
//2 連線池中是否用可用的連線，有則使用
Internal.instance.get(connectionPool, address, this, null);
if (connection != null) {
return connection;
}
selectedRoute = route;
}
//執行緒的選擇，多IP操作
if (selectedRoute == null) {
selectedRoute = routeSelector.next();
}
//3 如果沒有可用連線，則自己建立一個
RealConnection result;
synchronized (connectionPool) {
if (canceled) throw new IOException("Canceled");
// Now that we have an IP address, make another attempt at getting a connection from the pool.
// This could match due to connection coalescing.
Internal.instance.get(connectionPool, address, this, selectedRoute);
if (connection != null) {
route = selectedRoute;
return connection;
}
// Create a connection and assign it to this allocation immediately. This makes it possible
// for an asynchronous cancel() to interrupt the handshake we're about to do.
route = selectedRoute;
refusedStreamCount = 0;
result = new RealConnection(connectionPool, selectedRoute);
acquire(result);
}
//4 開始TCP以及TLS握手操作
result.connect(connectTimeout, readTimeout, writeTimeout, connectionRetryEnabled);
routeDatabase().connected(result.route());
//5 將新建立的連線，放在連線池中
Socket socket = null;
synchronized (connectionPool) {
// Pool the connection.
Internal.instance.put(connectionPool, result);
// If another multiplexed connection to the same address was created concurrently, then
// release this connection and acquire that one.
if (result.isMultiplexed()) {
socket = Internal.instance.deduplicate(connectionPool, address, this);
result = connection;
}
}
closeQuietly(socket);
return result;
}
}
複製程式碼整個流程如下：
- 查詢是否有完整的連線可用：
- Socket沒有關閉
- 輸入流沒有關閉
- 輸出流沒有關閉
- Http2連線沒有關閉
- 連線池中是否有可用的連線，如果有則可用。
- 如果沒有可用連線，則自己建立一個。
- 開始TCP連線以及TLS握手操作。
- 將新建立的連線加入連線池。
上述方法完成後會建立一個RealConnection物件，然後呼叫該方法的connect()方法建立連線，我們再來看看RealConnection.connect()方法的實現。
public final class RealConnection extends Http2Connection.Listener implements Connection {
public void connect(
int connectTimeout, int readTimeout, int writeTimeout, boolean connectionRetryEnabled) {
if (protocol != null) throw new IllegalStateException("already connected");
//線路選擇
RouteException routeException = null;
List<ConnectionSpec> connectionSpecs = route.address().connectionSpecs();
ConnectionSpecSelector connectionSpecSelector = new ConnectionSpecSelector(connectionSpecs);
if (route.address().sslSocketFactory() == null) {
if (!connectionSpecs.contains(ConnectionSpec.CLEARTEXT)) {
throw new RouteException(new UnknownServiceException(
"CLEARTEXT communication not enabled for client"));
}
String host = route.address().url().host();
if (!Platform.get().isCleartextTrafficPermitted(host)) {
throw new RouteException(new UnknownServiceException(
"CLEARTEXT communication to " + host + " not permitted by network security policy"));
}
}
//開始連線
while (true) {
try {
//如果是通道模式，則建立通道連線
if (route.requiresTunnel()) {
connectTunnel(connectTimeout, readTimeout, writeTimeout);
}
//否則進行Socket連線，一般都是屬於這種情況
else {
connectSocket(connectTimeout, readTimeout);
}
//建立https連線
establishProtocol(connectionSpecSelector);
break;
} catch (IOException e) {
closeQuietly(socket);
closeQuietly(rawSocket);
socket = null;
rawSocket = null;
source = null;
sink = null;
handshake = null;
protocol = null;
http2Connection = null;
if (routeException == null) {
routeException = new RouteException(e);
} else {
routeException.addConnectException(e);
}
if (!connectionRetryEnabled || !connectionSpecSelector.connectionFailed(e)) {
throw routeException;
}
}
}
if (http2Connection != null) {
synchronized (connectionPool) {
allocationLimit = http2Connection.maxConcurrentStreams();
}
}
}
/** Does all the work necessary to build a full HTTP or HTTPS connection on a raw socket. */
private void connectSocket(int connectTimeout, int readTimeout) throws IOException {
Proxy proxy = route.proxy();
Address address = route.address();
//根據代理型別的不同處理Socket
rawSocket = proxy.type() == Proxy.Type.DIRECT || proxy.type() == Proxy.Type.HTTP
? address.socketFactory().createSocket()
: new Socket(proxy);
rawSocket.setSoTimeout(readTimeout);
try {
//建立Socket連線
Platform.get().connectSocket(rawSocket, route.socketAddress(), connectTimeout);
} catch (ConnectException e) {
ConnectException ce = new ConnectException("Failed to connect to " + route.socketAddress());
ce.initCause(e);
throw ce;
}
// The following try/catch block is a pseudo hacky way to get around a crash on Android 7.0
// More details:
// https://github.com/square/okhttp/issues/3245
// https://android-review.googlesource.com/#/c/271775/
try {
//獲取輸入/輸出流
source = Okio.buffer(Okio.source(rawSocket));
sink = Okio.buffer(Okio.sink(rawSocket));
} catch (NullPointerException npe) {
if (NPE_THROW_WITH_NULL.equals(npe.getMessage())) {
throw new IOException(npe);
}
}
}
}
複製程式碼最終呼叫Java裡的套接字Socket裡的connect()方法。
3.2 連線池
我們知道在負責的網路環境下，頻繁的進行建立Sokcet連線（TCP三次握手）和斷開Socket（TCP四次分手）是非常消耗網路資源和浪費時間的，HTTP中的keepalive連線對於 降低延遲和提升速度有非常重要的作用。
複用連線就需要對連線進行管理，這裡就引入了連線池的概念。
Okhttp支援5個併發KeepAlive，預設鏈路生命為5分鐘(鏈路空閒後，保持存活的時間)，連線池有ConectionPool實現，對連線進行回收和管理。
ConectionPool在內部維護了一個執行緒池，來清理連線，如下所示：
public final class ConnectionPool {
private static final Executor executor = new ThreadPoolExecutor(0 /* corePoolSize */,
Integer.MAX_VALUE /* maximumPoolSize */, 60L /* keepAliveTime */, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp ConnectionPool", true));
//清理連線，線上程池executor裡呼叫。
private final Runnable cleanupRunnable = new Runnable() {
@Override public void run() {
while (true) {
//執行清理，並返回下次需要清理的時間。
long waitNanos = cleanup(System.nanoTime());
if (waitNanos == -1) return;
if (waitNanos > 0) {
long waitMillis = waitNanos / 1000000L;
waitNanos -= (waitMillis * 1000000L);
synchronized (ConnectionPool.this) {
try {
//在timeout時間內釋放鎖
ConnectionPool.this.wait(waitMillis, (int) waitNanos);
} catch (InterruptedException ignored) {
}
}
}
}
}
};
}
複製程式碼ConectionPool在內部維護了一個執行緒池，來清理連，清理任務由cleanup()方法完成，它是一個阻塞操作，首先執行清理，並返回下次需要清理的間隔時間，呼叫呼叫wait() 方法釋放鎖。等時間到了以後，再次進行清理，並返回下一次需要清理的時間，迴圈往復。
我們來看一看cleanup()方法的具體實現。
public final class ConnectionPool {
long cleanup(long now) {
int inUseConnectionCount = 0;
int idleConnectionCount = 0;
RealConnection longestIdleConnection = null;
long longestIdleDurationNs = Long.MIN_VALUE;
synchronized (this) {
//遍歷所有的連線，標記處不活躍的連線。
for (Iterator<RealConnection> i = connections.iterator(); i.hasNext(); ) {
RealConnection connection = i.next();
//1. 查詢此連線內部的StreanAllocation的引用數量。
if (pruneAndGetAllocationCount(connection, now) > 0) {
inUseConnectionCount++;
continue;
}
idleConnectionCount++;
//2. 標記空閒連線。
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;
}
}
if (longestIdleDurationNs >= this.keepAliveDurationNs
|| idleConnectionCount > this.maxIdleConnections) {
//3. 如果空閒連線超過5個或者keepalive時間大於5分鐘，則將該連線清理掉。
connections.remove(longestIdleConnection);
} else if (idleConnectionCount > 0) {
//4. 返回此連線的到期時間，供下次進行清理。
return keepAliveDurationNs - longestIdleDurationNs;
} else if (inUseConnectionCount > 0) {
//5. 全部都是活躍連線，5分鐘時候再進行清理。
return keepAliveDurationNs;
} else {
//6. 沒有任何連線，跳出迴圈。
cleanupRunning = false;
return -1;
}
}
//7. 關閉連線，返回時間0，立即再次進行清理。
closeQuietly(longestIdleConnection.socket());
return 0;
}
}
複製程式碼整個方法的流程如下所示：
- 查詢此連線內部的StreanAllocation的引用數量。
- 標記空閒連線。
- 如果空閒連線超過5個或者keepalive時間大於5分鐘，則將該連線清理掉。
- 返回此連線的到期時間，供下次進行清理。
- 全部都是活躍連線，5分鐘時候再進行清理。
- 沒有任何連線，跳出迴圈。
- 關閉連線，返回時間0，立即再次進行清理。
在RealConnection裡有個StreamAllocation虛引用列表，每建立一個StreamAllocation，就會把它新增進該列表中，如果留關閉以後就將StreamAllocation 物件從該列表中移除，正是利用利用這種引用計數的方式判定一個連線是否為空閒連線，
public final List<Reference<StreamAllocation>> allocations = new ArrayList<>();
複製程式碼查詢引用計數由pruneAndGetAllocationCount()方法實現，具體實現如下所示：
public final class ConnectionPool {
private int pruneAndGetAllocationCount(RealConnection connection, long now) {
//虛引用列表
List<Reference<StreamAllocation>> references = connection.allocations;
//遍歷虛引用列表
for (int i = 0; i < references.size(); ) {
Reference<StreamAllocation> reference = references.get(i);
//如果虛引用StreamAllocation正在被使用，則跳過進行下一次迴圈，
if (reference.get() != null) {
//引用計數
i++;
continue;
}
// We've discovered a leaked allocation. This is an application bug.
StreamAllocation.StreamAllocationReference streamAllocRef =
(StreamAllocation.StreamAllocationReference) reference;
String message = "A connection to " + connection.route().address().url()
+ " was leaked. Did you forget to close a response body?";
Platform.get().logCloseableLeak(message, streamAllocRef.callStackTrace);
//否則移除該StreamAllocation引用
references.remove(i);
connection.noNewStreams = true;
// 如果所有的StreamAllocation引用都沒有了，返回引用計數0
if (references.isEmpty()) {
connection.idleAtNanos = now - keepAliveDurationNs;
return 0;
}
}
//返回引用列表的大小，作為引用計數
return references.size();
}
}
複製程式碼四 快取機制
3.1 快取策略
在分析Okhttp的快取機制之前，我們先來回顧一下HTTP與快取相關的理論知識，這是實現Okhttp機制的基礎。
HTTP的快取機制也是依賴於請求和響應header裡的引數類實現的，最終響應式從快取中去，還是從服務端重新拉取，HTTP的快取機制的流程如下所示：
? 點選圖片檢視大圖
HTTP的快取可以分為兩種：
- 強制快取：需要服務端參與判斷是否繼續使用快取，當客戶端第一次請求資料是，服務端返回了快取的過期時間（Expires與Cache-Control），沒有過期就可以繼續使用快取，否則則不適用，無需再向服務端詢問。
- 對比快取：需要服務端參與判斷是否繼續使用快取，當客戶端第一次請求資料時，服務端會將快取標識（Last-Modified/If-Modified-Since與Etag/If-None-Match）與資料一起返回給客戶端，客戶端將兩者都備份到快取中 ，再次請求資料時，客戶端將上次備份的快取 標識傳送給服務端，服務端根據快取標識進行判斷，如果返回304，則表示通知客戶端可以繼續使用快取。
強制快取優先於對比快取。
上面提到強制快取使用的的兩個標識：
- Expires：Expires的值為服務端返回的到期時間，即下一次請求時，請求時間小於服務端返回的到期時間，直接使用快取資料。到期時間是服務端生成的，客戶端和服務端的時間可能有誤差。
- Cache-Control：Expires有個時間校驗的問題，所有HTTP1.1採用Cache-Control替代Expires。
Cache-Control的取值有以下幾種：
- private: 客戶端可以快取。
- public: 客戶端和代理伺服器都可快取。
- max-age=xxx: 快取的內容將在 xxx 秒後失效
- no-cache: 需要使用對比快取來驗證快取資料。
- no-store: 所有內容都不會快取，強制快取，對比快取都不會觸發。
我們再來看看對比快取的兩個標識：
Last-Modified/If-Modified-Since
Last-Modified 表示資源上次修改的時間。
當客戶端傳送第一次請求時，服務端返回資源上次修改的時間：
Last-Modified: Tue, 12 Jan 2016 09:31:27 GMT
複製程式碼客戶端再次傳送，會在header裡攜帶If-Modified-Since。將上次服務端返回的資源時間上傳給服務端。
If-Modified-Since: Tue, 12 Jan 2016 09:31:27 GMT
複製程式碼服務端接收到客戶端發來的資源修改時間，與自己當前的資源修改時間進行對比，如果自己的資源修改時間大於客戶端發來的資源修改時間，則說明資源做過修改， 則返回200表示需要重新請求資源，否則返回304表示資源沒有被修改，可以繼續使用快取。
上面是一種時間戳標記資源是否修改的方法，還有一種資源標識碼ETag的方式來標記是否修改，如果標識碼發生改變，則說明資源已經被修改，ETag優先順序高於Last-Modified。
Etag/If-None-Match
ETag是資原始檔的一種標識碼，當客戶端傳送第一次請求時，服務端會返回當前資源的標識碼：
ETag: "5694c7ef-24dc"
複製程式碼客戶端再次傳送，會在header裡攜帶上次服務端返回的資源標識碼：
If-None-Match:"5694c7ef-24dc"
複製程式碼服務端接收到客戶端發來的資源標識碼，則會與自己當前的資源嗎進行比較，如果不同，則說明資源已經被修改，則返回200，如果相同則說明資源沒有被修改，返回 304，客戶端可以繼續使用快取。
以上便是HTTP快取策略的相關理論知識，我們來看看具體實現。
Okhttp的快取策略就是根據上述流程圖實現的，具體的實現類是CacheStrategy，CacheStrategy的建構函式裡有兩個引數：
CacheStrategy(Request networkRequest, Response cacheResponse) {
this.networkRequest = networkRequest;
this.cacheResponse = cacheResponse;
}
複製程式碼這兩個引數引數的含義如下：
- networkRequest：網路請求。
- cacheResponse：快取響應，基於DiskLruCache實現的檔案快取，可以是請求中url的md5，value是檔案中查詢到的快取，這個我們下面會說。
CacheStrategy就是利用這兩個引數生成最終的策略，有點像map操作，將networkRequest與cacheResponse這兩個值輸入，處理之後再將這兩個值輸出，們的組合結果如下所示：
- 如果networkRequest為null，cacheResponse為null：only-if-cached(表明不進行網路請求，且快取不存在或者過期，一定會返回503錯誤)。
- 如果networkRequest為null，cacheResponse為non-null：不進行網路請求，而且快取可以使用，直接返回快取，不用請求網路。
- 如果networkRequest為non-null，cacheResponse為null：需要進行網路請求，而且快取不存在或者過期，直接訪問網路。
- 如果networkRequest為non-null，cacheResponse為non-null：Header中含有ETag/Last-Modified標籤，需要在條件請求下使用，還是需要訪問網路。
那麼這四種情況是如何判定的，我們來看一下。
CacheStrategy是利用Factory模式進行構造的，CacheStrategy.Factory物件構建以後，呼叫它的get()方法即可獲得具體的CacheStrategy，CacheStrategy.Factory.get()方法內部 呼叫的是CacheStrategy.Factory.getCandidate()方法，它是核心的實現。
如下所示：
public static class Factory {
private CacheStrategy getCandidate() {
//1. 如果快取沒有命中，就直接進行網路請求。
if (cacheResponse == null) {
return new CacheStrategy(request, null);
}
//2. 如果TLS握手資訊丟失，則返回直接進行連線。
if (request.isHttps() && cacheResponse.handshake() == null) {
return new CacheStrategy(request, null);
}
//3. 根據response狀態碼，Expired時間和是否有no-cache標籤就行判斷是否進行直接訪問。
if (!isCacheable(cacheResponse, request)) {
return new CacheStrategy(request, null);
}
//4. 如果請求header裡有"no-cache"或者右條件GET請求（header裡帶有ETag/Since標籤），則直接連線。
CacheControl requestCaching = request.cacheControl();
if (requestCaching.noCache() || hasConditions(request)) {
return new CacheStrategy(request, null);
}
CacheControl responseCaching = cacheResponse.cacheControl();
if (responseCaching.immutable()) {
return new CacheStrategy(null, cacheResponse);
}
//計算當前age的時間戳：now - sent + age
long ageMillis = cacheResponseAge();
//重新整理時間，一般伺服器設定為max-age
long freshMillis = computeFreshnessLifetime();
if (requestCaching.maxAgeSeconds() != -1) {
//一般取max-age
freshMillis = Math.min(freshMillis, SECONDS.toMillis(requestCaching.maxAgeSeconds()));
}
long minFreshMillis = 0;
if (requestCaching.minFreshSeconds() != -1) {
//一般取0
minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds());
}
long maxStaleMillis = 0;
if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) {
maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds());
}
//5. 如果快取在過期時間內則可以直接使用，則直接返回上次快取。
if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) {
Response.Builder builder = cacheResponse.newBuilder();
if (ageMillis + minFreshMillis >= freshMillis) {
builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\"");
}
long oneDayMillis = 24 * 60 * 60 * 1000L;
if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) {
builder.addHeader("Warning", "113 HttpURLConnection \"Heuristic expiration\"");
}
return new CacheStrategy(null, builder.build());
}
//6. 如果快取過期，且有ETag等資訊，則傳送If-None-Match、If-Modified-Since、If-Modified-Since等條件請求
//交給服務端判斷處理
String conditionName;
String conditionValue;
if (etag != null) {
conditionName = "If-None-Match";
conditionValue = etag;
} else if (lastModified != null) {
conditionName = "If-Modified-Since";
conditionValue = lastModifiedString;
} else if (servedDate != null) {
conditionName = "If-Modified-Since";
conditionValue = servedDateString;
} else {
return new CacheStrategy(request, null); // No condition! Make a regular request.
}
Headers.Builder conditionalRequestHeaders = request.headers().newBuilder();
Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue);
Request conditionalRequest = request.newBuilder()
.headers(conditionalRequestHeaders.build())
.build();
return new CacheStrategy(conditionalRequest, cacheResponse);
}
}
複製程式碼整個函式的邏輯就是按照上面那個HTTP快取判定流程圖來實現，具體流程如下所示：
- 如果快取沒有命中，就直接進行網路請求。
- 如果TLS握手資訊丟失，則返回直接進行連線。
- 根據response狀態碼，Expired時間和是否有no-cache標籤就行判斷是否進行直接訪問。
- 如果請求header裡有"no-cache"或者右條件GET請求（header裡帶有ETag/Since標籤），則直接連線。
- 如果快取在過期時間內則可以直接使用，則直接返回上次快取。
- 如果快取過期，且有ETag等資訊，則傳送If-None-Match、If-Modified-Since、If-Modified-Since等條件請求交給服務端判斷處理
整個流程就是這樣，另外說一點，Okhttp的快取是根據伺服器header自動的完成的，整個流程也是根據RFC文件寫死的，客戶端不必要進行手動控制。
理解了快取策略，我們來看看快取在磁碟上是如何被管理的。
3.2 快取管理
這篇文章我們來分析Okhttp的快取機制，快取機制是基於DiskLruCache做的。Cache類封裝了快取的實現，實現了InternalCache介面。
InternalCache介面如下所示：
InternalCache
public interface InternalCache {
//獲取快取
Response get(Request request) throws IOException;
//存入快取
CacheRequest put(Response response) throws IOException;
//移除快取
void remove(Request request) throws IOException;
//更新快取
void update(Response cached, Response network);
//跟蹤一個滿足快取條件的GET請求
void trackConditionalCacheHit();
//跟蹤滿足快取策略CacheStrategy的響應
void trackResponse(CacheStrategy cacheStrategy);
}
複製程式碼我們接著來看看它的實現類。
Cache沒有直接實現InternalCache這個介面，而是在其內部實現了InternalCache的匿名內部類，內部類的方法呼叫Cache對應的方法，如下所示：
final InternalCache internalCache = new InternalCache() {
@Override public Response get(Request request) throws IOException {
return Cache.this.get(request);
}
@Override public CacheRequest put(Response response) throws IOException {
return Cache.this.put(response);
}
@Override public void remove(Request request) throws IOException {
Cache.this.remove(request);
}
@Override public void update(Response cached, Response network) {
Cache.this.update(cached, network);
}
@Override public void trackConditionalCacheHit() {
Cache.this.trackConditionalCacheHit();
}
@Override public void trackResponse(CacheStrategy cacheStrategy) {
Cache.this.trackResponse(cacheStrategy);
}
};
InternalCache internalCache() {
return cache != null ? cache.internalCache : internalCache;
}
複製程式碼` 在Cache類裡還定義一些內部類，這些類封裝了請求與響應資訊。
- Cache.Entry：封裝了請求與響應等資訊，包括url、varyHeaders、protocol、code、message、responseHeaders、handshake、sentRequestMillis與receivedResponseMillis。
- Cache.CacheResponseBody：繼承於ResponseBody，封裝了快取快照snapshot，響應體bodySource，內容型別contentType，內容長度contentLength。
除了兩個類以外，Okhttp還封裝了一個檔案系統類FileSystem類，這個類利用Okio這個庫對Java的FIle操作進行了一層封裝，簡化了IO操作。理解了這些剩下的就是DiskLruCahe裡的插入快取 、獲取快取和刪除快取的操作。
關於這一部分的內容，可以參考我們之前寫的內容07Android開源框架原始碼分析：LruCache與DiskLruCache 。
好了，到這裡關於Okhttp的全部內容就都講完了，可以說Okhttp是設計非常優良的一個庫，有很多值得我們學習的地方，下一篇我們來分析它的好搭檔Retrofit。