2. 程式人生 > >OkHttp3原始碼分析之攔截器Interceptor

OkHttp3原始碼分析之攔截器Interceptor

阿新 • • 發佈：2019-01-22

前言

在上一篇部落格中，我們從原始碼分析了，一次非同步網路請求的整個大概表面的流程，但是涉及到某些具體的內容呢，就直接帶過了。本篇文章我們就先來了解一下在發起一次網路請求時，OkHttp是怎麼發起請求獲取響應的。這裡邊就涉及到OkHttp的一個很棒的設計——攔截器Interceptor。

分析

原始碼基於最新的版本：3.10.0。
還記得上一篇部落格中一次非同步任務中，到最後一步執行的程式碼嗎？
那就是RealCall.AsyncCall#execute()方法

@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
 
 {
          eventListener.callFailed(RealCall.this, e);
          responseCallback.onFailure(RealCall.this, e);
        }
      } finally {
        client.dispatcher().finished(this);
      }
  }

我們注意到其實真正執行網路請求，或者說入口是在

Response response = getResponseWithInterceptorChain();

這一句程式碼中。
另外，在發起同步請求的時候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);
    }
  }

核心入口是一樣，只不過我們要知道，同步請求的時候是在主執行緒中執行的，而非同步請求我們在上一篇部落格中也分析過了，是線上程池中執行的。
下面我們就來看一下RealCall#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, this, eventListener, client.connectTimeoutMillis(),
        client.readTimeoutMillis(), client.writeTimeoutMillis());

    return chain.proceed(originalRequest);
  }

首先呢，正如註釋中所說，構建一整套攔截器，就是將一個個不同的攔截器新增到一個集合中，上邊各個攔截器的功能作用我們下邊再說，先接著往下看程式碼。
Interceptor是一個介面，它有個內部介面Chain，它的具體的實現類RealInterceptorChain，顧名思義，就是攔截器鏈，就是將一個個攔截器串起來，然後執行RealInterceptorChain#proceed(Request request)方法來返回得到Response。
那麼上邊具體的實現是在另一個過載方法裡邊，下邊看一下這個過載的方法proceed(...)都幹了什麼？

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, call, eventListener, connectTimeout, readTimeout,
        writeTimeout);
    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");
    }

    if (response.body() == null) {
      throw new IllegalStateException(
          "interceptor " + interceptor + " returned a response with no body");
    }

    return response;
  }

上邊程式碼去除一些錯誤丟擲判斷的內容後，主要的邏輯就是在喚起鏈中的下一個攔截器這三行程式碼。
①第一行：

RealInterceptorChain next = new RealInterceptorChain(interceptors, streamAllocation, httpCodec,
        connection, index + 1, request, call, eventListener, connectTimeout, readTimeout,
        writeTimeout);

建立一個RealInterceptorChain物件。注意這裡傳入的一個引數index+1。
②第二行：

Interceptor interceptor = interceptors.get(index);

獲得集合中當前索引的攔截器，index初始為0。
③第三行：

Response response = interceptor.intercept(next);

呼叫當前索引攔截器的intercept(Chain chain)方法。

我們就拿集合中第一個攔截器RetryAndFollowUpInterceptor為例，
看一下RetryAndFollowUpInterceptor#intercept(Chain chain)方法：

@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 streamAllocation = new StreamAllocation(client.connectionPool(),
        createAddress(request.url()), call, eventListener, callStackTrace);
    this.streamAllocation = streamAllocation;

    int followUpCount = 0;
    Response priorResponse = null;
    while (true) {
      if (canceled) {
        streamAllocation.release();
        throw new IOException("Canceled");
      }

      Response response;
      boolean releaseConnection = true;
      try {
        //執行(index+1)攔截器鏈的proceed()方法
        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.
        if (!recover(e.getLastConnectException(), streamAllocation, 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.
        boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
        if (!recover(e, streamAllocation, requestSendStarted, request)) throw e;
        releaseConnection = false;
        continue;
      } finally {
        // We're throwing an unchecked exception. Release any resources.
        if (releaseConnection) {
          streamAllocation.streamFailed(null);
          streamAllocation.release();
        }
      }

      ...
    }
  }

上邊最關鍵的程式碼，其實也就是這一句：

response = realChain.proceed(request, streamAllocation, null, null);

我們會發現，這一句執行的是下一個攔截器鏈的proceed方法，接著回到上邊，會呼叫下一個攔截器的intercept()方法，這樣反覆相互遞迴呼叫，直到鏈的盡頭，即攔截器鏈的集合已經遍歷完成。

我們檢視其它攔截器的原始碼可以發現，他們的樣式非常類似：

@Override 
public Response intercept(Chain chain) throws IOException {
    Request request = chain.request();
    // 1、在發起請求前對request進行處理

    // 2、遞迴呼叫下一個攔截器遞迴，獲取response呼叫
    response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);

    //3、對response進行處理，返回給上一個攔截器
    return  response;     
    }
  }

那麼分析到這裡，我們思考一個問題，也可能面試中會問到：
這裡為什麼每次都重新建立RealInterceptorChain物件next，為什麼不直接複用上一層的RealInterceptorChain物件？
因為這裡是遞迴呼叫，在呼叫下一層攔截器的interupter()方法的時候，本層的 response階段還沒有執行完成，如果複用RealInterceptorChain物件，必然導致下一層修改該RealInterceptorChain物件，所以需要重新建立RealInterceptorChain物件。

我們通過一張經典圖來描述一下上面說的整個邏輯，我們可以看的更清晰一些：
這裡寫圖片描述
這裡的攔截器分層的思想就是借鑑的網路裡的分層模型的思想。請求從最上面一層到最下一層，響應從最下一層到最上一層，每一層只負責自己的任務，對請求或響應做自己負責的那塊的修改。

原始碼中核心攔截器

原始碼中核心攔截器完成了網路訪問的核心邏輯，由上邊往list中新增攔截器的順序，我們可以知道它依次呼叫順序（也可以在上圖中看出）,下邊大致瞭解一下各個攔截器所負責的內容：

  • RetryAndFollowUpInterceptor
    ①在網路請求失敗後進行重試；
    ②當伺服器返回當前請求需要進行重定向時直接發起新的請求，並在條件允許情況下複用當前連線
  • BridgeInterceptor
    這個攔截器是在v3.4.0之後由HttpEngine拆分出來的。
    ①設定內容長度，內容編碼
    ②設定gzip壓縮，並在接收到內容後進行解壓。省去了應用層處理資料解壓的麻煩
    說到這裡有一個小坑需要注意：
    原始碼中註釋也有說明，
    If we add an "Accept-Encoding: gzip" header field,
    we're responsible for also decompressing the transfer stream.
    就是說OkHttp是自動支援gzip壓縮的，也會自動新增header，這時候如果你自己添加了"Accept-Encoding: gzip"，它就不管你了，就需要你自己解壓縮。
    ③新增cookie
    ④設定其他報頭，如User-Agent,Host,Keep-alive等。其中Keep-Alive是實現多路複用的必要步驟
  • CacheInterceptor
    這個攔截器是在v3.4.0之後由HttpEngine拆分出來的。
    ①當網路請求有符合要求的Cache時直接返回Cache
    ②當伺服器返回內容有改變時更新當前cache
    ③如果當前cache失效，刪除
  • ConnectIntercetot
    這個攔截器是在v3.4.0之後由HttpEngine拆分出來的。
    為當前請求找到合適的連線，可能複用已有連線也可能是重新建立的連線，返回的連線由連線池負責決定
  • CallServerInterceptor
    負責向伺服器發起真正的訪問請求，並在接收到伺服器返回後讀取響應返回。

自定義攔截器

除了官方已經寫好的比較核心的攔截器之外，我們還可以自定義攔截器。比如官方給的一個LoggingInterceptor來列印請求或者響應的時間日誌；再比如我們在向伺服器傳輸比較大的資料的時候，想對post的資料進行Gzip壓縮，這個可以參考github上的這個issue：
Add GZip Request Compression #350
或者我之前寫的一篇部落格：
Okhttp3請求網路開啟Gzip壓縮

首先我們看一張官方wiki的圖：
這裡寫圖片描述

攔截器可以被註冊為應用攔截器（application interceptors）或者網路攔截器（network interceptors）。

其實在上邊原始碼分析中，RealCall#getResponseWithInterceptorChain()這個方法去構建一個攔截器集合的時候（也決定了其遞迴呼叫順序）：

Response getResponseWithInterceptorChain() throws IOException {
    // Build a full stack of interceptors.
    List<Interceptor> interceptors = new ArrayList<>();
    interceptors.addAll(client.interceptors());//Application 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());//Network Interceptors
    }
    interceptors.add(new CallServerInterceptor(forWebSocket));
    ...
    return chain.proceed(originalRequest);
  }

我們可以知道應用攔截器和網路攔截器在遞迴呼叫的順序。

那麼，這兩者到底有什麼區別呢？這裡給出官方wiki的翻譯：

Application Interceptors

通過OkHttpClient.Builder的addInterceptor()註冊一個 application interceptor:

OkHttpClient client = new OkHttpClient.Builder()
    .addInterceptor(new LoggingInterceptor())
    .build();
Request request = new Request.Builder()
    .url("http://www.publicobject.com/helloworld.txt")
    .header("User-Agent", "OkHttp Example")
    .build();
Response response = client.newCall(request).execute();
response.body().close();

URLhttp://www.publicobject.com/helloworld.txt
會重定向到https://publicobject.com/helloworld.txt,
OkHttp會自動跟蹤這次重定向。application interceptor會被呼叫一次，並且通過呼叫chain.proceed()返回攜帶有重定向後的response。

INFO: Sending request http://www.publicobject.com/helloworld.txt on null
User-Agent: OkHttp Example
INFO: Received response for https://publicobject.com/helloworld.txt in 1179.7ms
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/plain
Content-Length: 1759
Connection: keep-alive

我們可以看到，會重定向是因為response.request().url()和request.url()是不同的，日誌也列印了兩個不同的URL。

Network Interceptors

註冊一個Network Interceptors的方式是非常類似的，只需要將addInterceptor()替換為addNetworkInterceptor()：

OkHttpClient client = new OkHttpClient.Builder()
    .addNetworkInterceptor(new LoggingInterceptor())
    .build();
Request request = new Request.Builder()
    .url("http://www.publicobject.com/helloworld.txt")
    .header("User-Agent", "OkHttp Example")
    .build();
Response response = client.newCall(request).execute();
response.body().close();

當我們執行上面這段程式碼，這個interceptor會執行兩次。一次是呼叫在初始的request http://www.publicobject.com/helloworld.txt，另外一次是呼叫在重定向後的request https://publicobject.com/helloworld.txt。

INFO: Sending request http://www.publicobject.com/helloworld.txt on Connection{www.publicobject.com:80, proxy=DIRECT hostAddress=54.187.32.157 cipherSuite=none protocol=http/1.1}
User-Agent: OkHttp Example
Host: www.publicobject.com
Connection: Keep-Alive
Accept-Encoding: gzip
INFO: Received response for http://www.publicobject.com/helloworld.txt in 115.6ms
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html
Content-Length: 193
Connection: keep-alive
Location: https://publicobject.com/helloworld.txt
INFO: Sending request https://publicobject.com/helloworld.txt on Connection{publicobject.com:443, proxy=DIRECT hostAddress=54.187.32.157 cipherSuite=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA protocol=http/1.1}
User-Agent: OkHttp Example
Host: publicobject.com
Connection: Keep-Alive
Accept-Encoding: gzip
INFO: Received response for https://publicobject.com/helloworld.txt in 80.9ms
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/plain
Content-Length: 1759
Connection: keep-alive

那麼我們如何選擇這兩種攔截器的使用？它們各有各的優缺點，我們可以根據自己需要來合理選擇。

  • Application Interceptors

    • 不需要關心由重定向、重試請求等造成的中間response產物。
    • 總會被呼叫一次，即使HTTP response是從快取（cache）中獲取到的。
    • 關注原始的request，而不關心注入的headers，比如If-None-Match。
    • interceptor可以被取消呼叫，不呼叫Chain.proceed()。
    • interceptor可以重試和多次呼叫Chain.proceed()。

  • Network Interceptors

    • 可以操作由重定向、重試請求等造成的中間response產物。
    • 如果是從快取中獲取cached responses ，導致中斷了network，是不會呼叫這個interceptor的。
    • 資料在整個network過程中都可以通過Network Interceptors監聽。
    • 可以獲取攜帶了request的Connection。

結語

本篇文章算是接著上篇文章將整個網路請求中重要的互動步驟作了原始碼分析，詳細瞭解了攔截器的相關內容。
在之後，我們再對OkHttp的任務排程佇列，快取，連線等方面的內容作深入瞭解。

相關推薦

OkHttp3原始碼分析之攔截器Interceptor

前言 在上一篇部落格中，我們從原始碼分析了，一次非同步網路請求的整個大概表面的流程，但是涉及到某些具體的內容呢，就直接帶過了。本篇文章我們就先來了解一下在發起一次網路請求時，OkHttp是怎麼發起請求獲取響應的。這裡邊就涉及到OkHttp的一個很棒的設計——攔

SpringMVC總結之攔截器Interceptor（例：登入攔截器）

目錄   1.前言 2.HandleInterceptor介面 3.攔截器實現使用者登入攔截 1.前言 使用攔截器，主要是為了攔截使用者的請求並進行相應的處理，比如通過攔截器進行使用者登入驗證，使用者許可權驗證等；SpringMVC中的攔截器攔截請求是通過實

springMVC原始碼分析--HandlerInterceptor攔截器（一）

對SpringMVC有所瞭解的人肯定接觸過HandlerInterceptor攔截器，HandlerInterceptor介面給我們提供了3個方法：（1）preHandle: 在執行controller處理之前執行，返回值為boolean ,返回值為true時接著執行post

springMVC原始碼分析--HandlerInterceptor攔截器呼叫過程（二）

在上一篇部落格springMVC原始碼分析--HandlerInterceptor攔截器（一）中我們介紹了HandlerInterceptor攔截器相關的內容，瞭解到了HandlerInterceptor提供的三個介面方法：（1）preHandle: 在執行controlle

Java三大器之攔截器(Interceptor)的實現原理及程式碼示例

轉載 https://blog.csdn.net/reggergdsg/article/details/52962774 1，攔截器的概念     java裡的攔截器是動態攔截Action呼叫的物件，它提供了一種機制可以使開發者在一個Action執行的前後執行一段程式碼，也可以在一個Action 執

Jfinal 源碼分析之攔截器的使用

一次 stat ret 目前 核心 不同 手動 tex 包括 Jfinal 源碼分析之攔截器的使用 官方文檔初始攔截器： Interceptor可以對方法進行攔截，並提供機會再方法的前後添加切面代碼，實現AOP的核心目標。 攔截器相關的類的分析： Interceptor接

Mybatis之攔截器Interceptor

    使用mybatis時用PageHelper進行分頁，用到了PageInterceptor，藉此瞭解下m

SpringMVC原始碼深度解析之攔截器&過濾器&檢視層&非同步原始碼分析

SpringMVC註解方式開啟檢視層 整合Jsp 檢視層 @Bean public InternalResour

Netty 原始碼分析之拆包器的奧祕

為什麼要粘包拆包 為什麼要粘包 首先你得了解一下TCP/IP協議，在使用者資料量非常小的情況下，極端情況下，一個位元組，該TCP資料包的有效載荷非常低，傳遞100位元組的資料，需要100次TCP傳送，100次ACK，在應用及時性要求不高的情況下，將這100個有效資料拼接成一個數據包，那會縮短到一個TCP資

Qt原始碼分析之事件分發器QEventDispatcherWin32

分析Qt原始碼一則想自己在開發學習中有積累，同時自己也一直有一種理念，使用她那麼就更深入的認識她。 如果有分析不正確的，還煩請各位看官指正。 事件分發器建立 在QCoreApplication建構函式中 if (!QCoreApplicationPrivate

一步步實現windows版ijkplayer系列文章之三——Ijkplayer播放器原始碼分析之音視訊輸出——音訊篇

一步步實現windows版ijkplayer系列文章之三——Ijkplayer播放器原始碼分析之音視訊輸出——音訊篇 這篇文章的ijkplayer音訊原始碼研究我們還是選擇Android平臺，它的音訊解碼是不支援硬解的，音訊播放使用的API是OpenSL ES或AudioTrack。 OpenSL ES

STL原始碼分析之迭代器

前言 迭代器是將演算法和容器兩個獨立的泛型進行調和的一個介面. 使我們不需要關係中間的轉化是怎麼樣的就都能直接使用迭代器進行資料訪問. 而迭代器最重要的就是對operator *和operator->進行過載, 使它表現的像一個指標. 型別 迭代器根據移動特性和實施操作

STL原始碼分析之第二級配置器

前言 第一級是直接呼叫malloc分配空間, 呼叫free釋放空間, 第二級三就是建立一個記憶體池, 小於128位元組的申請都直接在記憶體池申請, 不直接呼叫malloc和free. 本節分析第二級空間配置器, STL將第二級配置器設定為預設的配置器, 所以只要一次申請的空間不超過1

STL原始碼分析之第一級配置器

前言 上一節我們分析了空間配置器對new的配置, 而STL將空間配置器分為了兩級, 第一級是直接呼叫malloc分配空間, 呼叫free釋放空間, 第二級三就是建立一個記憶體池, 小於128位元組的申請都直接在記憶體池申請, 不直接呼叫malloc和free. 本節我們就先分析第

STL原始碼分析之空間配置器

前言 SGI STL將new的申請空間和呼叫建構函式的兩個功能分開實現, 如果對new不太清楚的, 可以先去看看這一篇new實現再來看配置器也不遲. 本節是STL分析的第一篇, 主要分析STL各個部分都會出現的alloc實現, 雖然每個部分都只會預設呼叫它, 不瞭解它也可以看懂分析,

STL原始碼分析之multimap配接器

前言 前面我們分析了map, 知道map是不允許插入相同的鍵值的, 也不會儲存第二次的資料, 而本節分析的multimap與map不同, 它允許多個重複的鍵值插入. mutimap操作 int main() { multimap<string, int> mul

STL原始碼分析之multiset配接器

前言 前面也分析過set, 並且set不能插入相同的鍵, 本節分析的multiset與set不同之處就是他允許插入相同的鍵. multiset操作 int main() { multiset<string> multi; // 允許重複插入鍵 mult

STL原始碼分析之map配接器

前言 上一節分析了pair結構, 正是為map分析做鋪墊, map本身實現也不難, 其資料儲存是pair, 儲存結構是RB-tree, 即map也並不能說是關聯容器, 而應該是配接器. map操作 map的insert必須是以pair為儲存結構, 當然也可以直接使用make_

STL原始碼分析之set配接器

前言 上面兩節我們分析了RB-tree, 同時我們也知道了rb-tree的插入操作還分為可重複插入和不可重複插入(insert_unique). 本節分析set, 嚴格意義說set就是修改了底層容器介面的, 所以應該是配置器. set就是將RB-tree作為底層容器, 以insert

STL原始碼分析之queue配接器

前言 上一節分析了stack實現, stack是修改了deque的介面而實現的一個功能簡單的結構, 本節分析的queue也是用deque為底層容器封裝. queue資料都是在頭部進行操作的, 之允許進行push和pop操作. queue分析 queue結構 #ifnd