目录
OKHttp的优缺点
OKHttp的主流程
OKHttp核心类分析
OKHttp涉及到的设计模式
OKHttp的优缺点
优缺点是比较而言，对比目前的网络框架
| 框架名称 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| OKHttp | 1）Http高性能库，属于底层网络框架 2）内置连接池，支持连接复用 3）通过Gzip压缩响应体数据 4）支持同步阻塞和异步阻塞两种方式 | 使用时需要进一步封装 | 重量级网络交互场景 |
| Volley | 1）基于 HttpUrlConnection，是封装后的网络框架。 2）可扩展性好，可支持HttpClient、HttpUrlConnection和Okhttp | 不适合大的下载或者流式传输操作，数据方法放到byte[]数组里，消耗内存 | 适合轻量级网络交互，网络请求频繁，传输数据量小，不适合做文件(音视频)操作（上传/下载） |
| Retrofit | 1）底层基于okhttp，属于封装后的网络框架 2）封装好，效率高，简洁易用 3）支持RxJava | 1）扩展性差 2）项目中常常RxJava+Retrofit+Okhttp组合，来搭建网络框架，具有一定学习成本 | 适合大型项目，重量级网络交互场景，网络请求频繁、传输数据量大 |
关于OkHttp我们知道：
1）OkHttp基于Socket通信，它更倾向于底层，会对Http协议进行完全的封装
可以简单理解为：Okhttp通过Socket和服务器进行了TCP连接，并将需要的请求信息按照Http协议的格式封装，通过Socket连接发送到服务器，再读取服务器的响应
2）Android 4.4后，HttpURLConnection底层实现就是OkHttp，相当于官方认证
基于此，我们探究OkHttp源码才更有意义，对网络框架的底层原理才会更加了解
OKHttp的主流程
通过上图，我们了解OkHttp的核心流程，具体详细过程可以看下面的文字解读
- 通过建造者模式，构建OkHttp的客户端请求发起者OkHttpClient
- 通过构建者模式，构建Request的请求体，组装参数，header、method、Url等
- 创建Call，真正的请求在RealCall中完成，Dispatcher调度器负责管理RealCall，通过execute()或者enquene()完成同步/异步请求
- execute()后者enquene()最终会调用getResponseWithInterceptorChain()方法，从拦截器链条interceptors中获取结果
OKHttp核心类分析
从上面的分析可知，RealCall是Call的具体实现类，我们来看RealCall他的exectue()方法
override fun execute(): Response {
//判断有没有执行过，没有执行进行置位标记
check(executed.compareAndSet(false, true)) { "Already Executed" }
//请求超时开始计时
timeout.enter()
callStart()
try {
// 第一步 交给dispatcher开始请求
client.dispatcher.executed(this)
//第二步 获取请求结果
return getResponseWithInterceptorChain()
} finally {
//第三步 结束请求任务
client.dispatcher.finished(this)
}
}
关键代码已经做了注释，可以看到，整个请求核心步骤分三步完成
第一步：是dispatcher的execute方法，我们进入Dispatcher类来看下，Dispatcher从字面意思来看，就是调度器，主要负责管理网络请求线程，异步请求通过线程池ExecutorService来管理
@get:Synchronized var maxRequests = 64
set(maxRequests) {
require(maxRequests >= 1) { "max < 1: $maxRequests" }
synchronized(this) {
field = maxRequests
}
promoteAndExecute()
}
@get:Synchronized var maxRequestsPerHost = 5
set(maxRequestsPerHost) {
require(maxRequestsPerHost >= 1) { "max < 1: $maxRequestsPerHost" }
synchronized(this) {
field = maxRequestsPerHost
}
promoteAndExecute()
}
maxRequests = 64 默认最大并发请求数量是64
maxRequestPerHost = 5 默认单个Host最大并发请求量是5
继续向下看，初始化了线程池，这个后面可以单独讲
@get:Synchronized
@get:JvmName("executorService") val executorService: ExecutorService
get() {
if (executorServiceOrNull == null) {
executorServiceOrNull = ThreadPoolExecutor(0, Int.MAX_VALUE, 60, TimeUnit.SECONDS,
SynchronousQueue(), threadFactory("$okHttpName Dispatcher", false))
}
return executorServiceOrNull!!
}
线程池初始化完成后，继续向下看
private val readyAsyncCalls = ArrayDeque() private val runningAsyncCalls = ArrayDeque() private val runningSyncCalls = ArrayDeque()
通过注释可以知道
readyAsyncCalls 等待的异步任务队列
runningAsyncCalls 在运行的异步任务队列
runningSyncalls 在运行的同步任务队列
这里的ArrayDeque是双端队列，什么是双端队列？
一般队列是FIFO，即first in first out，先进先出，栈是LIFO，last in fisrt out，后进先出，而双端队列结合两种数据结构的特性，可以做到两端进，可以两端弹出，也就是可以在队列的两端进行插入和删除操作。
那么第二个问题又来了，既然是双端队列，为什么选ArrayDeque？linkedList也是大小可变的双端队列，为什么没有选择它？
这个问题就涉及到链表和数组的区别了，各有优劣，说道这里可能已经知道接下来的分析，没错，ArrayDeque底层基于数组(循环数组)实现，linkedList底层是链表实现，数组的优势占用连续内存区域、随机读取效率高，但插入和删除效率低，而链表占用非连续内存，随机读取效率低，但插入和删除效率高，这样看来，貌似不分伯仲？
实际上，在OkHttp中，网络请求也是按照先来后到的执行，后来的需要在后面排队，每次执行过网络请求时，都要遍历readyAsyncCalls，把符合条件的网络请求加入runningAsyncCalls队列中，这时，数组中数据是连续存储在内存单元的，cpu寻找时数组就会更快，而且，连续的存储方式在垃圾回收GC时，效率会优于链表，所以，应该是综合性能，最终选择ArrayDeque
OKHttp涉及到的设计模式
