OkHttp 是一套处理 HTTP 网络请求的依赖库，由 Square 公司设计研发并开源，目前可以在 Java 和 Kotlin 中使用。

对于 Android App 来说，OkHttp 现在几乎已经占据了所有的网络请求操作，RetroFit + OkHttp 实现网络请求似乎成了一种标配。因此它也是每一个 Android 开发工程师的必备技能，了解其内部实现原理可以更好地进行功能扩展、封装以及优化。

异步执行的队列

先从OkHttp的基本使用切入：

先是构建请求，通过 Builder() 构建初始化Dispatcher，Http协议类型protocols，Cookie压缩类型，dns等参数。

请求操作的起点从 OkHttpClient.newCall().enqueue() 方法开始。

newCall

okHttpClient.newCall 把 request 封装转成一个 RealCall

这个方法会返回一个 RealCall 类型的对象，通过它将网络请求操作添加到请求队列中。

enqueue方法将Callable对象转换成一个异步的AsyncCall的runnable对象。

AsyncCall是RealCall的内部类，并且把它交给了client的dispatch对象。

Dispatcher 是 OkHttpClient 的调度器，是一种门户模式。主要用来实现执行、取消异步请求操作。本质上是内部维护了一个线程池去执行异步操作，并且在 Dispatcher 内部根据一定的策略，保证最大并发个数、同一 host 主机允许执行请求的线程个数等。

在enqueue方法会先判断在运行的asyncCalls数量是不是已经达到最大的64个，并且还会判断当前运行的主机数（也就是网页URL主要部分，端口前面的主地址）是不是超过了最大的5个。如果都小于，则将当前的AsyncCall加入到正在执行的集合中，否则加入准备执行的集合中。加入到正在执行的集合中，就会调用线程池的执行方法。最终去了AsyncCall的execute方法

这里为什么不是run方法的原因是因为AsyncCall继承的NamedRunnable的run方法中调用了execute方法

在AsyncCall的execute方法中，就会来到最重要的一个部分，也就是拦截器的部分。而等拦截器执行完，拦截器方法返回的就是Response。

拦截器

而真正获取请求结果的方法是在 getResponseWithInterceptorChain 方法中，从名字也能看出其内部是一个拦截器的调用链，具体代码如下：

在添加上述几个拦截器之前，会调用 client.interceptors 将开发人员设置的拦截器添加到列表当中。

而如果是需要在进行连接后回传数据进行拦截的的话，也会通过调用 client.networkInterceptors。

例如自定义缓存拦截器加载在后面，也就是addNetworkInterceptor，来实现自定义缓存策略拦截器。如果是调用 client.interceptors ，则因为回传数据已经进过CacheInterceptor，所以无法生效。而调用 client.networkInterceptors 则是在接收到resp后，resp会先来到 networkInterceptors 添加的拦截器，进行缓存策略的更改，再回传给 CacheInterceptor 上层进行缓存策略判断。

RetryAndFollowUpInterceptor拦截器

内部为一个死循环，每次都会重试丢给下一级处理。

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

      /**
      部分代码省略
      **/    

  }

是否跳出循环看是否为致命异常，如果不是致命异常，例如连接超时，则进行重试。

并且在这个拦截器中，还会处理重定向307、308等。会通过获取新的头部信息，生产一个新的请求，交给下级。

RetryAndFollowUpInterceptor中followUpRequest方法处理状态码

BridgeInterceptor拦截器

主要设置一些通用的请求头，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 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拦截器

负责 HTTP 请求的缓存处理。

CacheInterceptor 主要做以下几件事情：

根据 Request 获取当前已有缓存的 Response（有可能为 null），并根据获取到的缓存 Response，创建 CacheStrategy 对象。

通过 CacheStrategy 判断当前缓存中的 Response 是否有效（比如是否过期），如果缓存 Response 可用则直接返回，否则调用 chain.proceed() 继续执行下一个拦截器，也就是发送网络请求从服务器获取远端 Response。具体如下：

如果从服务器端成功获取 Response，再判断是否将此 Response 进行缓存操作。

ConnectInterceptor拦截器

负责建立与服务器地址之间的连接，也就是 TCP 连接。

建立Socket连接连接缓存，封装HttpCodec里面封装了okio的输入输出流，就可以向服务器写数据和返回数据。

CallServerInterceptor拦截器

CallServerInterceptor 是 OkHttp 中最后一个拦截器，也是 OkHttp 中最核心的网路请求部分，其 intercept 方法如下：

如上图所示，主要分为 2 部分。蓝线以上的操作是向服务器端发送请求数据，蓝线以下代表从服务端获取相应数据并构建 Response 对象。

总结

这节课主要分析了 OkHttp 的源码实现：

OkHttp 内部是一个门户模式，所有的下发工作都是通过一个门户 Dispatcher 来进行分发。
在网络请求阶段通过责任链模式，链式的调用各个拦截器的 intercept 方法。

okHttp源码分析