《從使用到源碼：OkHttp3責任鏈模式剖析》

一從使用開始

0.依賴引入

implementation ("com.squareup.okhttp3:okhttp:3.14.7")

1.創建OkHttpClient實例

方式一：直接使用默認配置的Builder

//從源碼可以看出，當我們直接new創建OkHttpClient實例時，會默認給我們配置好一個Builder
OkHttpClient okHttpClient = new OkHttpClient();
?
//源碼
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();if (proxySelector == null) {proxySelector = new NullProxySelector();}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;callTimeout = 0;connectTimeout = 10_000;readTimeout = 10_000;writeTimeout = 10_000;pingInterval = 0;}

方式二：自定義配置Builder

OkHttpClient client = new OkHttpClient().newBuilder().addInterceptor(new MyCookieInterceptor()).addNetworkInterceptor(new MyNetWorkInterceptor()).readTimeout(3000, TimeUnit.SECONDS).build();

2.創建Request實例

Request request = new Request.Builder().url("https://www.xxx.com").build();

3.創建Call請求，發起同步或異步網絡請求

 //同步請求Response execute = client.newCall(request).execute();//異步請求
client.newCall(request).enqueue(new Callback() {@Overridepublic void onFailure(Call call, IOException e) {//請求響應失敗回調}
?@Overridepublic void onResponse(Call call, Response response) throws IOException {//請求響應成功回調}});

二責任鏈的構建剖析

1.責任鏈模式介紹

什么是責任鏈模式？
一個請求沿著一條“鏈”傳遞，直到該“鏈”上的某個處理者處理它為止。
OkHttp中的責任鏈是如何體現的？
將一個網絡請求Request沿著一條由多個攔截器組成的“鏈”順序向后傳遞，若攔截器無法完全處理請求則將請求繼續向后傳遞，直到某個攔截器完全處理它并返回Respose結果（不一定是成功的），再依據順序層層向前傳遞。

2.OkHttp中的責任鏈模式剖析

前面我們已經了解了OkHttp的使用，接下來我們就從OkHttp進行同步請求的代碼入手，來剖析其責任鏈在怎么構建起來的。

//同步請求Response execute = client.newCall(request).execute();

同步請求部分的代碼如上，ctrl+鼠標左鍵點擊newCall進入OkHttp的源碼，向下追溯，最終發現調用到了RealCall的靜態方法，將OkHttpClient對象和Request對象作為參數傳遞給了RealCall構造方法，構建了一個RealCall對象并返回。

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.transmitter = new Transmitter(client, call);return call;
}

再回到同步請求的代碼

//同步請求Response execute = client.newCall(request).execute();

這次我們ctrl+鼠標左鍵點擊execute查看同步請求的代碼邏輯，此時發現走到了Call接口，execute()方法沒有方法體，沒關系，我們在Call接口中ctrl+h，就可以看到Call接口的繼承樹啦

//Call
Response execute() throws IOException;

而后你就會發現Call下只有一個子類也就是我們剛剛看過的RealCall，在RealCall中搜索execute()方法，就可以看到實際執行的到的execute()方法如下

@Override public Response execute() throws IOException {synchronized (this) {if (executed) throw new IllegalStateException("Already Executed");executed = true;}transmitter.timeoutEnter();transmitter.callStart();try {client.dispatcher().executed(this);return getResponseWithInterceptorChain();} finally {client.dispatcher().finished(this);}
}

此方法的作用主要有三個：（transmitter我們暫不關注，它的作用主要是管理Call的生命周期，關心的寶子自行了解哈）

檢查同步請求是否已經被執行過
client.dispatcher().executed(this)，將同步請求存入ArrayDeque中，以實現發起多個同步請求時，按順序進行同步請求
getResponseWithInterceptorChain()，創建責任鏈并執行，獲取同步請求返回結果

我們進入client.dispatcher().executed(this)的executed(this)方法，可以看到如下代碼：

/** 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);
}

可以看到在同步請求中，此方法的作用僅為記錄同步請求

接下來我們進入getResponseWithInterceptorChain()方法，OkHttp責任鏈構建和開啟就開始于這個方法：

//RealCall.class
?
Response getResponseWithInterceptorChain() throws IOException {// Build a full stack of interceptors.//創建一個攔截器集合List<Interceptor> interceptors = new ArrayList<>();/**將用戶即我們自己定義的攔截器加入到此集合中，即我們剛剛在自定義配置Builder中調用.addInterceptor(new         MyCookieInterceptor())傳遞進來的攔截器**/interceptors.addAll(client.interceptors());//加入一些默認的內置攔截器//負責失敗重試以及重定向的攔截器interceptors.add(new RetryAndFollowUpInterceptor(client));//負責把用戶構造的請求轉換為發送到服務器的請求、把服務器返回的響應轉換為用戶友好的響應的攔截器interceptors.add(new BridgeInterceptor(client.cookieJar()));//負責讀取緩存直接返回、更新緩存的攔截器interceptors.add(new CacheInterceptor(client.internalCache()));//負責和服務器建立連接的攔截器interceptors.add(new ConnectInterceptor(client));//判斷當前請求是 WebSocket 握手請求 還是HTTP或HTTPS請求if (!forWebSocket) {/**是HTTP或HTTPS請求才添加用戶在自定義配置Builder中調用addNetworkInterceptor(new MyNetWorkInterceptor())配置進來的網絡攔截器，因為網絡攔截器是專門為處理 HTTP 網絡請求而生的，為WebSocket類型的請求設置此攔截器是無意義的,甚至可能因攔截 HTTP 幀而干擾 WebSocket 協議的正常交互**/interceptors.addAll(client.networkInterceptors());}//負責向服務器發送請求數據、從服務器讀取響應數據的攔截器（此為最后一個執行的攔截器）interceptors.add(new CallServerInterceptor(forWebSocket));/**構建責任鏈chain，將我們剛剛的攔截器集合interceptors，原始的請求originalRequest（也就是我們創建的Request對象），此類自身的  實例傳入(此處我們只關心這三個參數就好啦)**/Interceptor.Chain chain = new RealInterceptorChain(interceptors, transmitter, null, 0,originalRequest, this, client.connectTimeoutMillis(),client.readTimeoutMillis(), client.writeTimeoutMillis());boolean calledNoMoreExchanges = false;try {//調用proceed()方法將原始請求傳遞進去開啟責任鏈Response response = chain.proceed(originalRequest);if (transmitter.isCanceled()) {closeQuietly(response);throw new IOException("Canceled");}return response;} catch (IOException e) {calledNoMoreExchanges = true;throw transmitter.noMoreExchanges(e);} finally {if (!calledNoMoreExchanges) {transmitter.noMoreExchanges(null);}}
}

上面我們分析了RealCall的getResponseWithInterceptorChain()方法，最后走到了Interceptor.Chain的proceed()方法，讓我們來分析這部分源碼吧

ctrl+鼠標左鍵點擊proceed()方法，可以查看到如下源碼：

/*** Observes, modifies, and potentially short-circuits requests going out and the corresponding* responses coming back in. Typically interceptors add, remove, or transform headers on the request* or response.*/
public interface Interceptor {Response intercept(Chain chain) throws IOException;
?interface Chain {Request request();
?Response proceed(Request request) throws IOException;
?/*** Returns the connection the request will be executed on. This is only available in the chains* of network interceptors; for application interceptors this is always null.*/@Nullable Connection connection();
?Call call();
?int connectTimeoutMillis();
?Chain withConnectTimeout(int timeout, TimeUnit unit);
?int readTimeoutMillis();
?Chain withReadTimeout(int timeout, TimeUnit unit);
?int writeTimeoutMillis();
?Chain withWriteTimeout(int timeout, TimeUnit unit);}
}

可以看到，proceed()方法在Interceptor接口中的Chain接口中，沒有具體實現，所以我們依舊在Chain接口中ctrl+h，查看Chain接口的繼承樹，而后我們就又可以發現，它又是只有一個子類 RealInterceptorChain，那proceed()方法的具體實現就必然在 RealInterceptorChain中啦，如下：

//RealInterceptorChain.class
//此方法負責驅動攔截器鏈的執行（OkHttp 的攔截器鏈是核心設計，用于處理請求、響應的各種中間邏輯，如重試、緩存、網絡連接等）
//每個攔截器（除最后一個）處理完畢后（但未完全處理完畢）都會回調回這個方法，在此方法中將請求交由下一個攔截器處理
@Override public Response proceed(Request request) throws IOException {//可以看到這里調用了RealInterceptorChain類中自己實現的同名proceed方法return proceed(request, transmitter, exchange);
}
?
//也就是說，這里就是proceed方法的具體實現了
public Response proceed(Request request, Transmitter transmitter, @Nullable Exchange exchange)throws IOException {
//index變量的作用是控制攔截器的順序執行，OkHttp的責任鏈就是依靠此變量來實現順序執行的，index表示攔截器集合interceptors的索引//此處進行攔截器索引合法性校驗if (index >= interceptors.size()) throw new AssertionError();/**通過記錄代碼調用執行到此處的次數，以統計當前攔截器鏈的調用次數，因為我們上面說了，每個攔截器（除最后一個）處理完畢后（但未完全處理完畢）都會回調回這個方法,故可以這樣來統計**/calls++;//驗證網絡攔截器（Network Interceptor）是否修改了請求的 Host（主機）或 Port（端口）/**因為網絡攔截器的職責是在網絡請求建立之前和之后處理邏輯（例如，處理重定向、重試、緩存等）。一個已經建立的 TCP 連接是和特定的主機與端口綁定的。如果攔截器修改了這些信息，那么這個連接就無法被重用，這會導致不必要的連接開銷，并且破壞了攔截器鏈的邏輯完整性。**/// If we already have a stream, confirm that the incoming request will use it.if (this.exchange != null && !this.exchange.connection().supportsUrl(request.url())) {throw new IllegalStateException("network interceptor " + interceptors.get(index - 1)+ " must retain the same host and port");}//確保每個網絡攔截器只調用一次 chain.proceed() 方法// If we already have a stream, confirm that this is the only call to chain.proceed().if (this.exchange != null && calls > 1) {throw new IllegalStateException("network interceptor " + interceptors.get(index - 1)+ " must call proceed() exactly once");}//創建下一個（index + 1）攔截器 鏈對象// Call the next interceptor in the chain.RealInterceptorChain next = new RealInterceptorChain(interceptors, transmitter, exchange,index + 1, request, call, connectTimeout, readTimeout, writeTimeout);//通過index獲取到當前攔截器對象Interceptor interceptor = interceptors.get(index);/**用當前攔截器對象調用intercept(next)，將下一個攔截器 鏈對象傳遞進去，此方法為每個攔截器都有的，攔截器對請求的處理都在這個方法中進行，好了接下來就可以跳到下面看這個方法的源碼了**/Response response = interceptor.intercept(next);
?// Confirm that the next interceptor made its required call to chain.proceed().if (exchange != 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;
}

下面，我們以BridgeInterceptor攔截器中的intercept方法為例，來捋一下intercept方法的執行流程

//BridgeInterceptor.class ?
?
@Override public Response intercept(Chain chain) throws IOException {//通過攔截器鏈對象獲取到請求對象Request userRequest = chain.request();Request.Builder requestBuilder = userRequest.newBuilder();/**下面就是，對請求對象進行此攔截器的負責的一系列請求前處理，由于本章我們只關注責任鏈模式的整體構建，故下面的攔截器處理邏輯，我們暫不做過多的解析**/RequestBody body = userRequest.body();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());}//到此處，此攔截器負責的，請求前的處理已經完成/**繼續通過傳進來的責任鏈對象chain調用proceed()方法，將處理后的請求傳回此方法，如此形成一個鏈路使請求能夠通過責任鏈上的攔截器能有條不紊的向后執行：除最后一個攔截器的每個攔截器在其intercept(Chain chain)方法中進行請求的前置處理完畢后都會將處理完的請求傳回到RealInterceptorChain的proceed()方法，在proceed()方法中通過index來獲取到下一個要執行的攔截器對象，調用到對應的intercept(Chain chain)方法，直到到調用到最后一個攔截器對象的intercept(Chain chain)方法時，也就是CallServerInterceptor的intercept(Chain chain)方法，才會真正發起網絡請求，并最終返回一個Response對象，而后返回其調用處，一層層回調回去，直至最初的調用的proceed()方法。**/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);String contentType = networkResponse.header("Content-Type");responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));}
?return responseBuilder.build();}

接下來我們來看最后一個攔截器的intercept(Chain chain)方法邏輯

//CallServerInterceptor.class ?
@Override public Response intercept(Chain chain) throws IOException {//與其他攔截器一樣通過攔截器鏈對象獲取到請求對象RealInterceptorChain realChain = (RealInterceptorChain) chain;Exchange exchange = realChain.exchange();Request request = realChain.request();
?long sentRequestMillis = System.currentTimeMillis();
?exchange.writeRequestHeaders(request);//而后就是進行一些前置處理后直接發起網絡請求了boolean responseHeadersStarted = false;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"))) {exchange.flushRequest();responseHeadersStarted = true;exchange.responseHeadersStart();responseBuilder = exchange.readResponseHeaders(true);}
?if (responseBuilder == null) {if (request.body().isDuplex()) {// Prepare a duplex body so that the application can send a request body later.exchange.flushRequest();BufferedSink bufferedRequestBody = Okio.buffer(exchange.createRequestBody(request, true));request.body().writeTo(bufferedRequestBody);} else {// Write the request body if the "Expect: 100-continue" expectation was met.BufferedSink bufferedRequestBody = Okio.buffer(exchange.createRequestBody(request, false));request.body().writeTo(bufferedRequestBody);bufferedRequestBody.close();}} else {exchange.noRequestBody();if (!exchange.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.exchange.noNewExchangesOnConnection();}}} else {exchange.noRequestBody();}
?if (request.body() == null || !request.body().isDuplex()) {exchange.finishRequest();}
?if (!responseHeadersStarted) {exchange.responseHeadersStart();}
?if (responseBuilder == null) {responseBuilder = exchange.readResponseHeaders(false);}
?Response response = responseBuilder.request(request).handshake(exchange.connection().handshake()).sentRequestAtMillis(sentRequestMillis).receivedResponseAtMillis(System.currentTimeMillis()).build();
?int code = response.code();if (code == 100) {// server sent a 100-continue even though we did not request one.// try again to read the actual responseresponse = exchange.readResponseHeaders(false).request(request).handshake(exchange.connection().handshake()).sentRequestAtMillis(sentRequestMillis).receivedResponseAtMillis(System.currentTimeMillis()).build();
?code = response.code();}
?exchange.responseHeadersEnd(response);
?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(exchange.openResponseBody(response)).build();}
?if ("close".equalsIgnoreCase(response.request().header("Connection"))|| "close".equalsIgnoreCase(response.header("Connection"))) {exchange.noNewExchangesOnConnection();}
?if ((code == 204 || code == 205) && response.body().contentLength() > 0) {throw new ProtocolException("HTTP " + code + " had non-zero Content-Length: " + response.body().contentLength());}//網絡請求完畢將處理完畢的結果返回return response;}

在經過最后一個攔截器的intercept(Chain chain)方法后，就會一層層將結果返回，直到回到最初的proceed()方法了，至此OkHttp的責任鏈模式就分析完畢啦~