OkHttpClient原始碼分析（二） —— RetryAndFollowUpInterceptor和BridgeInterceptor

chaychan發表於2019-01-04
HTTPclient原始碼

OkHttp攔截器

  攔截器是OkHttp中提供的一種強大機制，它可以實現網路監聽、請求以及響應重寫、請求失敗重試等功能。

OkHttpClient原始碼分析（二） —— RetryAndFollowUpInterceptor和BridgeInterceptor

如上圖所示，這就OkHttp內部提供給我們的攔截器，就是當我們發起一個http請求的時候，OkHttp就會通過這個攔截器鏈來執行http請求。其中包括:

  • RetryAndFollowUpInterceptor 重試和重定向攔截器
  • BridgeInterceptor ：橋接和適配攔截器
  • CacheInterceptor ：快取攔截器
  • ConnectInterceptor ：連結攔截器
  • CallServerInterceptor ：請求和處理響應攔截器

BridgeInterceptor和 CacheInterceptor 主要是用來補充使用者請求建立當中缺少的一些必需的http請求頭和處理快取的功能。

ConnectInterceptor 主要是負責建立可用的連結，CallServerInterceptor 主要是負責將http請求寫進網路的IO流當中，並且從網路IO流當中讀取服務端返回給客戶端的資料。

原始碼分析

getResponseWithInterceptorChain()

上篇文章 OkHttpClient原始碼分析（一）——同步、非同步請求的執行流程和原始碼分析 有提及到一個很重要的方法getResponseWithInterceptorChain()，同步請求的話，是在RealCall類中的excute()方法中呼叫到該方法，而非同步請求是在RealCall的內部類AsyncCal中的excute()方法中呼叫，檢視該方法的原始碼：

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的集合，新增了OkHttpClient中配置的攔截器集合，然後依次新增了上述提及到的那五個攔截器；

二、建立一個攔截器鏈RealInterceptorChain，並執行攔截器鏈的proceed()方法;

檢視RealInterceptorChain類的proceed()方法:

 public Response proceed(Request request, StreamAllocation streamAllocation, HttpStream httpStream,
      Connection connection) throws IOException {
      
      ...
      
      // Call the next interceptor in the chain.
    RealInterceptorChain next = new RealInterceptorChain(
        interceptors, streamAllocation, httpStream, connection, index + 1, request);
    Interceptor interceptor = interceptors.get(index);
    Response response = interceptor.intercept(next);
    
    ...
 }
複製程式碼

其中，核心的程式碼就在這裡，這裡再次建立了RealInterceptorChain物件，此時建立的是下一個攔截器鏈，傳入的是index + 1，並通過呼叫當前Interceptor的intercept()方法，將下一個攔截器鏈傳入，得到Response物件，至於攔截器的intercept()方法，下面將會分析。

RetryAndFollowUpInterceptor

主要作用是負責網路請求失敗重連，需要注意的是，並不是所有的網路請求失敗以後都可以進行重連，它是有一定的限制範圍的，OkHttp內部會幫我們檢測網路異常和響應碼的判斷，如果都在它的限制範圍內的話，就會進行網路重連。

原始碼主要看intercept()方法：

@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;
    ...
}
複製程式碼

這裡建立了一個StreamAllocation物件，StreamAllocation物件是用來建立執行Http請求所需要的網路元件的，從它名字可以看出，它是用來分配stream的，主要是用於獲取連線服務端的connection和用於與服務端進行資料傳輸的輸入輸出流 。

詳細的邏輯都在intercept()方法中的while迴圈中，這裡不做詳細介紹，主要是介紹其中的這個：

 while (true) {
    ...
    
    try {
        response = ((RealInterceptorChain) chain).proceed(request, streamAllocation, null, null);
        releaseConnection = false;
      }
      
      ...
    
    if (++followUpCount > MAX_FOLLOW_UPS) {
        streamAllocation.release();
        throw new ProtocolException("Too many follow-up requests: " + followUpCount);
    }
    
    ...
 ｝
複製程式碼

這裡我們可以發現，RealInterceptorChain呼叫proceed()方法，方法裡又建立了一個RealInterceptorChain物件（下一個攔截器鏈 index + 1），然後通過index獲取到當前執行到的攔截器，呼叫攔截器的intercept()方法，這裡intercept()方法中，再次呼叫了RealInterceptorChain的proceed()方法，形成了遞迴。

以上程式碼是對重試的次數進行判斷，由此可知，並不是無限次的進行網路重試，而是有一定的重試次數的，MAX_FOLLOW_UPS 是一個常量，值為20，也就是說最多進行20次重試，如果還不成功的話，就會釋放StreamAllocation物件和丟擲ProtocolException異常。

總結：

  1. 建立StreamAllocation物件
  2. 呼叫RealInterceptorChain.proceed()進行網路請求
  3. 根據異常結果或響應結果判斷是否要進行重新請求
  4. 呼叫下一個攔截器，對response進行處理，返回給上一個攔截器

BridgeInterceptor

同樣也是看核心方法intercept()：

@Override public Response intercept(Chain chain) throws IOException {
    Request userRequest = chain.request();
    Request.Builder requestBuilder = userRequest.newBuilder();

    ...

    if (userRequest.header("Host") == null) {
      requestBuilder.header("Host", hostHeader(userRequest.url(), false));
    }

    if (userRequest.header("Connection") == null) {
      requestBuilder.header("Connection", "Keep-Alive");
    }

    ...
  
    Response networkResponse = chain.proceed(requestBuilder.build());

    ...

    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();
  }
複製程式碼

這裡並沒有貼上整個方法的程式碼，省略了部分，主要的操作就是為發起的Request請求新增請求頭資訊，其中同樣也呼叫了proceed()方法遞迴呼叫下個攔截器，最後面是針對經過gzip壓縮過的Response進行解壓處理，這裡通過判斷是否支援gzip壓縮且請求頭裡面的"Content-Encoding"的value是否是"gzip"來判斷是否需要進行gzip解壓。

總結：

  1. 負責將使用者構建的Request請求轉化為能夠進行網路訪問的請求；
  2. 將這個符合網路請求的Request進行網路請求；
  3. 將網路請求回來的的相應Response轉化為使用者可用的Response

下一篇將為大家介紹OkHttp的快取機制，感興趣的朋友可以繼續閱讀：

OkHttpClient原始碼分析（三）—— 快取機制介紹

相關文章