OkHttp之Interceptor

先看RealCall

发送一个请求，我们会先创建一个request，然后使用okHttpClient.newCall(request)，创建一个call进行网络请求，这个call，就是RealCall

 

RealCall中有一个重要的方法：execute()，同步执行网络请求，这个方法用request请求网络，返回response

 

红色方框内就是核心方法，组成拦截链，把这个请求通过拦截链处理之后，才会真正的去请求网络，获取response。

这个方法里添加了一系列的拦截器，看第一个红框，首先是把Application Interceptor添加进去了，然后依次添加了RetryAndrFollowUpInterceptor，BridgeInterceptor，CacheInterceptor，ConnectInterceptor，之后又在第二个红框的位置添加了networkInterceptor，最终的拦截器是CallServerInterceptor，记住，这个顺序对后面是有影响的！

 

先了解一下Interceptor

看一下OkHttp官网上的一张图

这张图看起来有点烦人，专治各种颈椎病。

从这张图上，我们看到拦截器分两种，一种是Application Interceptors，一种是Network Interceptors，有什么区别呢？先看一下官网怎么说的

归根结底，这两种拦截器是因为位置不一样导致他们有很大的区别的，我们从拦截器列表中看到，Application Interceptors是放在最外层的拦截器，它最先拦截到request，但是response是最后才拦截到的，也就是说，如果下面的retry拦截器进行了重连的操作，Application Interceptors是不知道的，而Network Interceptors相反，最先拦截到resopnse，直到要请求网络的时候，才拦截到request，所有的真正的网络请求，Network Interceptors都可以拦截到。我们看一下灵魂画手画的流程图：

RealCall中的execute()调用了getResponseWithInterceptorChain()，而这个方法在添加了一系列的拦截器之后实例化了一个RealInterceptorChain，并调用了chain.proceed()方法。我们看，上图，Chain持有拦截器列表，并持有一个interceptor，在proceed()方法中，interceptor拦截了request，然后实例化了一个持有下一个拦截器的chain，并调用这个chain的proceed。那么，按照顺序，应该是Application Interceptor 首先拦截了request，然后在持有retry拦截器的chain中调用proceed()方法，retry拦截器拦截request，按照顺序往下走，在network Interceptor 拦截request之后，最终callserver  interceptor去请求了网络。

 

当网络返回response之后，正好反过来，CallServerInterceptor处理之后，先由network interceptor拦截，然后其他的拦截，最后才是Application Interceptor拦截。

 

RealInterceptorChain中的proceed()方法会实例化下一个拦截器的chain。并调用当前拦截器进行拦截操作。

 

 

简单说一个拦截器的使用场景，RetryAndrFollowUpInterceptor会拦截到网络请求的结果和异常，如果有异常，这个拦截器会从request重新请求。这时候，在RetryAndrFollowUpInterceptor之上的Application Interceptor是不会知道retry做了什么，发生了什么，直到retry拦截器把response反馈给Application Interceptor。因为retry拦截器里有个while(true)死循环！！！