老生常谈的OkHttp

最新推荐文章于 2024-04-05 12:53:35 发布

小草帽学编程

最新推荐文章于 2024-04-05 12:53:35 发布

阅读量5.1k

点赞数 4

分类专栏： Android开发——进阶文章标签： android tv java

本文链接：https://blog.csdn.net/LVEfrist/article/details/123282843

版权

Android开发——进阶专栏收录该内容

9 篇文章 1 订阅

订阅专栏

背景：

前面我们已经梳理过HTTP相关知识点了，但是作为Android开发，大多数时候并不会直接面向HTTP协议，而是面向OkHttp这个网络请求框架来做网络请求(当然了，现在可能更多的是面向Retrofit做网络开发，但Retrofit说到底只是个工具，内部还是OKHttp完成的网络请求)。这也是为啥OkHttp变成了面试必问的原因，这里我们就简单理一下OkHttp这个框架的相关知识。

一、OkHttp的组成

OkHttp框架一经面试就收到的热捧，这是因为它极大的简化了开发者完成网络开发的步骤。框架内部使用的大量的设计模式，但今天我们不说设计模式，我们先来说说它的主要组成。作为Android开发，OkHttpClient我想都不会陌生，因为我们的网络请求就得通过它来发出去。这也是整个OkHttp框架的入口。

通过源码很清晰的就能看到OkHttpClient的组成部分。其中被提及的最多的就是：分发器和拦截器两个成员。这也是我们将要说的重点。

分发器：负责管理和分发网络请求（Call）的核心
拦截器：负责网络请求的拦截、建立连接、拼包、发送/接收数据等任务

二、分发器都负责干啥

OkHttp中的分发器可以说是除了拦截器以外最关键的一个环节了。之所以有分发器的存在是因为我们一个APP会有无数的网络请求，且可能同一时间进行大量的网络请求。这就要求OkHttp能够支持大并发的网络请求需要，同时还要支持异步请求和同步请求。

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

如上源码，分发器主要有一个线程池+三个等待队列组成。至于他的工作流程我就不去贴代码一步步扣了，有兴趣的自己去跟下代码把，这里就总结下它的工作流程：

同步请求：因为同步请求是不存在任何条件限制立马执行，不需要线程池，所以分发器只将其放入同步执行队列做一下记录，等任务执行完再移除。

异步请求：异步请求相对于同步来说要复杂一丢丢。

正在执行的异步任务小于最大同时请求数（64），且同一Host请求小于最大同一Host请求数（5）则将Call加入异步正在执行队列，并交给线程池立即执行。否则将Call加入异步等待队列。

不管是异步请求还是同步请求，任务执行完后都会执行finish操作，唯一的区别是异步请求执行finish操作时会轮询异步等待队列。

前面也说了OkHttp能够达到高并发的要求，那么问题来了，他是怎么做到的呢？关键点就在分发器的线程池上：

线程池中常用的有三种队列，我们需要简单了解下：

（1）SynchronousQueue：是一个没有容量，无缓冲，不存储元素的阻塞队列，是个典型的生产者消费者模型，会直接将任务交给消费者，必须等队列中添加的元素被消费后才能继续添加新的元素。这样结合线程池的工作原理就不难明白为啥选择它来支持高并发了，由此提交到这个线程池的任务会被立即执行。

（2） LinkedBlockingQueue：是一个无界缓存等待队列。当前执行的线程数量达到corePoolSize的数量时，剩余的元素会在阻塞队列里等待，当队列满时，才会开启新的线程，立即执行新添加的任务，当线程数达到 maximumPoolSize 数量时，执行线程拒绝策略。每个线程完全独立于其他线程。

（3）ArrayBlockingQueue：是一个有界缓存等待队列，可以指定缓存队列的大小，当正在执行的线程数等于corePoolSize时，多余的元素缓存在ArrayBlockingQueue队列中等待有空闲的线程时继续执行，当ArrayBlockingQueue已满时，加入ArrayBlockingQueue失败，会开启新的线程去执行，当线程数已经达到最大的maximumPoolSizes时，再有新的元素尝试加入ArrayBlockingQueue时会执行拒绝策略。

其中LinkedBlockingQueue和ArrayBlockingQueue类似，区别就是一个无界（Integer.MAX_VALUE大小），一个有界（需要指定大小）。

三、拦截器的工作

这里我们只讲一下OkHttp内部自带的五种拦截器，因为这五种拦截器组合完成了真正的Http网络请求。自带的五大拦截器将Request按责任链模式依序向下传递，Response结果再按责任链逆序向上传递返回。也就意味着第一个执行的拦截器最先接触到Request，最后接收到Response:

重试与重定向拦截器：RetryAndFollowUpInterceptor

（1）重试

在使用者不禁用重试的前提下，当出现某些异常（如：Socket超时异常、路由异常）时，且存在更多的路由线路，则会尝试换条线路进行请求的重试。但是这里要注意有几种异常不会进行重试：

SSL证书异常（证书验证失败）
SSL验证失败异常（通常是没有证书）
协议异常（未按照Http协议定义数据）

（2）重定向

如果请求结束，也没有发生异常并不代表当前获得的响应就是最终结果，而是要根据Response响应码再次判断是否需要重定向。状态码很多，这里就不啰里吧嗦介绍了，有兴趣自己去扣一下源码

我想强调的是，重定向是有次数限制的，最大次数为20次。

桥接拦截器：BridgeInterceptor

上面在说HTTP协议的时候已经讲过它的报文了，其中的Header的关键部分都是在这个拦截器中进行补全的。如：

请求头	说明
`Content-Type`	请求体类型,如：`application/x-www-form-urlencoded`
`Content-Length`/`Transfer-Encoding`	请求体解析方式
`Host`	请求的主机站点
`Connection: Keep-Alive`	保持长连接
`Accept-Encoding: gzip`	接受响应支持gzip压缩
`Cookie`	cookie身份辨别
`User-Agent`	请求的用户信息，如:操作系统、浏览器等

在补全请求头后交给下一个拦截器处理，在得到响应结果后还会做两件事：

保存cookie，在下次请求则会读取对应的数据设置进入请求头，默认的CookieJar不提供实现
如果使用gzip返回的数据，则使用GzipSource包装便于解析。

缓存拦截器：CacheInterceptor

Http的缓存机制前面在介绍Http协议的时候我们也详细讲解过它的工作流程了，在这里我也不再啰嗦它的策略机制了，有兴趣可以翻到前面去看看。缓存拦截器的作用就是在发出请求前，判断缓存是否命中。如果命中则可以不请求，直接使用缓存的响应。但是要注意OkHttp只会缓存GET请求的响应（至于为啥，我也不知道，哈哈）。