.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之间,此时网络链路已经准备好,只等待发送请求数据。
-
首先,应用拦截器在RetryAndFollowUpInterceptor和CacheInterceptor之前,所以一旦发生错误重试或者网络重定向,网络拦截器可能执行多次,因为相当于进行了二次请求,但是应用拦截器永远只会触发一次。另外如果在CacheInterceptor中命中了缓存就不需要走网络请求了,因此会存在短路网络拦截器的情况。
-
其次,如上文提到除了CallServerInterceptor,每个拦截器都应该至少调用一次realChain.proceed方法。实际上在应用拦截器这层可以多次调用proceed方法(本地异常重试)或者不调用proceed方法(中断),但是网络拦截器这层连接已经准备好,可且仅可调用一次proceed方法。
-
最后,从使用场景看,应用拦截器因为只会调用一次,通常用于统计客户端的网络请求发起情况;而网络拦截器一次调用代表了一定会发起一次网络通信,因此通常可用于统计网络链路上传输的数据。
网络缓存机制CacheInterceptor
这里的缓存是指基于Http网络协议的数据缓存策略,侧重点在客户端缓存,所以我们要先来复习一下Http协议如何根据请求和响应头来标识缓存的可用性。
提到缓存,就必须要聊聊缓存的有效性、有效期。
HTTP缓存原理
写在最后
由于本文罗列的知识点是根据我自身总结出来的,并且由于本人水平有限,无法全部提及,欢迎大神们能补充~
将来我会对上面的知识点一个一个深入学习,也希望有童鞋跟我一起学习,一起进阶。
提升架构认知不是一蹴而就的,它离不开刻意学习和思考。
**这里,笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家,**梳理了多年的架构经验,筹备近1个月最新录制的,相信这份视频能给你带来不一样的启发、收获。
最近还在整理并复习一些Android基础知识点,有问题希望大家够指出,谢谢。
希望读到这的您能转发分享和关注一下我,以后还会更新技术干货,谢谢您的支持!
转发+点赞+关注,第一时间获取最新知识点
Android架构师之路很漫长,一起共勉吧!
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!
的数据缓存策略,侧重点在客户端缓存,所以我们要先来复习一下Http协议如何根据请求和响应头来标识缓存的可用性。
提到缓存,就必须要聊聊缓存的有效性、有效期。
HTTP缓存原理
写在最后
由于本文罗列的知识点是根据我自身总结出来的,并且由于本人水平有限,无法全部提及,欢迎大神们能补充~
将来我会对上面的知识点一个一个深入学习,也希望有童鞋跟我一起学习,一起进阶。
提升架构认知不是一蹴而就的,它离不开刻意学习和思考。
**这里,笔者分享一份从架构哲学的层面来剖析的视频及资料分享给大家,**梳理了多年的架构经验,筹备近1个月最新录制的,相信这份视频能给你带来不一样的启发、收获。
[外链图片转存中…(img-AXHEowt4-1715855745504)]
[外链图片转存中…(img-kuyHY0Wz-1715855745507)]
最近还在整理并复习一些Android基础知识点,有问题希望大家够指出,谢谢。
希望读到这的您能转发分享和关注一下我,以后还会更新技术干货,谢谢您的支持!
转发+点赞+关注,第一时间获取最新知识点
Android架构师之路很漫长,一起共勉吧!
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门,即可获取!