OkHttp原理解析（1）

基于OkHttp 3.10.0版本，最新OkHttp为：4.0.1逻辑与3版本并没有太大变化，但是改为kotlin实现。

OkHttp介绍

OkHttp是当下Android使用最频繁的网络请求框架，由Square公司开源。Google在Android4.4以后开始将源码中的HttpURLConnection底层实现替换为OKHttp，同时现在流行的Retrofit框架底层同样是使用OKHttp的。

优点:

支持Http1、Http2、Quic以及WebSocket
连接池复用底层TCP(Socket)，减少请求延时
无缝的支持GZIP减少数据流量
缓存响应数据减少重复的网络请求
请求失败自动重试主机的其他ip，自动重定向

使用流程

在使用OkHttp发起一次请求时，对于使用者最少存在 OkHttpClient 、 Request 与 Call 三个角色。其中OkHttpClient 和 Request 的创建可以使用它为我们提供的 Builder （建造者模式）。而 Call 则是把 Request 交给 OkHttpClient 之后返回的一个已准备好执行的请求。
建造者模式：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。实例化OKHttpClient和Request的时候，因为有太多的属性需要设置，而且开发者的需求组合千变万化，使用建造者模式可以让用户不需要关心这个类的内部细节，配置好后，建造者会帮助我们按部就班的初始化表示对象同时OkHttp在设计时采用的门面模式，将整个系统的复杂性给隐藏起来，将子系统接口通过一个客户端OkHttpClient统一暴露出来。
OkHttpClient 中全是一些配置，比如代理的配置、ssl证书的配置等。而 Call 本身是一个接口，我们获得的实现
为: RealCall

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.eventListener = client.eventListenerFactory().create(call);
return call;
}

Call 的 execute 代表了同步请求，而 enqueue 则代表异步请求。两者唯一区别在于一个会直接发起网络请求，而另一个使用OkHttp内置的线程池来进行。这就涉及到OkHttp的任务分发器。分发器Dispatcher ，分发器就是来调配请求任务的，内部会包含一个线程池。可以在创建 OkHttpClient 时，传递我们自己定义的线程池来创建分发器。这个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<>();

同步请求

synchronized void executed(RealCall call) {
runningSyncCalls.add(call);
}

因为同步请求不需要线程池，也不存在任何限制。所以分发器仅做一下记录。
异步请求

synchronized void enqueue(AsyncCall call) {
if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) <maxRequestsPerHost) {
                    runningAsyncCalls.add(call);
                    executorService().execute(call);
    } else {
                readyAsyncCalls.add(call);
   }
}

当正在执行的任务未超过最大限制64，同时 runningCallsForHost(call) < maxRequestsPerHost 同一Host的请求不超过5个，则会添加到正在执行队列，同时提交给线程池。否则先加入等待队列。加入线程池直接执行没啥好说的，但是如果加入等待队列后，就需要等待有空闲名额才开始执行。因此每次执行完一个请求后，都会调用分发器的 finished 方法

需要注意的是 只有异步任务才会存在限制与等待，所以在执行完了移除正在执行队列中的元素后，异步任务结束会执行 promoteCalls() 。很显然这个方法肯定会重新调配请求。

在满足条件下，会把等待队列中的任务移动到 runningAsyncCalls 并交给线程池执行。所以分发器到这里就完了。逻辑上还是非常简单的。请求流程用户是不需要直接操作任务分发器的，获得的 RealCall 中就分别提供了 execute 与 enqueue 来开始同步请求或异步请求。

异步请求的后续同时是调用 getResponseWithInterceptorChain() 来执行请求

如果该 RealCall 已经执行过了，再次执行是不允许的。异步请求会把一个 AsyncCall 提交给分发器。AsyncCall 实际上是一个 Runnable 的子类,使用线程启动一个 Runnable 时会执行 run 方法，在 AsyncCall 中被重定向到 execute 方法:

同时 AsyncCall 也是 RealCall 的普通内部类，这意味着它是持有外部类 RealCall 的引用，可以获得直接调用外部类的方法。可以看到无论是同步还是异步请求实际上真正执行请求的工作都在getResponseWithInterceptorChain() 中。这个方法就是整个OkHttp的核心：拦截器责任链。但是在介绍责任链之前，我们再来回顾一下线程池的基础知识。分发器线程池前面我们提过，分发器就是来调配请求任务的，内部会包含一个线程池。当异步请求时，会将请求任务交给线程池来执行。那分发器中默认的线程池是如何定义的呢？为什么要这么定义？

在OkHttp的分发器中的线程池定义如上，其实就和 Executors.newCachedThreadPool() 创建的线程一样。首先核心线程为0，表示线程池不会一直为我们缓存线程，线程池中所有线程都是在60s内没有工作就会被回收。而最大线程 Integer.MAX_VALUE 与等待队列 SynchronousQueue 的组合能够得到最大的吞吐量。即当需要线程池执行任务时，如果不存在空闲线程不需要等待，马上新建线程执行任务！等待队列的不同指定了线程池的不同排队机制。一般来说，等待队列 BlockingQueue 有： ArrayBlockingQueue 、 LinkedBlockingQueue 与 SynchronousQueue 。

假设向线程池提交任务时，核心线程都被占用的情况下：
ArrayBlockingQueue ：基于数组的阻塞队列，初始化需要指定固定大小。
当使用此队列时，向线程池提交任务，会首先加入到等待队列中，当等待队列满了之后，再次提交任务，尝试加入队列就会失败，这时就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。所以最终可能出现后提交的任务先执行，而先提交的任务一直在等待。

LinkedBlockingQueue ：基于链表实现的阻塞队列，初始化可以指定大小，也可以不指定。

当指定大小后，行为就和 ArrayBlockingQueu 一致。而如果未指定大小，则会使用默认的 Integer.MAX_VALUE 作
为队列大小。这时候就会出现线程池的最大线程数参数无用，因为无论如何，向线程池提交任务加入等待队列都会成功。最终意味着所有任务都是在核心线程执行。如果核心线程一直被占，那就一直等待。SynchronousQueue : 无容量的队列。使用此队列意味着希望获得最大并发量。

因为无论如何，向线程池提交任务，往队列提交任务都会失败。而失败后如果没有空闲的非核心线程，就会检查如果当前线程池中的线程数未达到最大线程，则会新建线程执行新提交的任务。完全没有任何等待，唯一制约它的就是最大线程数的个数。因此一般配合 Integer.MAX_VALUE 就实现了真正的无等待。
但是需要注意的时，我们都知道，进程的内存是存在限制的，而每一个线程都需要分配一定的内存。所以线程并不能无限个数。那么当设置最大线程数为 Integer.MAX_VALUE 时，OkHttp同时还有最大请求任务执行个数: 64的限制。这样即解决了这个问题同时也能获得最大吞吐。

拦截器责任链
OkHttp最核心的工作是在 getResponseWithInterceptorChain() 中进行，在进入这个方法分析之前，我们先来了解什么是责任链模式，因为此方法就是利用的责任链模式完成一步步的请求。
责任链顾名思义就是由一系列的负责者构成的一个链条，类似于工厂流水线。
责任链模式
为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下
一个接收者，依此类推。
那整个过程是什么样子的呢？

在责任链模式中，每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的 情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

拦截器流程

而OkHttp中的 getResponseWithInterceptorChain() 中经历的流程为

请求会被交给责任链中的一个个拦截器。默认情况下有五大拦截器：
1.  RetryAndFollowUpInterceptor
第一个接触到请求，最后接触到响应；负责判断是否需要重新发起整个请求
2.  BridgeInterceptor
补全请求，并对响应进行额外处理
3.  CacheInterceptor
请求前查询缓存，获得响应并判断是否需要缓存
4.  ConnectInterceptor
与服务器完成TCP连接
5.  CallServerInterceptor
与服务器通信；封装请求数据与解析响应数据(如：HTTP报文)

拦截器详情
一、重试及重定向拦截器
第一个拦截器: RetryAndFollowUpInterceptor ，主要就是完成两件事情：重试与重定向。
重试
请求阶段发生了 RouteException 或者 IOException会进行判断是否重新发起请求。
RouteException

IOException

两个异常都是根据 recover 方法判断是否能够进行重试，如果返回 true ，则表示允许重试。

所以首先使用者在不禁止重试的前提下，如果出现了某些异常，并且存在更多的路由线路，则会尝试换条线路进行
请求的重试。其中某些异常是在 isRecoverable 中进行判断:

1、协议异常，如果是那么直接判定不能重试;（你的请求或者服务器的响应本身就存在问题，没有按照http协议来
定义数据，再重试也没用） 2、超时异常，可能由于网络波动造成了Socket连接的超时，可以使用不同路线重试。
3、SSL证书异常/SSL验证失败异常，前者是证书验证失败，后者可能就是压根就没证书，或者证书数据不正确，
那还怎么重试？
经过了异常的判定之后，如果仍然允许进行重试，就会再检查当前有没有可用路由路线来进行连接。简单来说，比
如 DNS 对域名解析后可能会返回多个 IP，在一个IP失败后，尝试另一个IP进行重试。
重定向
如果请求结束后没有发生异常并不代表当前获得的响应就是最终需要交给用户的，还需要进一步来判断是否需要重
定向的判断。重定向的判断位于 followUpRequest 方法

整个是否需要重定向的判断内容很多，记不住，这很正常，关键在于理解他们的意思。如果此方法返回空，那就表示不需要再重定向了，直接返回响应；但是如果返回非空，那就要重新请求返回的 Request ，但是需要注意的是，我们的 followup 在拦截器中定义的最大次数为20次。
总结
本拦截器是整个责任链中的第一个，这意味着它会是首次接触到 Request 与最后接收到 Response 的角色，在这个拦截器中主要功能就是判断是否需要重试与重定向。重试的前提是出现了 RouteException 或者 IOException 。一但在后续的拦截器执行过程中出现这两个异常，就会通过 recover 方法进行判断是否进行连接重试。重定向发生在重试的判定之后，如果不满足重试的条件，还需要进一步调用 followUpRequest 根据 Response 的响应码(当然，如果直接请求失败， Response 都不存在就会抛出异常)。 followup 最大发生20次。

二、桥接拦截器
BridgeInterceptor ，连接应用程序和服务器的桥梁，我们发出的请求将会经过它的处理才能发给服务器，比如设
置请求内容长度，编码，gzip压缩，cookie等，获取响应后保存Cookie等操作。这个拦截器相对比较简单。
补全请求头:

在补全了请求头后交给下一个拦截器处理，得到响应后，主要干两件事情：
1、保存cookie，在下次请求则会读取对应的数据设置进入请求头，默认的 CookieJar 不提供实现
2、如果使用gzip返回的数据，则使用 GzipSource 包装便于解析。
总结
桥接拦截器的执行逻辑主要就是以下几点对用户构建的 Request 进行添加或者删除相关头部信息，以转化成能够真正进行网络请求的 Request 将符合网络请求规范的Request交给下一个拦截器处理，并获取 Response 如果响应体经过了GZIP压缩，那就需要解压，再构建成用户可用的 Response 并返回

三、缓存拦截器
CacheInterceptor ，在发出请求前，判断是否命中缓存。如果命中则可以不请求，直接使用缓存的响应。 (只会存
在Get请求的缓存)
步骤为:
1、从缓存中获得对应请求的响应缓存
2、创建 CacheStrategy ,创建时会判断是否能够使用缓存，在 CacheStrategy 中存在两个成员: networkRequest
与 cacheResponse 。他们的组合如下:

3、交给下一个责任链继续处理
4、后续工作，返回304则用缓存的响应；否则使用网络响应并缓存本次响应（只缓存Get请求的响应）缓存拦截器的工作说起来比较简单，但是具体的实现，需要处理的内容很多。在缓存拦截器中判断是否可以使用缓存，或是请求服务器都是通过 CacheStrategy 判断。

缓存策略
CacheStrategy 。首先需要认识几个请求头与响应头

其中 Cache-Control 可以在请求头存在，也能在响应头存在，对应的value可以设置多种组合：
1.  max-age=[秒] ：资源最大有效时间;
2.  public ：表明该资源可以被任何用户缓存，比如客户端，代理服务器等都可以缓存资源;
3.  private ：表明该资源只能被单个用户缓存，默认是private。
4.  no-store ：资源不允许被缓存
5.  no-cache ：(请求)不使用缓存
6.  immutable ：(响应)资源不会改变
7.  min-fresh=[秒] ：(请求)缓存最小新鲜度(用户认为这个缓存有效的时长)
8.  must-revalidate ：(响应)不允许使用过期缓存
9.  max-stale=[秒] ：(请求)缓存过期后多久内仍然有效
假设存在max-age=100，min-fresh=20。这代表了用户认为这个缓存的响应，从服务器创建响应 到 能够缓
存使用的时间为100-20=80s。但是如果max-stale=100。这代表了缓存有效时间80s过后，仍然允许使用
100s，可以看成缓存有效时长为180s。

详细流程
如果从缓存中获得了本次请求URL对应的 Response ，首先会从响应中获得以上数据备用。

判断缓存的命中会使用 get() 方法

方法中调用 getCandidate() 方法来完成真正的缓存判断。
1、缓存是否存在
整个方法中的第一个判断是缓存是不是存在：

if (cacheResponse == null) {
    return new CacheStrategy(request, null);
}

cacheResponse 是从缓存中找到的响应，如果为null，那就表示没有找到对应的缓存，创建的 CacheStrategy 实例对象只存在 networkRequest ，这代表了需要发起网络请求。
2、https请求的缓存
继续往下走意味着 cacheResponse 必定存在，但是它不一定能用。后续进行有效性的一系列判断

if (request.isHttps() && cacheResponse.handshake() == null) {
   return new CacheStrategy(request, null);
}

如果本次请求是HTTPS，但是缓存中没有对应的握手信息，那么缓存无效。

3、响应码以及响应头

if (!isCacheable(cacheResponse, request)) {
         return new CacheStrategy(request, null);
}

整个逻辑都在 isCacheable 中，他的内容是:

缓存响应中的响应码为 200, 203, 204, 300, 301, 404, 405, 410, 414, 501, 308 的情况下,只判断服务器是不是给了Cache-Control: no-store (资源不能被缓存)，所以如果服务器给到了这个响应头，那就和前面两个判定一致(缓存不可用)。否则继续进一步判断缓存是否可用而如果响应码是302/307(重定向)，则需要进一步判断是不是存在一些允许缓存的响应头。根据注解中的给到的文档http://tools.ietf.org/html/rfc7234#section-3中的描述，如果存在 Expires 或者 Cache-Control 的值为：
1.  max-age=[秒] ：资源最大有效时间;
2.  public ：表明该资源可以被任何用户缓存，比如客户端，代理服务器等都可以缓存资源;
3.  private ：表明该资源只能被单个用户缓存，默认是private。
同时不存在 Cache-Control: no-store ，那就可以继续进一步判断缓存是否可用。
所以综合来看判定优先级如下：
1、响应码不为 200, 203, 204, 300, 301, 404, 405, 410, 414, 501, 308，302，307 缓存不可用;
2、当响应码为302或者307时，未包含某些响应头，则缓存不可用;
3、当存在 Cache-Control: no-store 响应头则缓存不可用。
如果响应缓存可用，进一步再判断缓存有效性
4、用户的请求配置

走到这一步，OkHttp需要先对用户本次发起的 Request 进行判定，如果用户指定了 Cache-Control: no-cache (不使用缓存)的请求头或者请求头包含  If-Modified-Since 或 If-None-Match (请求验证)，那么就不允许使用缓存。

这意味着如果用户请求头中包含了这些内容，那就必须向服务器发起请求。但是需要注意的是，OkHttp并不会缓存304的响应，如果是此种情况，即用户主动要求与服务器发起请求，服务器返回的304(无响应体)，则直接把304的响应返回给用户：“既然你主动要求，我就只告知你本次请求结果”。而如果不包含这些请求头，那继续判定缓存有效性。