1 使用回顧

我們在前面博文《Android網絡編程(九) 之 OkHttp3框架的使用》中已經對OkHttp的使用進行過介紹。今天我們接着往下來閱讀OkHttp的關鍵源碼從而它進行更加深入的理解。開始前，先來回顧一下簡單的使用，通過使用步驟來深入分析每行代碼背後的原理，代碼如：

private void test() {
        // 1 創建 OkHttpClient 對象，並可設置連接超時時間
//        OkHttpClient client = new OkHttpClient.Builder()
//                .connectTimeout(10, TimeUnit.SECONDS)
//                .readTimeout(10,TimeUnit.SECONDS)
//                .writeTimeout(10,TimeUnit.SECONDS)
//                .cache(new Cache(cacheDirectory, cacheSize))
//                .build();
        OkHttpClient client = new OkHttpClient();

        // 2 創建一個Request請求
        final Request request = new Request.Builder()
                .url("http://wwww.baidu.com")
                .get() //默認就是GET請求，可以不寫
//                .post(RequestBody.create(MediaType.parse("text/x-markdown; charset=utf-8"), "Hello world!"))
                .build();

        // 3 創建一個call對象
        Call call = client.newCall(request);

        // 4 發起請求
//        Response response = call.execute();
        call.enqueue(new Callback() {
            @Override
            public void onFailure(Call call, IOException e) {
                e.printStackTrace();
            }
            @Override
            public void onResponse(Call call, Response response) throws IOException {
                // 這裏是子線程
//                final String res = response.body().string();
//                runOnUiThread(new Runnable() {
//                    public void run() {
//                        TextView控件對象.setText(res);
//                    }
//                });
            }
        });
    }

可見其步驟大概是：

1 創建 OkHttpClient 對象，並可設置其連接超時時間和緩存信息；

2 創建一個Request請求，指定Url和請求方式，請求方式get是默認可不寫，而Post的話如上述註釋代碼代表post一個字符串；
3 使用OkHttpClient對象的newCall方法傳入Request對象來創建一個Call對象；
4 Call對象發起請求，如果同步請求就使用：Response response = call.execute();。

2 原理分析

因爲OkHttp 從4.0.0 RC 3版本後它的實現語言從Java變成了Kotlin來實現。所以我們在開始之前，如果你想還是針對Java代碼進行分析，可先將版本回退到3.14.4版本。

2.1 創建OkHttpClient對象

OkHttpClient的創建是通過一個構造器模式進行的初始化，其中包括：任務分發器、支持協議、TLS版本、連接池、超時時長等信息。如以下注釋，我們下面將重要來關注Dispatcher任務分發器和ConnectionPool連接池。

OkHttpClient.java

public Builder() {
  dispatcher = new Dispatcher();						// **任務分發器**
  protocols = DEFAULT_PROTOCOLS;						// 支持的協議
  connectionSpecs = DEFAULT_CONNECTION_SPECS;					// TLS版本和連接協議
  eventListenerFactory = EventListener.factory(EventListener.NONE);	        // 事件列表監聽器
  proxySelector = ProxySelector.getDefault();					// 代理選擇器
  if (proxySelector == null) {
    proxySelector = new NullProxySelector();
  }
  cookieJar = CookieJar.NO_COOKIES;						// Cookie
  socketFactory = SocketFactory.getDefault();					// Socket工廠
  hostnameVerifier = OkHostnameVerifier.INSTANCE;				// 主機名
  certificatePinner = CertificatePinner.DEFAULT;				// 證書鏈
  proxyAuthenticator = Authenticator.NONE;					// 代理身份驗證
  authenticator = Authenticator.NONE;						// 本地驗證
  connectionPool = new ConnectionPool();					// **連接池**
  dns = Dns.SYSTEM;								// 基礎域名
  followSslRedirects = true;							// SSL重定向
  followRedirects = true;							// 本地重定向
  retryOnConnectionFailure = true;						// 連接失敗重試
  callTimeout = 0;								// 請求超時時間
  connectTimeout = 10_000;							// 連接超時時間
  readTimeout = 10_000;								// 讀取超時時間
  writeTimeout = 10_000;							// 寫入超時時間
  pingInterval = 0;								// 命令間隔
}

2.1.1 Dispatcher任務分發器

Dispatcher.java

public final class Dispatcher {
/** 總的最大請求數 */
  private int maxRequests = 64;
/** 每臺主機最大請求數 */
  private int maxRequestsPerHost = 5;
  private @Nullable Runnable idleCallback;

  /** 執行調用的線程池 */
  private @Nullable ExecutorService executorService;

  /** 準備執行的異步請求隊列 */
  private final Deque<AsyncCall> readyAsyncCalls = new ArrayDeque<>();

  /** 正在運行的異步請求隊列,包括尚未完成的已取消呼叫 */
  private final Deque<AsyncCall> runningAsyncCalls = new ArrayDeque<>();

  /** 正在運行的同步請求隊列，包括尚未完成的已取消呼叫 */
  private final Deque<RealCall> runningSyncCalls = new ArrayDeque<>();

  public Dispatcher(ExecutorService executorService) {
    this.executorService = executorService;
  }

  public Dispatcher() {
  }

  public synchronized ExecutorService executorService() {
    if (executorService == null) {
      executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
          new SynchronousQueue<>(), Util.threadFactory("OkHttp Dispatcher", false));
    }
    return executorService;
  }
  // ……
}

Dispatcher類雖然它的構造函數是空的，但實際上從它的成員變量能發現信息量很多，如三個雙向的任務隊列和一個線程池。其中三個隊列分別是：準備執行的異步請求隊列 readyAsyncCalls、正在運行的異步請求隊列 runningAsyncCalls 和正在運行的同步請求隊列 runningSyncCalls。而線程池是一個沒有核心線程，線程數量無上限，空閒60秒回收，適用於大量耗時較短的異常任務的線程池，它用於任務工作。

2.1.2 ConnectionPool連接池

ConnectionPool.java

public final class ConnectionPool {
  final RealConnectionPool delegate;

  /**
   * Create a new connection pool with tuning parameters appropriate for a single-user application.
   * The tuning parameters in this pool are subject to change in future OkHttp releases. Currently
   * this pool holds up to 5 idle connections which will be evicted after 5 minutes of inactivity.
   */
  public ConnectionPool() {
    this(5, 5, TimeUnit.MINUTES);
  }

  public ConnectionPool(int maxIdleConnections, long keepAliveDuration, TimeUnit timeUnit) {
    this.delegate = new RealConnectionPool(maxIdleConnections, keepAliveDuration, timeUnit);
  }

  /** Returns the number of idle connections in the pool. */
  public int idleConnectionCount() {
    return delegate.idleConnectionCount();
  }

  /** Returns total number of connections in the pool. */
  public int connectionCount() {
    return delegate.connectionCount();
  }

  /** Close and remove all idle connections in the pool. */
  public void evictAll() {
    delegate.evictAll();
  }
}

RealConnectionPool.java

public final class RealConnectionPool {
  /**
   * Background threads are used to cleanup expired connections. There will be at most a single
   * thread running per connection pool. The thread pool executor permits the pool itself to be
   * garbage collected.
   */
  private static final Executor executor = new ThreadPoolExecutor(0 /* corePoolSize */,
      Integer.MAX_VALUE /* maximumPoolSize */, 60L /* keepAliveTime */, TimeUnit.SECONDS,
      new SynchronousQueue<>(), Util.threadFactory("OkHttp ConnectionPool", true));
  // ……
  private final Deque<RealConnection> connections = new ArrayDeque<>();
  final RouteDatabase routeDatabase = new RouteDatabase();
  boolean cleanupRunning;
  // ……
  public RealConnectionPool(int maxIdleConnections, long keepAliveDuration, TimeUnit timeUnit) {
    this.maxIdleConnections = maxIdleConnections;
    this.keepAliveDurationNs = timeUnit.toNanos(keepAliveDuration);

    // ……
  }
  // ……
}

ConnectionPool類構造函數中也是創建了一個RealConnectionPool對象，傳入了兩個參數值：最大空閒連接數5個和連接保活時間是5分鐘。

而RealConnectionPool類裏頭存在着一個線程池，該線程池沒有核心線程，線程數量無上限，空閒60秒回收，用於清理長時間閒置的和泄漏的連接。類裏還有一個用於管理所有的連接的雙端隊列Deque<RealConnection>。

2.2創建一個Request請求對象

Request.java

public Builder() {
  this.method = "GET";
  this.headers = new Headers.Builder();
}

Builder(Request request) {
  this.url = request.url;
  this.method = request.method;
  this.body = request.body;
  this.tags = request.tags.isEmpty()
      ? Collections.emptyMap()
      : new LinkedHashMap<>(request.tags);
  this.headers = request.headers.newBuilder();
}

Request類比較簡單，就是做一些傳入url、get/post、body等信息

3.3創建Call對象

通過前面步驟創建了OkHttpClient和Request對象後，便可使用OkHttpClient對象的newCall方法傳入Request對象，來看看newCall方法的代碼：

Dispatcher.java

@Override public Call newCall(Request request) {
  return RealCall.newRealCall(this, request, false /* for web socket */);
}

RealCall.java

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;
}
private RealCall(OkHttpClient client, Request originalRequest, boolean forWebSocket) {
  this.client = client;
  this.originalRequest = originalRequest;
  this.forWebSocket = forWebSocket;
}

3.3.1 Transmitter發射器

Transmitter.java

public Transmitter(OkHttpClient client, Call call) {
  this.client = client;
  this.connectionPool = Internal.instance.realConnectionPool(client.connectionPool());
  this.call = call;
  this.eventListener = client.eventListenerFactory().create(call);
  this.timeout.timeout(client.callTimeoutMillis(), MILLISECONDS);
}

在上面newRealCall方法內創建了一個RealCall對象後再創建了一個Transmitter對象，並傳入OkHttpClient對象和RealCall對象。Transmitter構造函數除了獲得傳入的兩個參數對象外，還獲得了OkHttpClent中的連接池和事件列表監聽器。Transmitter主要是用於判斷是否有可以重用的連接或者對沒用的連接需釋放。

3.4 發起異步請求

異步請求調用了call對象的enqueue方法，並傳入回調接口，繼續看代碼：

RealCall.java

@Override public void enqueue(Callback responseCallback) {
  synchronized (this) {
    if (executed) throw new IllegalStateException("Already Executed");
    executed = true;
  }
  transmitter.callStart();
  client.dispatcher().enqueue(new AsyncCall(responseCallback));
}

方法中可見，短短几行代碼做了三件事情：

先進行了判斷是否已執行過，如果已經執行過便拋出異常；
開始調用了Transmitter對象的callStart方法，通知網絡請求開始；
創建一個AsyncCall異步任務對象並傳遞給任務分發器。

任務調度器Dispatcher#enqueue方法

Dispatcher.java

void enqueue(AsyncCall call) {
  synchronized (this) {
    // 關鍵代碼1，將任務添加到準備運行的異步請求隊列中
    readyAsyncCalls.add(call);

    // Mutate the AsyncCall so that it shares the AtomicInteger of an existing running call to
    // the same host.
    if (!call.get().forWebSocket) {
      // 關鍵代碼2，查找是否存在同一主機的任務
      AsyncCall existingCall = findExistingCallWithHost(call.host());
      if (existingCall != null) call.reuseCallsPerHostFrom(existingCall);
    }
  }
  // 關鍵代碼3，分配任務並執行
  promoteAndExecute();
}

enqueue方法主要做了3件事情：

將任務添加到準備運行的異步請求隊列中；
查找同一主機的任務；
分配任務並執行。

findExistingCallWithHost方法查找同一主機的任務

Dispatcher.java

@Nullable private AsyncCall findExistingCallWithHost(String host) {
  for (AsyncCall existingCall : runningAsyncCalls) {
    if (existingCall.host().equals(host)) return existingCall;
  }
  for (AsyncCall existingCall : readyAsyncCalls) {
    if (existingCall.host().equals(host)) return existingCall;
  }
  return null;
}

上述方法可見，方法中首先遍歷了正在運行的異步請求隊列然後再遍歷準備運行的異步請求隊列，來返回是否存在同一主機的任務。

promoteAndExecute方法分配任務並執行

Dispatcher.java

private boolean promoteAndExecute() {
  assert (!Thread.holdsLock(this));

  List<AsyncCall> executableCalls = new ArrayList<>();
  boolean isRunning;
  synchronized (this) {
    for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {
      AsyncCall asyncCall = i.next();

      if (runningAsyncCalls.size() >= maxRequests) break; // Max capacity.
      if (asyncCall.callsPerHost().get() >= maxRequestsPerHost) continue; // Host max capacity.

      i.remove();
      asyncCall.callsPerHost().incrementAndGet();
      executableCalls.add(asyncCall);
      runningAsyncCalls.add(asyncCall);
    }
    isRunning = runningCallsCount() > 0;
  }

  for (int i = 0, size = executableCalls.size(); i < size; i++) {
    AsyncCall asyncCall = executableCalls.get(i);
    asyncCall.executeOn(executorService());
  }

  return isRunning;
}

上述方法可見，對準備隊列進行了遍歷，並判斷正在運行的請求隊列是否 >= 最大請求數（默認64）和判斷此請求所屬主機的正在執行任務 >= 最大值（默認5），如果條件沒問題，便將本身任務從準備隊列移除並添加到正在運行的隊列。最後遍歷剛纔添加到正在運行的隊列對其調用executeOn方法傳入Dispatcher中的線程池進行執行任務。

executeOn方法執行任務

RealCall.java

final class AsyncCall extends NamedRunnable {
  // ……
  void executeOn(ExecutorService executorService) {
    assert (!Thread.holdsLock(client.dispatcher()));
    boolean success = false;
    try {
      // 關鍵代碼
      executorService.execute(this);
      success = true;
    } catch (RejectedExecutionException e) {
      InterruptedIOException ioException = new InterruptedIOException("executor rejected");
      ioException.initCause(e);
      transmitter.noMoreExchanges(ioException);
      responseCallback.onFailure(RealCall.this, ioException);
    } finally {
      if (!success) {
        client.dispatcher().finished(this); // This call is no longer running!
      }
    }
  }

  @Override protected void execute() {
    boolean signalledCallback = false;
    // 開始超時計算
    transmitter.timeoutEnter();
    try {
      // 關鍵代碼：調用 getResponseWithInterceptorChain()獲得響應內容
      Response response = getResponseWithInterceptorChain();
      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);
      }
    } catch (Throwable t) {
      cancel();
      if (!signalledCallback) {
        IOException canceledException = new IOException("canceled due to " + t);
        canceledException.addSuppressed(t);
        // 關鍵代碼：返回取消的失敗的請求響應
        responseCallback.onFailure(RealCall.this, canceledException);
      }
      throw t;
    } finally {
      // 關鍵代碼：將任務從正在運行隊列中移除
      client.dispatcher().finished(this);
    }
  }
}

因爲AsyncCall繼承於NamedRunnable，而NamedRunnable又繼承於Runnable，所以AsyncCall方法中關鍵代碼：executorService.execute(this);最終會調用到execute方法去。execute方法內，先開始了超時計算，接着重點調用了getResponseWithInterceptorChain方法來獲得請求結果，然後根據情況返回我們傳入的Callback接口中的onResponse或onFailure方法，最後無論成功與否將任務從正在運行異步隊列中移除。

3.5發起同步請求

認識了異步請求過程後，再來看同步請求會發現很多相同的地方，如代碼。

RealCall.java

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

上述方法，可見完成了6件事情：

先進行了判斷是否已執行過，如果已經執行過便拋出異常；
開始調用了Transmitter對象的timeoutEnter方法，開始超時計算；
開始調用了Transmitter對象的callStart方法，通知網絡請求開始；
任務自身添加到正在運行的同步請求隊列；
仍然是調用了getResponseWithInterceptorChain方法來獲得請求結果；
最後無論成功與否將任務從正在運行同步隊列中移除。

3.6 通過getResponseWithInterceptorChain方法認識攔截器

異步請求和同步請求最終核心都調用到getResponseWithInterceptorChain方法才返回結果，所以我們來重點看看getResponseWithInterceptorChain是做了什麼事情。

RealCall.java

Response getResponseWithInterceptorChain() throws IOException {
  // 關鍵代碼1，創建一個攔截器列表
  List<Interceptor> interceptors = new ArrayList<>();
  interceptors.addAll(client.interceptors());				// 添加Application攔截器，也就是開發者可以自定義的應用攔截器
  interceptors.add(new RetryAndFollowUpInterceptor(client));		// 添加重定向攔截器		
  interceptors.add(new BridgeInterceptor(client.cookieJar()));	        // 添加必要的請求頭信息、gzip處理攔截器
  interceptors.add(new CacheInterceptor(client.internalCache()));	// 添加緩存處理攔截器
  interceptors.add(new ConnectInterceptor(client));			// 添加連接攔截器
  if (!forWebSocket) {
    interceptors.addAll(client.networkInterceptors());		        // 添加Network攔截器，也就是開發者可以自定義的網絡攔截器
  }
  interceptors.add(new CallServerInterceptor(forWebSocket));		// 添加訪問服務器攔截器

  Interceptor.Chain chain = new RealInterceptorChain(interceptors, transmitter, null, 0,
      originalRequest, this, client.connectTimeoutMillis(),
      client.readTimeoutMillis(), client.writeTimeoutMillis());

  boolean calledNoMoreExchanges = false;
  try {
    // 關鍵代碼2
    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);
    }
  }
}

我們在上一篇文章《Android網絡編程(九) 之 OkHttp框架的使用》中有簡單介紹了攔截器的結構以及開發者可自定義的兩種攔截器，其實就是對應上述代碼。方法開始創建了一個用於存在攔截器列表的數組，然後按順序將所有攔截器添加到數組中，接着利用該數組創一個RealInterceptorChain對象，再對其調用proceed方法。

RealInterceptorChain.java

@Override public Response proceed(Request request) throws IOException {
  return proceed(request, transmitter, exchange);
}

public Response proceed(Request request, Transmitter transmitter, @Nullable Exchange exchange) throws IOException {
  if (index >= interceptors.size()) throw new AssertionError();

  calls++;

  // ……

  // Call the next interceptor in the chain.
  RealInterceptorChain next = new RealInterceptorChain(interceptors, transmitter, exchange,
      index + 1, request, call, connectTimeout, readTimeout, writeTimeout);
  Interceptor interceptor = interceptors.get(index);
  Response response = interceptor.intercept(next);

  // ……

  return response;
}

上述代碼可見，proceed是由多個入口進行調用，而每次調用後index都會+1，其實這就是逐一對interceptors數組內的攔截器進行獲取和執行其intercept方法。

3.6.1 重定向攔截器RetryAndFollowUpInterceptor

重定向攔截器的主要作用是負責請求的重定向操作以及請求失敗後像路由錯誤、IO異常等的失敗的重試。

RetryAndFollowUpInterceptor.java

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

  int followUpCount = 0;
  Response priorResponse = null;
  // 關鍵代碼1：開啓一個循環，因爲重定向可能不止一次
  while (true) {
    // 關鍵代碼2：連接準備，如判斷是否相同連接、是否釋放連接等
    transmitter.prepareToConnect(request);

    if (transmitter.isCanceled()) {
      throw new IOException("Canceled");
    }

    Response response;
    boolean success = false;
    try {
      // 關鍵代碼3：觸發下一個攔截器
      response = realChain.proceed(request, transmitter, null);
      success = true;
    } catch (RouteException e) {
      // ……
    } catch (IOException e) {
      // ……
    } finally {
      // The network call threw an exception. Release any resources.
      if (!success) {
        transmitter.exchangeDoneDueToException();
      }
    }

    // Attach the prior response if it exists. Such responses never have a body.
    if (priorResponse != null) {
      response = response.newBuilder()
          .priorResponse(priorResponse.newBuilder()
                  .body(null)
                  .build())
          .build();
    }

    Exchange exchange = Internal.instance.exchange(response);
    Route route = exchange != null ? exchange.connection().route() : null;
    // 關鍵代碼4：重定向處理
    Request followUp = followUpRequest(response, route);

    if (followUp == null) {
      if (exchange != null && exchange.isDuplex()) {
        transmitter.timeoutEarlyExit();
      }
      return response;
    }

    RequestBody followUpBody = followUp.body();
    if (followUpBody != null && followUpBody.isOneShot()) {
      return response;
    }

    closeQuietly(response.body());
    if (transmitter.hasExchange()) {
      exchange.detachWithViolence();
    }

    // 關鍵代碼5：重定向次數不能大於20次
    if (++followUpCount > MAX_FOLLOW_UPS) {
      throw new ProtocolException("Too many follow-up requests: " + followUpCount);
    }

    request = followUp;
    priorResponse = response;
  }
}

該方法內部執行過程大概是這麼幾件事：

開啓一個循環，因爲重定向可能不止一次；
執行Transmitter的prepareToConnec方法進行連接準備，如判斷是否相同連接、是否釋放連接等；
執行Chain的proceed方法觸發下一個攔截器；
執行followUpRequest方法處理重定向，方法內會做30X（300～399是重定向相關返回碼）的返回碼判斷從而進行重定向請求；
判斷重定向是否大於最大限制。

3.6.2 必要的請求頭信息、gzip處理攔截器BridgeInterceptor

該攔截器主要是添加一些必要的請求頭信息，代碼相對較容易理解。

BridgeInterceptor.java

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

3.6.3 緩存處理攔截器CacheInterceptor

該攔截器主要是對緩存進行判斷是否存在和有效，然後讀取緩存，更新緩存等。

CacheInterceptor.java

@Override public Response intercept(Chain chain) throws IOException {
//關鍵代碼1，獲得緩存對象
  Response cacheCandidate = cache != null
      ? cache.get(chain.request())
      : null;

  long now = System.currentTimeMillis();
  //關鍵代碼2，通過CacheStrategy.Factory裏緩存相關策略計算，獲得networkRequest和cacheResponse兩個對象，分別表示網絡請求對象和緩存請求對象
  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()); // The cache candidate wasn't applicable. Close it.
  }

  // If we're forbidden from using the network and the cache is insufficient, fail.
  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();
  }

// 關鍵代碼3，判斷networkRequest爲null,表示緩存有效，直接返回緩存
  if (networkRequest == null) {
    return cacheResponse.newBuilder()
        .cacheResponse(stripBody(cacheResponse))
        .build();
  }

  Response networkResponse = null;
  try {
    // 關鍵代碼4：觸發下一個攔截器
    networkResponse = chain.proceed(networkRequest);
  } finally {
    // If we're crashing on I/O or otherwise, don't leak the cache body.
    if (networkResponse == null && cacheCandidate != null) {
      closeQuietly(cacheCandidate.body());
    }
  }

  // 關鍵代碼5,判斷cacheResponse不爲null，表示網絡請求和緩存請求同時存在
  if (cacheResponse != null) {
// 如果返回碼是304，表示服務端告知跟上次請求一樣沒有發生過變化，即緩存仍可用
    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();

      // Update the cache after combining headers but before stripping the
      // Content-Encoding header (as performed by initContentStream()).
      cache.trackConditionalCacheHit();
      cache.update(cacheResponse, response);
      return response;
    } else {
      closeQuietly(cacheResponse.body());
    }
  }
  // 關鍵代碼6，緩存不可用，使用網絡請求
  Response response = networkResponse.newBuilder()
      .cacheResponse(stripBody(cacheResponse))
      .networkResponse(stripBody(networkResponse))
      .build();
  // 關鍵代碼7，緩存響應結果
  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.
      }
    }
  }

  return response;
}

該方法內部執行過程大概是這麼幾件事：

獲得緩存對象；
通過CacheStrategy.Factory的get方法計算緩存是否可用，然後獲得網絡請求對象networkRequest和緩存對象cacheResponse；
判斷networkRequest爲null,表示緩存有效，直接返回緩存；
觸發下一個攔截器；
判斷cacheResponse不爲null，表示網絡請求和緩存請求同時存在進一步判斷緩存是否可用；
如果上述中緩存不可用，便使用網絡請；
緩存響應結果。

如果有看過我前面文章《Android網絡編程(八) 之 HttpURLConnection原理分析》的朋友會發現裏頭的“緩存策略”，其實跟上述的緩存處理攔截器的邏輯基本上是一樣的，而CacheStrategy.Factory的get方法也在文章有詳細介紹過，主要是判斷緩存是否爲空、是否缺少握手、是否不允許緩存、是否已過期不新鮮等，這裏就不重複了。

3.6.4 連接攔截器ConnectInterceptor

如果前面緩存攔截器中，緩存無效，則會觸發到連接攔截器。

ConnectInterceptor.java

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

  // We need the network to satisfy this request. Possibly for validating a conditional GET.
  boolean doExtensiveHealthChecks = !request.method().equals("GET");
// 關鍵代碼1，執行連接
  Exchange exchange = transmitter.newExchange(chain, doExtensiveHealthChecks);

  // 關鍵代碼2：觸發下一個攔截器
  return realChain.proceed(request, transmitter, exchange);
}

Transmitter.java

Exchange newExchange(Interceptor.Chain chain, boolean doExtensiveHealthChecks) {
  // ……
// 關鍵代碼
  ExchangeCodec codec = exchangeFinder.find(client, chain, doExtensiveHealthChecks);
  Exchange result = new Exchange(this, call, eventListener, exchangeFinder, codec);

  synchronized (connectionPool) {
    this.exchange = result;
    this.exchangeRequestDone = false;
    this.exchangeResponseDone = false;
    return result;
  }
}

ExchangeFinder.java

public ExchangeCodec find(
    OkHttpClient client, Interceptor.Chain chain, boolean doExtensiveHealthChecks) {
  int connectTimeout = chain.connectTimeoutMillis();
  int readTimeout = chain.readTimeoutMillis();
  int writeTimeout = chain.writeTimeoutMillis();
  int pingIntervalMillis = client.pingIntervalMillis();
  boolean connectionRetryEnabled = client.retryOnConnectionFailure();

  try {
    // 關鍵代碼
    RealConnection resultConnection = findHealthyConnection(connectTimeout, readTimeout,
        writeTimeout, pingIntervalMillis, connectionRetryEnabled, doExtensiveHealthChecks);
    return resultConnection.newCodec(client, chain);
  } catch (RouteException e) {
    trackFailure();
    throw e;
  } catch (IOException e) {
    trackFailure();
    throw new RouteException(e);
  }
}

上述幾處代碼中，首先在連接攔截器中，通過Transmitter的newExchange方法，然後再是ExchangeFinder中的finHealthyConnection方法來尋找一個健康的連接。到這裏又會發現，這裏的finHealthyConnection方法，跟前面文章《Android網絡編程(八) 之 HttpURLConnection原理分析》裏頭的“網絡請求”中的finHealthyConnection方法是一樣的，如果繼續往方法內部看下去，就是關於：創建與服務端建立Socket連接、發起與服務端的TCP連接、服務端建立TCP連接、TLS握手等的邏輯處理，這裏就不重複了。

3.6.5 訪問服務器攔截器CallServerInterceptor

該攔截器是攔截器列表中，最後執選擇攔截器，它用於向服務器發起網絡請求。

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

  long sentRequestMillis = System.currentTimeMillis();
  // 關鍵代碼1，寫入請求頭信息
  exchange.writeRequestHeaders(request);

  boolean responseHeadersStarted = false;
  Response.Builder responseBuilder = null;
  if (HttpMethod.permitsRequestBody(request.method()) && request.body() != null) {
    // 如果請求有"Expect: 100-continue"的頭信息，那麼在發送請求正文前要先等待一個"HTTP/1.1 100 Continue" 的響應。如果沒有獲取該響應，就不再發送請求體並獲取例如4xx響應
    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));
        // 關鍵代碼2，寫入請求主體信息
        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();
  }

  // 關鍵代碼3，結束請求
  if (request.body() == null || !request.body().isDuplex()) {
    exchange.finishRequest();
  }

  if (!responseHeadersStarted) {
    exchange.responseHeadersStart();
  }

  if (responseBuilder == null) {
    responseBuilder = exchange.readResponseHeaders(false);
  }

  // 關鍵代碼4，獲得響應頭信息
  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 response
    response = 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 {
    // 關鍵代碼5，獲得響應主體信息
    response = response.newBuilder()
        .body(exchange.openResponseBody(response))
        .build();
  }

  // 關鍵代碼6，關閉連接
  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;
}

該方法內部忽略100和101的返回碼邏輯，過程大概是這麼幾件事：

寫入請求頭信息；
寫入請求主體信息；
結束請求；
獲得響應頭信息；
獲得響應主體信息；
關閉連接。

3 原理總結

至此，關於OkHttp3框架就介紹完畢，雖然過程中省略了大理的細節，但整體過程原理還是通過源碼瞭解很多。那我們現在用簡短的話來總結一下原理：

第1、創建 OkHttpClient 對象，用構造器模式初始化了一些配置信息：任務分發器Dispatcher（其內部包含無核心無上限適用於大量的耗時短的60S自動回收的線程池用於執行請求任務，和三個請求隊列：異步準備、異步進行、同步進行）、支持協議（HTTP_2, HTTP_1_1）、連接池ConnectionPool （其內部包含一個管理閒置泄漏、維護連接的線程池）、連接/讀/寫超時時長等信息。

第2、創建Request請求對象，傳入url、get/post、body等信息。

第3、通過 OkHttpClient 傳入Request對象創建出一個 Call對象，創建過程還創建了一個Transmitter發射器（用於判斷是否有可以重用的連接或者對沒用的連接需釋放）。

第4、若是異步請求，調用RealCall#enqueue方法，傳入一個Callback

4.1一個 Call 只能執行一次，否則會拋異常。

4.2創建了一個 AsyncCall 並將Callback傳入，接着再交給任務分發器 Dispatcher.enqueue方法進一步處理。

方法內先將任務加入到準備運行異步隊列中。

接着對遍歷隊列，並判斷正在運行的請求隊列是否 >= 最大請求數（默認64）和判斷此請求所屬主機的正在執行任務 >= 最大值（默認5），如果不滿足便將本身任務從準備隊列移除並添加到正在運行的隊列。

然後遍歷剛纔添加到正在運行的隊列對其調用executeOn方法傳入Dispatcher中的線程池進行執行任務。

最後會調用 getResponseWithInterceptorChain方法獲得響應內容，最終無論成功與否將任務從正在運行異步隊列中移除。

第5、若是同步請求，調用RealCall#execute方法，過程跟異步類似

5.1一個 Call 只能執行一次，否則會拋異常。

5.2將任務自身添加到正在運行的同步請求隊列。

5.3仍然是調用了getResponseWithInterceptorChain方法來獲得請求結果，並在最後無論成功與否將任務從正在運行同步隊列中移除。

第6、RealCall#getResponseWithInterceptorChain是重要內容

1. 創建一個數組
2. 添加ApplicationInterceptor應用攔截器（請求開始之前最早被調用）
3. 創建一個RetryAndFollowUpInterceptor攔截器（用於請求的重定向操作以及請求失敗後像路由錯誤、IO異常等的失敗的重試）
4. 創建一個BridgeIntercepto攔截器並添加（用於添加一些必要的請求頭信息、gzip處理等）
5. 創建一個CacheInterceptor攔截器並添加（用於是對緩存進行判斷是否存在和有效，然後讀取緩存，更新緩存等）
6. 創建一個ConnectInterceptor攔截器並添加（若前面緩存無效，則創建與服務端建立Socket連接、發起與服務端TCP連接、服務端建立TCP連接、TLS握手等邏輯處理）
7. 添加NetworkInterceptor網絡攔截器（組裝完成請求之後，真正發起請求之前被調用）
8. 創建一個CallServerInterceptor攔截器並添加（用於向服務器發起真正的網絡請求）
9. 通過RealInterceptorChain#proceed(Request)來執行整個攔截器數組的第一個攔截器，然後每一個攔截器處理完畢後再次調用此方法進行下一攔截器的執行。

Android網絡編程(十) 之 OkHttp3原理分析

1 使用回顧

2 原理分析

2.1 創建OkHttpClient對象

2.1.1 Dispatcher任務分發器

2.1.2 ConnectionPool連接池

2.2創建一個Request請求對象

3.3創建Call對象

3.3.1 Transmitter發射器

3.4 發起異步請求

任務調度器Dispatcher#enqueue方法

findExistingCallWithHost方法查找同一主機的任務

promoteAndExecute方法分配任務並執行

executeOn方法執行任務

3.5發起同步請求

3.6 通過getResponseWithInterceptorChain方法認識攔截器

3.6.1 重定向攔截器RetryAndFollowUpInterceptor

3.6.2 必要的請求頭信息、gzip處理攔截器BridgeInterceptor

3.6.3 緩存處理攔截器CacheInterceptor

3.6.4 連接攔截器ConnectInterceptor

3.6.5 訪問服務器攔截器CallServerInterceptor

3 原理總結

linux安裝cuda和cudnn

模擬手機設備：使用 Playwright 實現移動端自動化測試

Mellanox網卡開啓SR-IOV

測試人員都是畫畫大神，讓我看看誰還不會用代碼圖？

Object.values()對象遍歷

我拍了拍Redis，被移出了羣聊···

網絡現代化通向雲原生應用的高速公路

面試官：說說你對序列化的理解

我宣佈，這是我找到的史上AI最全論文體系！

創建型設計模式之三種工廠模式區別

創建型設計模式之簡化版和傳統版的建造者模式

創建型設計模式之深拷貝的原型模式

創建型設計模式之正確使用單例模式

Android網絡編程(十) 之 OkHttp3原理分析

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結