前言

OkHttp系列文章
OkHttp系列文章（一） – Java网络编程基础
OkHttp系列文章（二） – Http与Https
OkHttp系列文章（三） – OkHttp
OkHttp系列文章（四） – OkHttp拦截器原理
OkHttp系列文章（五） – OkHttp的5个拦截器作用
OkHttp系列文章（六） – OkHttp的5个拦截器图解分析
OkHttp系列文章（七） – 文件更新下载

1. OkHttp拦截器图解分析

OkHttp5个拦截器的分析.png

分析上图可知：

相关知识：

1>：首先从最上边发送Request请求，经过5个拦截器，一直发到最下边，然后从最下边返回响应 Response，一直到最上边；
2>：中间5个拦截器只做自己相关的事情；

1>：对于RetryAndFollowUpInterceptor重试拦截器：

a>：Retry重试机制应用场景1 —— 返回307：

在Retry拦截器返回的Response数据，如果是307（重定向），就不要再给上边发送了，而是在Retry拦截器中把 Location解析出来，拿到新的连接之后，就封装成一个新的请求，然后重新再往下边发送 Request请求，再走一遍流程，再一次返回到 Retry拦截器时候，判断返回的Response是否是307，如果没有307了，就把数据给客户端返回回去，让客户端显示；

b>：Retry重试机制应用场景2 —— 抛异常：

比如在向下边发送 Request请求时，在任何一个拦截器里边发生异常，这个时候在 Retry拦截器中try…cache…，判断如果这个异常不是致命的异常，比如只是 socket连接超时，那么就不要抛异常给 Retry上边的客户端，让其再执行一遍所有拦截器流程，如果是致命的异常，就抛给上边，让其执行异常的方法，就是联网请求的 onFailure()方法；

2>：对于BridgeInterceptor基础拦截器：

BridgeInterceptor拦截器就是添加一些通用的头部信息，比如Connection（保持连接）、支持zip压缩，如果返回的数据是 InputStream，就需要解压数据，就需要用GZipInputStream去读数据，否则全是乱码；

3>：对于CacheInterceptor缓存拦截器：

从最上边开始发起请求，到 CacheInterceptor时候，发现有缓存，就不往下边的拦截器走了，直接又返回 Response到客户端并显示数据；如果没有缓存，就还会往下边的拦截器去跑，这个时候就需要给 CacheInterceptor添加一些字段，给头部添加一个 If – Modified – Since，然后继续向下边拦截器执行，当返回到 CacheInterceptor时，对数据做一次缓存，最后把 Response返回给 客户端；当下一次再执行到 CacheInterceptor时候发现有缓存，就不会往下边走了，直接读缓存，然后返回数据上去给客户端就可以；

4>：对于ConnectInterceptor连接拦截器：

从最上边开始发起请求，找可用的连接，如果有，就不需要建立新的socket连接，直接从 ConnectInterceptor到CallServerInterceptor读写数据，然后再把结果返回给最上边的客户端；
如果没有新的连接，就与 Server建立新的连接，然后继续从 ConnectInterceptor到CallServerInterceptor读写数据，然后再把结果返回给最上边的客户端；