OkHttp 是一套處理 HTTP 網(wǎng)絡(luò)請(qǐng)求的依賴庫，由 Square 公司設(shè)計(jì)研發(fā)并開源，目前可以在 Java 和 Kotlin 中使用。

對(duì)于 Android App 來說，OkHttp 現(xiàn)在幾乎已經(jīng)占據(jù)了所有的網(wǎng)絡(luò)請(qǐng)求操作，RetroFit + OkHttp 實(shí)現(xiàn)網(wǎng)絡(luò)請(qǐng)求似乎成了一種標(biāo)配。因此它也是每一個(gè) Android 開發(fā)工程師的必備技能，了解其內(nèi)部實(shí)現(xiàn)原理可以更好地進(jìn)行功能擴(kuò)展、封裝以及優(yōu)化。

異步執(zhí)行的隊(duì)列

先從OkHttp的基本使用切入：

先是構(gòu)建請(qǐng)求，通過 Builder() 構(gòu)建初始化Dispatcher，Http協(xié)議類型protocols，Cookie壓縮類型，dns等參數(shù)。

請(qǐng)求操作的起點(diǎn)從 OkHttpClient.newCall().enqueue() 方法開始。

• newCall

okHttpClient.newCall 把 request 封裝轉(zhuǎn)成一個(gè) RealCall

這個(gè)方法會(huì)返回一個(gè) RealCall 類型的對(duì)象，通過它將網(wǎng)絡(luò)請(qǐng)求操作添加到請(qǐng)求隊(duì)列中。

enqueue方法將Callable對(duì)象轉(zhuǎn)換成一個(gè)異步的AsyncCall的runnable對(duì)象。

AsyncCall是RealCall的內(nèi)部類，并且把它交給了client的dispatch對(duì)象。

Dispatcher 是 OkHttpClient 的調(diào)度器，是一種門戶模式。主要用來實(shí)現(xiàn)執(zhí)行、取消異步請(qǐng)求操作。本質(zhì)上是內(nèi)部維護(hù)了一個(gè)線程池去執(zhí)行異步操作，并且在 Dispatcher 內(nèi)部根據(jù)一定的策略，保證最大并發(fā)個(gè)數(shù)、同一 host 主機(jī)允許執(zhí)行請(qǐng)求的線程個(gè)數(shù)等。

在enqueue方法會(huì)先判斷在運(yùn)行的asyncCalls數(shù)量是不是已經(jīng)達(dá)到最大的64個(gè)，并且還會(huì)判斷當(dāng)前運(yùn)行的主機(jī)數(shù)（也就是網(wǎng)頁URL主要部分，端口前面的主地址）是不是超過了最大的5個(gè)。如果都小于，則將當(dāng)前的AsyncCall加入到正在執(zhí)行的集合中，否則加入準(zhǔn)備執(zhí)行的集合中。加入到正在執(zhí)行的集合中，就會(huì)調(diào)用線程池的執(zhí)行方法。最終去了AsyncCall的execute方法

這里為什么不是run方法的原因是因?yàn)锳syncCall繼承的NamedRunnable的run方法中調(diào)用了execute方法

在AsyncCall的execute方法中，就會(huì)來到最重要的一個(gè)部分，也就是攔截器的部分。而等攔截器執(zhí)行完，攔截器方法返回的就是Response。

攔截器

而真正獲取請(qǐng)求結(jié)果的方法是在 getResponseWithInterceptorChain 方法中，從名字也能看出其內(nèi)部是一個(gè)攔截器的調(diào)用鏈，具體代碼如下：

在添加上述幾個(gè)攔截器之前，會(huì)調(diào)用 client.interceptors 將開發(fā)人員設(shè)置的攔截器添加到列表當(dāng)中。

而如果是需要在進(jìn)行連接后回傳數(shù)據(jù)進(jìn)行攔截的的話，也會(huì)通過調(diào)用 client.networkInterceptors。

例如自定義緩存攔截器加載在后面，也就是addNetworkInterceptor，來實(shí)現(xiàn)自定義緩存策略攔截器。如果是調(diào)用 client.interceptors ，則因?yàn)榛貍鲾?shù)據(jù)已經(jīng)進(jìn)過CacheInterceptor，所以無法生效。而調(diào)用 client.networkInterceptors 則是在接收到resp后，resp會(huì)先來到 networkInterceptors 添加的攔截器，進(jìn)行緩存策略的更改，再回傳給 CacheInterceptor 上層進(jìn)行緩存策略判斷。

RetryAndFollowUpInterceptor攔截器

內(nèi)部為一個(gè)死循環(huán)，每次都會(huì)重試丟給下一級(jí)處理。

@Override public Response intercept(Chain chain) throws IOException {
    Request request = chain.request();
    RealInterceptorChain realChain = (RealInterceptorChain) chain;
    Call call = realChain.call();

    /**
    部分代碼省略
    **/    

    while (true) {
      /**
      部分代碼省略
      **/    
      Response response;
      boolean releaseConnection = true;
      try {
        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 {
        /**
        部分代碼省略
        **/    
      }

      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()), call, eventListener, callStackTrace);
        this.streamAllocation = streamAllocation;
      } else if (streamAllocation.codec() != null) {
        throw new IllegalStateException("Closing the body of " + response
            + " didn't close its backing stream. Bad interceptor?");
      }

      /**
      部分代碼省略
      **/    

  }

是否跳出循環(huán)看是否為致命異常，如果不是致命異常，例如連接超時(shí)，則進(jìn)行重試。

并且在這個(gè)攔截器中，還會(huì)處理重定向307、308等。會(huì)通過獲取新的頭部信息，生產(chǎn)一個(gè)新的請(qǐng)求，交給下級(jí)。

RetryAndFollowUpInterceptor中followUpRequest方法處理狀態(tài)碼

BridgeInterceptor攔截器

主要設(shè)置一些通用的請(qǐng)求頭，Content-type，connection，content-length，Cookie。做一些返回的處理，如果被壓縮，采用Zip解壓，保存Cookie。

@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());
    }

    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();
  }

CacheInterceptor攔截器

負(fù)責(zé) HTTP 請(qǐng)求的緩存處理。

CacheInterceptor 主要做以下幾件事情：

• 根據(jù) Request 獲取當(dāng)前已有緩存的 Response（有可能為 null），并根據(jù)獲取到的緩存 Response，創(chuàng)建 CacheStrategy 對(duì)象。

• 通過 CacheStrategy 判斷當(dāng)前緩存中的 Response 是否有效（比如是否過期），如果緩存 Response 可用則直接返回，否則調(diào)用 chain.proceed() 繼續(xù)執(zhí)行下一個(gè)攔截器，也就是發(fā)送網(wǎng)絡(luò)請(qǐng)求從服務(wù)器獲取遠(yuǎn)端 Response。具體如下：

• 如果從服務(wù)器端成功獲取 Response，再判斷是否將此 Response 進(jìn)行緩存操作。

ConnectInterceptor攔截器

負(fù)責(zé)建立與服務(wù)器地址之間的連接，也就是 TCP 連接。

建立Socket連接連接緩存，封裝HttpCodec里面封裝了okio的輸入輸出流，就可以向服務(wù)器寫數(shù)據(jù)和返回?cái)?shù)據(jù)。

CallServerInterceptor攔截器

CallServerInterceptor 是 OkHttp 中最后一個(gè)攔截器，也是 OkHttp 中最核心的網(wǎng)路請(qǐng)求部分，其 intercept 方法如下：

如上圖所示，主要分為 2 部分。藍(lán)線以上的操作是向服務(wù)器端發(fā)送請(qǐng)求數(shù)據(jù)，藍(lán)線以下代表從服務(wù)端獲取相應(yīng)數(shù)據(jù)并構(gòu)建 Response 對(duì)象。

總結(jié)

這節(jié)課主要分析了 OkHttp 的源碼實(shí)現(xiàn)：

• OkHttp 內(nèi)部是一個(gè)門戶模式，所有的下發(fā)工作都是通過一個(gè)門戶 Dispatcher 來進(jìn)行分發(fā)。

• 在網(wǎng)絡(luò)請(qǐng)求階段通過責(zé)任鏈模式，鏈?zhǔn)降恼{(diào)用各個(gè)攔截器的 intercept 方法。