OkHttp相关问题全解析

.build()

//同步任务开启新线程执行

Thread {

//发起网络请求

val response = client.newCall(request).execute()

if (!response.isSuccessful) throw IOException(“Unexpected code $response”)

Log.d(“okhttp_test”, “response: ${response.body?.string()}”)

}.start()

所以核心的代码逻辑是通过OkHttpClient的newCall方法创建了一个Call对象，并调用其execute方法；Call代表一个网络请求的接口，实现类只有一个RealCall。execute表示同步发起网络请求，与之对应还有一个enqueue方法，表示发起一个异步请求，因此同时需要传入callback。

我们来看RealCall的execute方法：

RealCall

override fun execute(): Response {

…

//开始计时超时、发请求开始回调

transmitter.timeoutEnter()

transmitter.callStart()

try {

client.dispatcher.executed(this)//第1步

return getResponseWithInterceptorChain()//第2步

} finally {

client.dispatcher.finished(this)//第3步

}

}

把大象装冰箱，统共也只需要三步。

第一步

调用Dispatcher的execute方法，那Dispatcher是什么呢？从名字来看它是一个调度器，调度什么呢？就是所有网络请求，也就是RealCall对象。网络请求支持同步执行和异步执行，异步执行就需要线程池、并发阈值这些东西，如果超过阈值需要将超过的部分存储起来，这样一分析Dispatcher的功能就可以总结如下：

• 记录同步任务、异步任务及等待执行的异步任务。

• 线程池管理异步任务。

• 发起/取消网络请求API：execute、enqueue、cancel。

OkHttp设置了默认的最大并发请求量 maxRequests = 64 和单个host支持的最大并发量 maxRequestsPerHost = 5。

同时用三个双端队列存储这些请求：

Dispatcher

//异步任务等待队列

private val readyAsyncCalls = ArrayDeque()

//异步任务队列

private val runningAsyncCalls = ArrayDeque()

//同步任务队列

private val runningSyncCalls = ArrayDeque()

为什么要使用双端队列？很简单因为网络请求执行顺序跟排队一样，讲究先来后到，新来的请求放队尾，执行请求从对头部取。

说到这LinkedList表示不服，我们知道LinkedList同样也实现了Deque接口，内部是用链表实现的双端队列，那为什么不用LinkedList呢？

实际上这与readyAsyncCalls向runningAsyncCalls转换有关，当执行完一个请求或调用enqueue方法入队新的请求时，会对readyAsyncCalls进行一次遍历，将那些符合条件的等待请求转移到runningAsyncCalls队列中并交给线程池执行。尽管二者都能完成这项任务，但是由于链表的数据结构致使元素离散的分布在内存的各个位置，CPU缓存无法带来太多的便利，另外在垃圾回收时，使用数组结构的效率要优于链表。

回到主题，上述的核心逻辑在promoteAndExecute方法中：

#Dispatcher

private fun promoteAndExecute(): Boolean {

val executableCalls = mutableListOf()

val isRunning: Boolean

synchronized(this) {

val i = readyAsyncCalls.iterator()

//遍历readyAsyncCalls

while (i.hasNext()) {

val asyncCall = i.next()

//阈值校验

if (runningAsyncCalls.size >= this.maxRequests) break // Max capacity.

if (asyncCall.callsPerHost().get() >= this.maxRequestsPerHost) continue // Host max capacity.

//符合条件 从readyAsyncCalls列表中删除

i.remove()

//per host 计数加1

asyncCall.callsPerHost().incrementAndGet()

executableCalls.add(asyncCall)

//移入runningAsyncCalls列表

runningAsyncCalls.add(asyncCall)

}

isRunning = runningCallsCount() > 0

}

for (i in 0 until executableCalls.size) {

val asyncCall = executableCalls[i]

//提交任务到线程池

asyncCall.executeOn(executorService)

}

return isRunning

}

这个方法在enqueue和finish方法中都会调用，即当有新的请求入队和当前请求完成后，需要重新提交一遍任务到线程池。

讲了半天线程池，那OkHttp内部到底用的什么线程池呢？

#Dispatcher

@get:JvmName(“executorService”) val executorService: ExecutorService

get() {

if (executorServiceOrNull == null) {

executorServiceOrNull = ThreadPoolExecutor(0, Int.MAX_VALUE, 60, TimeUnit.SECONDS,

SynchronousQueue(), threadFactory(“OkHttp Dispatcher”, false))

}

return executorServiceOrNull!!

}

这不是一个newCachedThreadPool吗？没错，除了最后一个threadFactory参数之外与newCachedThreadPool一毛一样，只不过是设置了线程名字而已，用于排查问题。

阻塞队列用的SynchronousQueue，它的特点是不存储数据，当添加一个元素时，必须等待一个消费线程取出它，否则一直阻塞，如果当前有空闲线程则直接在这个空闲线程执行，如果没有则新启动一个线程执行任务。通常用于需要快速响应任务的场景，在网络请求要求低延迟的大背景下比较合适，详见旧文 Java线程池工作原理浅析。

继续回到主线，第二步比较复杂我们先跳过，来看第三步。

第三步

调用Dispatcher的finished方法

//异步任务执行结束

internal fun finished(call: AsyncCall) {

call.callsPerHost().decrementAndGet()

finished(runningAsyncCalls, call)

}

//同步任务执行结束

internal fun finished(call: RealCall) {

finished(runningSyncCalls, call)

}

//同步异步任务 统一汇总到这里

private fun finished(calls: Deque, call: T) {

val idleCallback: Runnable?

synchronized(this) {

//将完成的任务从队列中删除

if (!calls.remove(call)) throw AssertionError(“Call wasn’t in-flight!”)

idleCallback = this.idleCallback

}

//这个方法在第一步中已经分析，用于将等待队列中的请求移入异步队列，并交由线程池执行。

val isRunning = promoteAndExecute()

//如果没有请求需要执行，回调闲置callback

if (!isRunning && idleCallback != null) {

idleCallback.run()

}

}

第二步

现在我们回过头来看最复杂的第二步，调用getResponseWithInterceptorChain方法，这也是整个OkHttp实现责任链模式的核心。

#RealCall

fun getResponseWithInterceptorChain(): Response {

//创建拦截器数组

val interceptors = mutableListOf()

//添加应用拦截器

interceptors += client.interceptors

//添加重试和重定向拦截器

interceptors += RetryAndFollowUpInterceptor(client)

//添加桥接拦截器

interceptors += BridgeInterceptor(client.cookieJar)

//添加缓存拦截器

interceptors += CacheInterceptor(client.cache)

//添加连接拦截器

interceptors += ConnectInterceptor

if (!forWebSocket) {

//添加网络拦截器

interceptors += client.networkInterceptors

}

//添加请求拦截器

interceptors += CallServerInterceptor(forWebSocket)

//创建责任链

val chain = RealInterceptorChain(interceptors, transmitter, null, 0, originalRequest, this,

client.connectTimeoutMillis, client.readTimeoutMillis, client.writeTimeoutMillis)

…

try {

//启动责任链

val response = chain.proceed(originalRequest)

…

return response

} catch (e: IOException) {

…

}

}

我们先不关心每个拦截器具体做了什么，主流程最终走到chain.proceed(originalRequest)。我们看一下这个procceed方法：

RealInterceptorChain

override fun proceed(request: Request): Response {

return proceed(request, transmitter, exchange)

}

@Throws(IOException::class)

fun proceed(request: Request, transmitter: Transmitter, exchange: Exchange?): Response {

if (index >= interceptors.size) throw AssertionError()

// 统计当前拦截器调用proceed方法的次数

calls++

// exchage是对请求流的封装，在执行ConnectInterceptor前为空，连接和流已经建立但此时此连接不再支持当前url

// 说明之前的网络拦截器对url或端口进行了修改，这是不允许的!!

check(this.exchange == null || this.exchange.connection()!!.supportsUrl(request.url)) {

“network interceptor ${interceptors[index - 1]} must retain the same host and port”

}

// 这里是对拦截器调用proceed方法的限制，在ConnectInterceptor及其之后的拦截器最多只能调用一次proceed!!

check(this.exchange == null || calls <= 1) {

“network interceptor ${interceptors[index - 1]} must call proceed() exactly once”

}

// 创建下一层责任链 注意index + 1

val next = RealInterceptorChain(interceptors, transmitter, exchange,

index + 1, request, call, connectTimeout, readTimeout, writeTimeout)

//取出下标为index的拦截器，并调用其intercept方法，将新建的链传入。

val interceptor = interceptors[index]

val response = interceptor.intercept(next)

// 保证在ConnectInterceptor及其之后的拦截器至少调用一次proceed!!

check(exchange == null || index + 1 >= interceptors.size || next.calls == 1) {

“network interceptor $interceptor must call proceed() exactly once”

}

return response

}

代码中的注释已经写得比较清楚了，总结起来就是创建下一级责任链，然后取出当前拦截器，调用其intercept方法并传入创建的责任链。++为保证责任链能依次进行下去，必须保证除最后一个拦截器（CallServerInterceptor）外，其他所有拦截器intercept方法内部必须调用一次chain.proceed()方法++，如此一来整个责任链就运行起来了。

比如ConnectInterceptor源码中：

ConnectInterceptor 这里使用单例

object ConnectInterceptor : Interceptor {

@Throws(IOException::class)

override fun intercept(chain: Interceptor.Chain): Response {

val realChain = chain as RealInterceptorChain

val request = realChain.request()

val transmitter = realChain.transmitter()

val doExtensiveHealthChecks = request.method != “GET”

//创建连接和流

val exchange = transmitter.newExchange(chain, doExtensiveHealthChecks)

//执行下一级责任链

return realChain.proceed(request, transmitter, exchange)

}

}

除此之外在责任链不同节点对于proceed的调用次数有不同的限制，ConnectInterceptor拦截器及其之后的拦截器能且只能调用一次，因为网络握手、连接、发送请求的工作发生在这些拦截器内，表示正式发出了一次网络请求；而在这之前的拦截器可以执行多次proceed，比如错误重试。

经过责任链一级一级的递推下去，最终会执行到CallServerInterceptor的intercept方法，此方法会将网络响应的结果封装成一个Response对象并return。之后沿着责任链一级一级的回溯，最终就回到getResponseWithInterceptorChain方法的返回。

拦截器分类

现在我们需要先大致总结一下责任链的各个节点拦截器的作用：

| 拦截器 | 作用 |

| — | — |

| 应用拦截器 | 拿到的是原始请求，可以添加一些自定义header、通用参数、参数加密、网关接入等等。 |

| RetryAndFollowUpInterceptor | 处理错误重试和重定向 |

| BridgeInterceptor | 应用层和网络层的桥接拦截器，主要工作是为请求添加cookie、添加固定的header，比如Host、Content-Length、Content-Type、User-Agent等等，然后保存响应结果的cookie，如果响应使用gzip压缩过，则还需要进行解压。 |

| CacheInterceptor | 缓存拦截器，如果命中缓存则不会发起网络请求。 |

| ConnectInterceptor | 连接拦截器，内部会维护一个连接池，负责连接复用、创建连接（三次握手等等）、释放连接以及创建连接上的socket流。 |

| networkInterceptors（网络拦截器） | 用户自定义拦截器，通常用于监控网络层的数据传输。 |

| CallServerInterceptor | 请求拦截器，在前置准备工作完成后，真正发起了网络请求。 |

至此，OkHttp的核心执行流程就结束了，是不是有种豁然开朗的感觉？现在我们终于可以回答开篇的问题：

addInterceptor与addNetworkInterceptor的区别

---

二者通常的叫法为应用拦截器和网络拦截器，从整个责任链路来看，应用拦截器是最先执行的拦截器，也就是用户自己设置request属性后的原始请求，而网络拦截器位于ConnectInterceptor和CallServerInterceptor之间，此时网络链路已经准备好，只等待发送请求数据。

1. 首先，应用拦截器在RetryAndFollowUpInterceptor和CacheInterceptor之前，所以一旦发生错误重试或者网络重定向，网络拦截器可能执行多次，因为相当于进行了二次请求，但是应用拦截器永远只会触发一次。另外如果在CacheInterceptor中命中了缓存就不需要走网络请求了，因此会存在短路网络拦截器的情况。

2. 其次，如上文提到除了CallServerInterceptor，每个拦截器都应该至少调用一次realChain.proceed方法。实际上在应用拦截器这层可以多次调用proceed方法（本地异常重试）或者不调用proceed方法（中断），但是网络拦截器这层连接已经准备好，可且仅可调用一次proceed方法。

3. 最后，从使用场景看，应用拦截器因为只会调用一次，通常用于统计客户端的网络请求发起情况；而网络拦截器一次调用代表了一定会发起一次网络通信，因此通常可用于统计网络链路上传输的数据。

网络缓存机制CacheInterceptor

---

这里的缓存是指基于Http网络协议的数据缓存策略，侧重点在客户端缓存，所以我们要先来复习一下Http协议如何根据请求和响应头来标识缓存的可用性。

提到缓存，就必须要聊聊缓存的有效性、有效期。

HTTP缓存原理

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。**

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

[外链图片转存中…(img-ugHahfyg-1715713650750)]

[外链图片转存中…(img-S0jonRB6-1715713650752)]

[外链图片转存中…(img-8y5D7FWs-1715713650753)]

[外链图片转存中…(img-Wnk3Pzqb-1715713650754)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！