- 本文章所使用的 OkHttp 源码版本:3.12.10
源码解析
- 老套路,还是从 OkHttp 用法开始入手这块的源码



- 这个方法看起来有点可疑,让我们接着看是不是这个方法


- 看到这里我们基本可以断定这里就是 OkHttp 拦截器整个流程的源码了,接下来让我们看看这里面添加了哪些拦截器





-
到了这里,我们大致对这几个拦截器有了基本的认识,那么问题来了,为什么要有这么多拦截器?写这些拦截器的主要作用是什么?这些拦截器的执行流程到底是什么样的?
-
首先 OkHttp 整个流程是由五个关键的拦截器完成的,这五个拦截器的职责明确,从一些拦截器的名称大概就可以猜出来,例如 CacheInterceptor,从这个名字我们基本可以猜出来它是负责处理请求缓存的,一套完整的网络请求流程很复杂,需要执行几万甚至几十万行代码,如果都写在一个类里面可想而知是一件多么恐怖的事情,而拦截器的作用是将这些代码根据职责进行分类。
-
至于拦截器的执行流程,我们可以看一下这段代码



- 我们可以看到,在添加完一些关键的拦截器之后,最终传入到了一个拦截链中,最后调用了执行的方法。接下来让我们看看这个方法里面做了什么操作


- 接下来让我们重点分析一下这三句源码的作用

- 这里有一个有趣的现象,一个类在方法体中 new 了自己,这个稍微有点难理解,但其实跟递归差不多


- 我们可以看到,拦截链会根据索引获取指定位置的拦截器,并且每 new 一个拦截链对象索引值都会 + 1

-
最后将拦截链对象传递给拦截器。
-
等下,你刚刚不是说 proceed 方法会递归?递归在哪里呢?

-
RealInterceptorChain.proceed() -> Interceptor.intercept() -> RealInterceptorChain.proceed() -> Interceptor.intercept() -> 以此类推
-
等下,你不是说有五个拦截器,怎么我只看到了两个拦截器在调用?

-
嗯,然后呢?还有一个呢?去哪里了?
-
先不要着急,让我们检查一下少了哪个拦截器没调用 proceed 方法

-
没错,最后一个拦截器没调用 proceed 方法,那到底是为什么呢?
-
因为这就是拦截器在调拦截器的游戏,假设总共有五个拦截器,第一个拦截器调用了第二个拦截器,第二个拦截器调用了第三个拦截器,第三个拦截器调用了第四个拦截器,第四个拦截器调用了第五个拦截器,那么问题来了,第五个拦截器要调用谁?
-
没错,游戏结束了,没有再继续往下传递了,因为所有的拦截器都已经遍历完了

-
Request 对象经过拦截链的层层传递,直到遍历完所有的拦截器,也就意味着本次网络请求完成了,最终返回 Response 对象
-
至此,拦截器大致的执行流程到这里就结束了,让我们简单总结一下
源码总结
- OkHttp 整个请求流程是由一条拦截链完成,拦截链会用递归的方式来遍历整个拦截器列表,直到最后一个拦截器才停止递归,等所有的拦截器遍历完了网络请求也就结束了,然后由拦截链返回最终的请求结果。
网友评论