OkHttp
续
根据上一篇 核心流程 ，我们大致知道了okhttp的内部运转，但是对于网络请求的缓存、连接复用以及网络监控的功能的实现，我们是只知其然，而不知其所以然，我们只知道是负责各个功能的拦截器帮助我们完成了底层的任务，但是却不知道原理是什么。今天跟着笔者继续学习Okhttp各个拦截器的原理实现。限于篇幅，在文章中，笔者只对相关拦截器的intercept方法进行了分析，但是并没有展开，有兴趣的同学可以自己去看。
回顾
我们知道Okhttp的核心功能的实现就是一套由拦截器组成的责任链机制，而这个责任链的入口就是getResponseWithInterceptorChain方法，我们再次贴出它的源码：
@Throws(IOException::class)internal fun getResponseWithInterceptorChain(): Response {// Build a full stack of interceptors.val interceptors = mutableListOf<Interceptor>()interceptors += client.interceptorsinterceptors += RetryAndFollowUpInterceptor(client)interceptors += BridgeInterceptor(client.cookieJar)interceptors += CacheInterceptor(client.cache)interceptors += ConnectInterceptorif (!forWebSocket) {interceptors += clientworkInterceptors}interceptors += CallServerInterceptor(forWebSocket)...var calledNoMoreExchanges = falsetry {val response = chain.proceed(originalRequest)if (isCanceled()) {response.closeQuietly()throw IOException("Canceled")}return response} catch (e: IOException) {...} finally {...}}上面拦截器的添加顺序实际上就是后面它们的执行顺序。
可以看到第一个添加的是应用拦截器，这个是在我们创建request的时候添加的，这个过程一般用于添加一些自定义的header、参数、网关接入等信息。所以这边我们就简单介绍一下
大概的拦截器工作原理
我说的所谓的工作原理其实就是拦截器的intercept方法是怎么运行的，当然在最后的请求拦截器（CallServerInterceptor）会有所不同，因为不需要向下递归了，而是开始回溯。
（实际上整个拦截链再笔者看来就是一个递归的过程。）
给大家贴一个interceptor的源码，它实际上是一个接口，然后内部有一个intercept方法还有一个接口Chain。这个Chain的实现类是RealInterceptorChain.java 这个源码就不贴了，没记错上篇文章给了。
fun interface Interceptor {@Throws(IOException::class)fun intercept(chain: Chain): Responsecompanion object {inline operator fun invoke(crossinline block: (chain: Chain) -> Response): Interceptor =Interceptor { block(it) }}interface Chain {fun request(): Request@Throws(IOException::class)fun proceed(request: Request): Responsefun connection(): Connection?fun call(): Callfun connectTimeoutMillis(): Intfun withConnectTimeout(timeout: Int, unit: TimeUnit): Chainfun readTimeoutMillis(): Intfun withReadTimeout(timeout: Int, unit: TimeUnit): Chainfun writeTimeoutMillis(): Intfun withWriteTimeout(timeout: Int, unit: TimeUnit): Chain}
}
实际上在拦截器内部，我们执行intercept方法，内部的逻辑大概分为 request部分的逻辑、调用Chain的proceed方法进入下一个拦截器，然后根据回溯得到的reponse 做处理。最后再返回response。
override fun intercept(chain : inteceptor.Chain ) :Response{val request = chain.request();// Request阶段，该拦截器在Request阶段负责做的事情// 调用RealInterceptorChain.proceed()，其实是在递归调用下一个拦截器的intercept()方法response = chain.proceed(request, streamAllocation, null, null);// Response阶段，完成了该拦截器在Response阶段负责做的事情，然后返回到上一层的拦截器。return response;
}拦截器
用户自定义的拦截逻辑 - 应用拦截器
应用拦截器最先被触发，并且在一次请求中只会被触发一次。
应用拦截器的作用通常由程序员设置，我们继承Interceptor类重写它的intercept方法，当我们在构建request时将该拦截器加入，那么在后续的拦截链中就会执行 我们在内部intercept方法中写的逻辑了，这里我就不给大家示例了，想要了解的可以自行查阅。
完成重定向及重试的幕后 - RetryAndFollowUpInterceptor
如果我们在构建request时没有加入应用拦截器，那么实际上第一次执行的就是RetryAndFollowUpInterceptor了，它的作用看名称也能明白 重试与重定向，重定向是什么意思呢？我们学过计算机网络知道，当我们访问一个站点时，该站点可能不能处理，需要浏览器重新向新的站点发起请求，并且返回3** 状态码 以及在返回的数据中的location字段中放入需要重定向的url。所以当本次请求返回数据时回溯到该层时，就进行一个判断如果location的字段值不为空，那么就会进行一次重定向请求。具体的话我们来看源码：
#RetryAndFollowUpInterceptor
//拦截器的intercept方法
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {val realChain = chain as RealInterceptorChainvar request = chain.requestval call = realChain.callvar followUpCount = 0var priorResponse: Response? = nullvar newRoutePlanner = truevar recoveredFailures = listOf<IOException>()//是个死循环，不过没关系，内部有限制机制while (true) {//在ConnectionInterceptor中会用到//第一次进入 循环时 newRoutePlanner为true，此时会创建一个ExchangeFinder对象，负责获取一条安全可靠的链接来携带请求call.enterNetworkInterceptorExchange(request, newRoutePlanner, chain)var response: Responsevar closeActiveExchange = true//如果本次请求被取消，那么抛出错误，跳出循环try {if (call.isCanceled()) {throw IOException("Canceled")}try {//在这里我们调用了责任链的proceed方法response = realChain.proceed(request)newRoutePlanner = true} catch (e: IOException) {// An attempt to communicate with a server failed. The request may have been sent.//进入recover方法，在该方法中如果错误是可以恢复的，那么将返回true进行重试，否则返回false，直接抛出错误。if (!recover(e, call, request, requestSendStarted = e !is ConnectionShutdownException)) {throw e.withSuppressed(recoveredFailures)} else {recoveredFailures += e}//由于是重试，将该参数设置为false。newRoutePlanner = falsecontinue}//在这里清空response的部分附加是因为本次可能是重试或者重定向，后续由下游的拦截器重新配置。// Clear out downstream interceptor's additional request headers, cookies, etc.response = response.newBuilder().request(request).priorResponse(priorResponse?.stripBody()).build()//该对象否则编码和解码val exchange = call.interceptorScopedExchange//在这个方法中，会根据response中的字段，判断是否进行重定向,若重定向则会返回新的request，否则返回nullval followUp = followUpRequest(response, exchange)//不重定向直接返回if (followUp == null) {if (exchange != null && exchange.isDuplex) {call.timeoutEarlyExit()}closeActiveExchange = falsereturn response}//一次性请求，不再重试或者重定向val followUpBody = followUp.bodyif (followUpBody != null && followUpBody.isOneShot()) {closeActiveExchange = falsereturn response}response.body.closeQuietly()//重定向次数超过一定次数就会抛出错误if (++followUpCount > MAX_FOLLOW_UPS) {throw ProtocolException("Too many follow-up requests: $followUpCount")}request = followUppriorResponse = response} finally {call.exitNetworkInterceptorExchange(closeActiveExchange)}}}
BridgeInterceptor - 我称它为网络请求的双向适配器
至于我为什么这么称呼它，我们先来看看官方给的注解
从应用程序代码到网络代码的桥梁。首先，它根据用户请求构建网络请求。然后它继续调用网络。最后，它从网络响应构建用户响应。
洋文版咱也贴一下 ：
Bridges from application code to network code. First it builds a network request from a user request. Then it proceeds to call the network. Finally it builds a user response from the network response.
有没有对于这个解释的结构很熟悉，没错，在开头，笔者就描述了大多数拦截器在其intercept方法中的逻辑结构，就是： 第一步处理request，第二步进入下一个拦截器，第三步根据第二步获得的response进行处理，最后返回response给上一层。
话不多说，上源码：
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {//首先获得requestval userRequest = chain.request()val requestBuilder = userRequest.newBuilder()val body = userRequest.bodyif (body != null) {val contentType = body.contentType()//在请求头部添加字段 Content-Type 也就是body的编码类型if (contentType != null) {requestBuilder.header("Content-Type", contentType.toString())}val contentLength = body.contentLength()//如果出现contentLength不为 -1 则需要设置content-length字段，界定是否传输完成if (contentLength != -1L) {requestBuilder.header("Content-Length", contentLength.toString())requestBuilder.removeHeader("Transfer-Encoding")} else {//分块传输，所以我们不需要Content-Length来界定是否传输完成。requestBuilder.header("Transfer-Encoding", "chunked")requestBuilder.removeHeader("Content-Length")}}//添加Host头部字段if (userRequest.header("Host") == null) {requestBuilder.header("Host", userRequest.url.toHostHeader())}//添加连接类型if (userRequest.header("Connection") == null) {requestBuilder.header("Connection", "Keep-Alive")}// If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing// the transfer stream.//对非分片传输且未设置压缩方式的请求，这里默认使用gzip压缩。var transparentGzip = falseif (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {transparentGzip = truerequestBuilder.header("Accept-Encoding", "gzip")}//添加cookie 用来跟踪用户身份val cookies = cookieJar.loadForRequest(userRequest.url)if (cookies.isNotEmpty()) {requestBuilder.header("Cookie", cookieHeader(cookies))}//用户代理if (userRequest.header("User-Agent") == null) {requestBuilder.header("User-Agent", userAgent)}val networkRequest = requestBuilder.build()//进入下一个拦截器，并获取响应数据val networkResponse = chain.proceed(networkRequest)//cookie管理cookieJar.receiveHeaders(networkRequest.url, networkResponse.headers)val responseBuilder = networkResponse.newBuilder().request(networkRequest)//解压缩、去头部字段if (transparentGzip &&"gzip".equals(networkResponse.header("Content-Encoding"), ignoreCase = true) &&networkResponse.promisesBody()) {val responseBody = networkResponse.bodyif (responseBody != null) {val gzipSource = GzipSource(responseBody.source())val strippedHeaders = networkResponse.headers.newBuilder().removeAll("Content-Encoding").removeAll("Content-Length").build()responseBuilder.headers(strippedHeaders)val contentType = networkResponse.header("Content-Type")responseBuilder.body(RealResponseBody(contentType, -1L, gzipSource.buffer()))}}return responseBuilder.build()}看完源码之后，我们可以清晰的知道，所谓的桥梁就是在请求发送之前，对请求进行加头部字段，发送之后获得response对响应进行拆头部字段，cookie管理以及解压缩。
CacheInterceptor - 缓存拦截器
利用好缓存其实就可以为我们节约大量的资源消耗，也就是说可以避免发送大量的重复请求，如果击中缓存，我们就可以直接使用本地缓存进行加载，而不去进行网络请求，这也是为什么Okhttp会在这里设置缓存拦截器的一个重要原因。现在我们来看看源码，看缓存拦截器到底是怎么工作的吧：
源码 ：
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {val call = chain.call()val cacheCandidate = cache?.get(chain.request())val now = System.currentTimeMillis()//获得缓存策略，并判断是否使用网络。val strategy = CacheStrategy.Factory(now, chain.request(), cacheCandidate)pute()val networkRequest = strategyworkRequest // null 表示不允许使用网络val cacheResponse = strategy.cacheResponse // null表示未击中缓存cache?.trackResponse(strategy)val listener = (call as? RealCall)?.eventListener ?: EventListener.NONEif (cacheCandidate != null && cacheResponse == null) {// The cache candidate wasn't applicable. Close it.//缓存候选人不适用，则关闭它。cacheCandidate.body.closeQuietly()}// If we're forbidden from using the network and the cache is insufficient, fail.// 如果我们被禁止使用网络并且缓存不足，则失败。if (networkRequest == null && cacheResponse == null) {return Response.Builder().request(chain.request()).protocol(Protocol.HTTP_1_1).code(HTTP_GATEWAY_TIMEOUT).message("Unsatisfiable Request (only-if-cached)").sentRequestAtMillis(-1L).receivedResponseAtMillis(System.currentTimeMillis()).build().also {listener.satisfactionFailure(call, it)}}// If we don't need the network, we're done.//如果我们不需要网络，并且缓存可用，那么我们就返回缓存。if (networkRequest == null) {return cacheResponse!!.newBuilder().cacheResponse(cacheResponse.stripBody()).build().also {listener.cacheHit(call, it)}}//到这一步了，其实缓存可能命中（协商缓存）也可能未命中，但是都得通过网络去判断。if (cacheResponse != null) {//缓存命中listener.cacheConditionalHit(call, cacheResponse)} else if (cache != null) {//缓存未命中listener.cacheMiss(call)}var networkResponse: Response? = nulltry {//进入下一层 并获取网络响应networkResponse = chain.proceed(networkRequest)} finally {// If we're crashing on I/O or otherwise, don't leak the cache body.if (networkResponse == null && cacheCandidate != null) {//关闭缓存，防止泄露cacheCandidate.body.closeQuietly()}}// If we have a cache response too, then we're doing a conditional get.//上面命中缓存if (cacheResponse != null) {//协商缓存成功，服务端返回的是304重定向，所以在这里利用缓存构建响应数据if (networkResponse?.code == HTTP_NOT_MODIFIED) {val response = cacheResponse.newBuilder().headers(combine(cacheResponse.headers, networkResponse.headers)).sentRequestAtMillis(networkResponse.sentRequestAtMillis).receivedResponseAtMillis(networkResponse.receivedResponseAtMillis).cacheResponse(cacheResponse.stripBody())workResponse(networkResponse.stripBody()).build()networkResponse.body.close()// Update the cache after combining headers but before stripping the// Content-Encoding header (as performed by initContentStream()).//在剥离Content-Enconding 字段前更新缓存cache!!.trackConditionalCacheHit()cache.update(cacheResponse, response)return response.also {listener.cacheHit(call, it)}} else {cacheResponse.body.closeQuietly()}}//利用网络返回数据，构建响应数据val response = networkResponse!!.newBuilder().cacheResponse(cacheResponse?.stripBody())workResponse(networkResponse.stripBody()).build()//如果缓存对象不为空，则设置缓存if (cache != null) {if (response.promisesBody() && CacheStrategy.isCacheable(response, networkRequest)) {// Offer this request to the cache.val cacheRequest = cache.put(response)return cacheWritingResponse(cacheRequest, response).also {if (cacheResponse != null) {// This will log a conditional cache miss only.//提交数据给缓存，同时记录缓存未命中listener.cacheMiss(call)}}}//只缓存GET请求的数据if (HttpMethod.invalidatesCache(networkRequest.method)) {try {cache.remove(networkRequest)} catch (_: IOException) {// The cache cannot be written.}}}return response}
其实，okhttp就是将整个网络请求过程进行了分层，所以对于计算机基础学好是真的很重要，上层永远在变，但是底层基础想要改变则需要长时间的演变。所以请注重基础!
ConnectionInterceptor - 连接拦截器
这一层是完成网络请求中，连接的建立，比如什么TCP握手，TLS/SSL握手这些操作的。该层的源码看起来是很少的，但是实际上完成的的很多，也比较难分析，所以笔者不会像上面的拦截器一样只是对其Intercept方法进行简单分析就ok了，笔者会适当展开，当然限于水平，也只能适当！
咱们看源码（很少）：
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {val realChain = chain as RealInterceptorChain// 别看下面这一行代码，分析起来，可以重新写一篇了！！！val exchange = realChain.call.initExchange(realChain) val connectedChain = realChain.copy(exchange = exchange)return connectedChain.proceed(realChain.request)}
进入到initExchange方法内部看看：
在这之前，笔者介绍一下 Exchange 和 ExchangeFinder以及codec
Exchange ：一次数据交换、可以理解为一条连接客户端和服务端的连接。
ExchangeFinder 可以理解为寻找这条连接的工具，寻找一条可用的连接以及相应的一些信息。
codec：编解码器。
internal fun initExchange(chain: RealInterceptorChain): Exchange {...val exchangeFinder = this.exchangeFinder!!//寻找可用的连接val connection = exchangeFinder.find()//获取格式兼容的编码器 http1.1/2.0val codec = connection.newCodec(client, chain)val result = Exchange(this, eventListener, exchangeFinder, codec)this.interceptorScopedExchange = resultthis.exchange = resultsynchronized(this) {this.requestBodyOpen = truethis.responseBodyOpen = true}if (canceled) throw IOException("Canceled")return result}
那么实际上val connection = exchangeFinder.find() 这行代码 才是重点！！！！它要寻找一条可用的连接。我们知道okhttp是有连接池的，所以在这一步，我们会优先利用可复用的连接，实在不行才会创建。还记得在RetryAndFollowInterceptor笔者说过 exchangeFinder的初始化吗？我们在这就用到了。实际上它按照客户端是否支持快速回退有两种不同的实现，感兴趣的可以去看下。那么这里笔者就只能写到这个层面了。外链。
NetWorkInterceptor - 网络拦截器
这个拦截器也是由我们自己添加的，主要的作用是用于监测网络。具体就不展开写了。自行了解。
CallServerInterceptor - 请求拦截器
在ConnectionInterceptor完成TCP、SSL/TLS、获取编码解码器 等操作之后，就会交由最后一个拦截器CallServerInterceptor去发送请求与服务器交互数据。
override fun intercept(chain: Interceptor.Chain): Response {
...try {//使用对应的编码器进行http请求头的构建exchange.writeRequestHeaders(request)if (HttpMethod.permitsRequestBody(request.method) && requestBody != null) {// If there's a "Expect: 100-continue" header on the request, wait for a "HTTP/1.1 100// Continue" response before transmitting the request body. If we don't get that, return// what we did get (such as a 4xx response) without ever transmitting the request body.if ("100-continue".equals(request.header("Expect"), ignoreCase = true)) {exchange.flushRequest()responseBuilder = exchange.readResponseHeaders(expectContinue = true)exchange.responseHeadersStart()invokeStartEvent = false}if (responseBuilder == null) {if (requestBody.isDuplex()) {// Prepare a duplex body so that the application can send a request body later.exchange.flushRequest()val bufferedRequestBody = exchange.createRequestBody(request, true).buffer()requestBody.writeTo(bufferedRequestBody)} else {// Write the request body if the "Expect: 100-continue" expectation was met.val bufferedRequestBody = exchange.createRequestBody(request, false).buffer()requestBody.writeTo(bufferedRequestBody)bufferedRequestBody.close()}} else {exchange.noRequestBody()if (!exchange.connection.isMultiplexed) {// If the "Expect: 100-continue" expectation wasn't met, prevent the HTTP/1 connection// from being reused. Otherwise we're still obligated to transmit the request body to// leave the connection in a consistent state.exchange.noNewExchangesOnConnection()}}} else {exchange.noRequestBody()}if (requestBody == null || !requestBody.isDuplex()) {exchange.finishRequest()}} catch (e: IOException) {if (e is ConnectionShutdownException) {throw e // No request was sent so there's no response to read.}if (!exchange.hasFailure) {throw e // Don't attempt to read the response; we failed to send the request.}sendRequestException = e}try {if (responseBuilder == null) {responseBuilder = exchange.readResponseHeaders(expectContinue = false)!!if (invokeStartEvent) {exchange.responseHeadersStart()invokeStartEvent = false}}var response = responseBuilder.request(request).handshake(exchange.connection.handshake()).sentRequestAtMillis(sentRequestMillis).receivedResponseAtMillis(System.currentTimeMillis()).build()var code = response.codeif (code == 100) {// Server sent a 100-continue even though we did not request one. Try again to read the// actual response status.responseBuilder = exchange.readResponseHeaders(expectContinue = false)!!if (invokeStartEvent) {exchange.responseHeadersStart()}response = responseBuilder.request(request).handshake(exchange.connection.handshake()).sentRequestAtMillis(sentRequestMillis).receivedResponseAtMillis(System.currentTimeMillis()).build()code = response.code}exchange.responseHeadersEnd(response)response = if (forWebSocket && code == 101) {// Connection is upgrading, but we need to ensure interceptors see a non-null response body.response.stripBody()} else {response.newBuilder().body(exchange.openResponseBody(response)).build()}if ("close".equals(response.request.header("Connection"), ignoreCase = true) ||"close".equals(response.header("Connection"), ignoreCase = true)) {exchange.noNewExchangesOnConnection()}if ((code == 204 || code == 205) && response.body.contentLength() > 0L) {throw ProtocolException("HTTP $code had non-zero Content-Length: ${response.body.contentLength()}")}return response} catch (e: IOException) {if (sendRequestException != null) {sendRequestException.addSuppressed(e)throw sendRequestException}throw e}}
参考
okhttp源码
OkHttp源码解析
听说你很熟悉Okhttp
Okhttp中类作用解析
OkHttp
续
根据上一篇 核心流程 ，我们大致知道了okhttp的内部运转，但是对于网络请求的缓存、连接复用以及网络监控的功能的实现，我们是只知其然，而不知其所以然，我们只知道是负责各个功能的拦截器帮助我们完成了底层的任务，但是却不知道原理是什么。今天跟着笔者继续学习Okhttp各个拦截器的原理实现。限于篇幅，在文章中，笔者只对相关拦截器的intercept方法进行了分析，但是并没有展开，有兴趣的同学可以自己去看。
回顾
我们知道Okhttp的核心功能的实现就是一套由拦截器组成的责任链机制，而这个责任链的入口就是getResponseWithInterceptorChain方法，我们再次贴出它的源码：
@Throws(IOException::class)internal fun getResponseWithInterceptorChain(): Response {// Build a full stack of interceptors.val interceptors = mutableListOf<Interceptor>()interceptors += client.interceptorsinterceptors += RetryAndFollowUpInterceptor(client)interceptors += BridgeInterceptor(client.cookieJar)interceptors += CacheInterceptor(client.cache)interceptors += ConnectInterceptorif (!forWebSocket) {interceptors += clientworkInterceptors}interceptors += CallServerInterceptor(forWebSocket)...var calledNoMoreExchanges = falsetry {val response = chain.proceed(originalRequest)if (isCanceled()) {response.closeQuietly()throw IOException("Canceled")}return response} catch (e: IOException) {...} finally {...}}上面拦截器的添加顺序实际上就是后面它们的执行顺序。
可以看到第一个添加的是应用拦截器，这个是在我们创建request的时候添加的，这个过程一般用于添加一些自定义的header、参数、网关接入等信息。所以这边我们就简单介绍一下
大概的拦截器工作原理
我说的所谓的工作原理其实就是拦截器的intercept方法是怎么运行的，当然在最后的请求拦截器（CallServerInterceptor）会有所不同，因为不需要向下递归了，而是开始回溯。
（实际上整个拦截链再笔者看来就是一个递归的过程。）
给大家贴一个interceptor的源码，它实际上是一个接口，然后内部有一个intercept方法还有一个接口Chain。这个Chain的实现类是RealInterceptorChain.java 这个源码就不贴了，没记错上篇文章给了。
fun interface Interceptor {@Throws(IOException::class)fun intercept(chain: Chain): Responsecompanion object {inline operator fun invoke(crossinline block: (chain: Chain) -> Response): Interceptor =Interceptor { block(it) }}interface Chain {fun request(): Request@Throws(IOException::class)fun proceed(request: Request): Responsefun connection(): Connection?fun call(): Callfun connectTimeoutMillis(): Intfun withConnectTimeout(timeout: Int, unit: TimeUnit): Chainfun readTimeoutMillis(): Intfun withReadTimeout(timeout: Int, unit: TimeUnit): Chainfun writeTimeoutMillis(): Intfun withWriteTimeout(timeout: Int, unit: TimeUnit): Chain}
}
实际上在拦截器内部，我们执行intercept方法，内部的逻辑大概分为 request部分的逻辑、调用Chain的proceed方法进入下一个拦截器，然后根据回溯得到的reponse 做处理。最后再返回response。
override fun intercept(chain : inteceptor.Chain ) :Response{val request = chain.request();// Request阶段，该拦截器在Request阶段负责做的事情// 调用RealInterceptorChain.proceed()，其实是在递归调用下一个拦截器的intercept()方法response = chain.proceed(request, streamAllocation, null, null);// Response阶段，完成了该拦截器在Response阶段负责做的事情，然后返回到上一层的拦截器。return response;
}拦截器
用户自定义的拦截逻辑 - 应用拦截器
应用拦截器最先被触发，并且在一次请求中只会被触发一次。
应用拦截器的作用通常由程序员设置，我们继承Interceptor类重写它的intercept方法，当我们在构建request时将该拦截器加入，那么在后续的拦截链中就会执行 我们在内部intercept方法中写的逻辑了，这里我就不给大家示例了，想要了解的可以自行查阅。
完成重定向及重试的幕后 - RetryAndFollowUpInterceptor
如果我们在构建request时没有加入应用拦截器，那么实际上第一次执行的就是RetryAndFollowUpInterceptor了，它的作用看名称也能明白 重试与重定向，重定向是什么意思呢？我们学过计算机网络知道，当我们访问一个站点时，该站点可能不能处理，需要浏览器重新向新的站点发起请求，并且返回3** 状态码 以及在返回的数据中的location字段中放入需要重定向的url。所以当本次请求返回数据时回溯到该层时，就进行一个判断如果location的字段值不为空，那么就会进行一次重定向请求。具体的话我们来看源码：
#RetryAndFollowUpInterceptor
//拦截器的intercept方法
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {val realChain = chain as RealInterceptorChainvar request = chain.requestval call = realChain.callvar followUpCount = 0var priorResponse: Response? = nullvar newRoutePlanner = truevar recoveredFailures = listOf<IOException>()//是个死循环，不过没关系，内部有限制机制while (true) {//在ConnectionInterceptor中会用到//第一次进入 循环时 newRoutePlanner为true，此时会创建一个ExchangeFinder对象，负责获取一条安全可靠的链接来携带请求call.enterNetworkInterceptorExchange(request, newRoutePlanner, chain)var response: Responsevar closeActiveExchange = true//如果本次请求被取消，那么抛出错误，跳出循环try {if (call.isCanceled()) {throw IOException("Canceled")}try {//在这里我们调用了责任链的proceed方法response = realChain.proceed(request)newRoutePlanner = true} catch (e: IOException) {// An attempt to communicate with a server failed. The request may have been sent.//进入recover方法，在该方法中如果错误是可以恢复的，那么将返回true进行重试，否则返回false，直接抛出错误。if (!recover(e, call, request, requestSendStarted = e !is ConnectionShutdownException)) {throw e.withSuppressed(recoveredFailures)} else {recoveredFailures += e}//由于是重试，将该参数设置为false。newRoutePlanner = falsecontinue}//在这里清空response的部分附加是因为本次可能是重试或者重定向，后续由下游的拦截器重新配置。// Clear out downstream interceptor's additional request headers, cookies, etc.response = response.newBuilder().request(request).priorResponse(priorResponse?.stripBody()).build()//该对象否则编码和解码val exchange = call.interceptorScopedExchange//在这个方法中，会根据response中的字段，判断是否进行重定向,若重定向则会返回新的request，否则返回nullval followUp = followUpRequest(response, exchange)//不重定向直接返回if (followUp == null) {if (exchange != null && exchange.isDuplex) {call.timeoutEarlyExit()}closeActiveExchange = falsereturn response}//一次性请求，不再重试或者重定向val followUpBody = followUp.bodyif (followUpBody != null && followUpBody.isOneShot()) {closeActiveExchange = falsereturn response}response.body.closeQuietly()//重定向次数超过一定次数就会抛出错误if (++followUpCount > MAX_FOLLOW_UPS) {throw ProtocolException("Too many follow-up requests: $followUpCount")}request = followUppriorResponse = response} finally {call.exitNetworkInterceptorExchange(closeActiveExchange)}}}
BridgeInterceptor - 我称它为网络请求的双向适配器
至于我为什么这么称呼它，我们先来看看官方给的注解
从应用程序代码到网络代码的桥梁。首先，它根据用户请求构建网络请求。然后它继续调用网络。最后，它从网络响应构建用户响应。
洋文版咱也贴一下 ：
Bridges from application code to network code. First it builds a network request from a user request. Then it proceeds to call the network. Finally it builds a user response from the network response.
有没有对于这个解释的结构很熟悉，没错，在开头，笔者就描述了大多数拦截器在其intercept方法中的逻辑结构，就是： 第一步处理request，第二步进入下一个拦截器，第三步根据第二步获得的response进行处理，最后返回response给上一层。
话不多说，上源码：
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {//首先获得requestval userRequest = chain.request()val requestBuilder = userRequest.newBuilder()val body = userRequest.bodyif (body != null) {val contentType = body.contentType()//在请求头部添加字段 Content-Type 也就是body的编码类型if (contentType != null) {requestBuilder.header("Content-Type", contentType.toString())}val contentLength = body.contentLength()//如果出现contentLength不为 -1 则需要设置content-length字段，界定是否传输完成if (contentLength != -1L) {requestBuilder.header("Content-Length", contentLength.toString())requestBuilder.removeHeader("Transfer-Encoding")} else {//分块传输，所以我们不需要Content-Length来界定是否传输完成。requestBuilder.header("Transfer-Encoding", "chunked")requestBuilder.removeHeader("Content-Length")}}//添加Host头部字段if (userRequest.header("Host") == null) {requestBuilder.header("Host", userRequest.url.toHostHeader())}//添加连接类型if (userRequest.header("Connection") == null) {requestBuilder.header("Connection", "Keep-Alive")}// If we add an "Accept-Encoding: gzip" header field we're responsible for also decompressing// the transfer stream.//对非分片传输且未设置压缩方式的请求，这里默认使用gzip压缩。var transparentGzip = falseif (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {transparentGzip = truerequestBuilder.header("Accept-Encoding", "gzip")}//添加cookie 用来跟踪用户身份val cookies = cookieJar.loadForRequest(userRequest.url)if (cookies.isNotEmpty()) {requestBuilder.header("Cookie", cookieHeader(cookies))}//用户代理if (userRequest.header("User-Agent") == null) {requestBuilder.header("User-Agent", userAgent)}val networkRequest = requestBuilder.build()//进入下一个拦截器，并获取响应数据val networkResponse = chain.proceed(networkRequest)//cookie管理cookieJar.receiveHeaders(networkRequest.url, networkResponse.headers)val responseBuilder = networkResponse.newBuilder().request(networkRequest)//解压缩、去头部字段if (transparentGzip &&"gzip".equals(networkResponse.header("Content-Encoding"), ignoreCase = true) &&networkResponse.promisesBody()) {val responseBody = networkResponse.bodyif (responseBody != null) {val gzipSource = GzipSource(responseBody.source())val strippedHeaders = networkResponse.headers.newBuilder().removeAll("Content-Encoding").removeAll("Content-Length").build()responseBuilder.headers(strippedHeaders)val contentType = networkResponse.header("Content-Type")responseBuilder.body(RealResponseBody(contentType, -1L, gzipSource.buffer()))}}return responseBuilder.build()}看完源码之后，我们可以清晰的知道，所谓的桥梁就是在请求发送之前，对请求进行加头部字段，发送之后获得response对响应进行拆头部字段，cookie管理以及解压缩。
CacheInterceptor - 缓存拦截器
利用好缓存其实就可以为我们节约大量的资源消耗，也就是说可以避免发送大量的重复请求，如果击中缓存，我们就可以直接使用本地缓存进行加载，而不去进行网络请求，这也是为什么Okhttp会在这里设置缓存拦截器的一个重要原因。现在我们来看看源码，看缓存拦截器到底是怎么工作的吧：
源码 ：
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {val call = chain.call()val cacheCandidate = cache?.get(chain.request())val now = System.currentTimeMillis()//获得缓存策略，并判断是否使用网络。val strategy = CacheStrategy.Factory(now, chain.request(), cacheCandidate)pute()val networkRequest = strategyworkRequest // null 表示不允许使用网络val cacheResponse = strategy.cacheResponse // null表示未击中缓存cache?.trackResponse(strategy)val listener = (call as? RealCall)?.eventListener ?: EventListener.NONEif (cacheCandidate != null && cacheResponse == null) {// The cache candidate wasn't applicable. Close it.//缓存候选人不适用，则关闭它。cacheCandidate.body.closeQuietly()}// If we're forbidden from using the network and the cache is insufficient, fail.// 如果我们被禁止使用网络并且缓存不足，则失败。if (networkRequest == null && cacheResponse == null) {return Response.Builder().request(chain.request()).protocol(Protocol.HTTP_1_1).code(HTTP_GATEWAY_TIMEOUT).message("Unsatisfiable Request (only-if-cached)").sentRequestAtMillis(-1L).receivedResponseAtMillis(System.currentTimeMillis()).build().also {listener.satisfactionFailure(call, it)}}// If we don't need the network, we're done.//如果我们不需要网络，并且缓存可用，那么我们就返回缓存。if (networkRequest == null) {return cacheResponse!!.newBuilder().cacheResponse(cacheResponse.stripBody()).build().also {listener.cacheHit(call, it)}}//到这一步了，其实缓存可能命中（协商缓存）也可能未命中，但是都得通过网络去判断。if (cacheResponse != null) {//缓存命中listener.cacheConditionalHit(call, cacheResponse)} else if (cache != null) {//缓存未命中listener.cacheMiss(call)}var networkResponse: Response? = nulltry {//进入下一层 并获取网络响应networkResponse = chain.proceed(networkRequest)} finally {// If we're crashing on I/O or otherwise, don't leak the cache body.if (networkResponse == null && cacheCandidate != null) {//关闭缓存，防止泄露cacheCandidate.body.closeQuietly()}}// If we have a cache response too, then we're doing a conditional get.//上面命中缓存if (cacheResponse != null) {//协商缓存成功，服务端返回的是304重定向，所以在这里利用缓存构建响应数据if (networkResponse?.code == HTTP_NOT_MODIFIED) {val response = cacheResponse.newBuilder().headers(combine(cacheResponse.headers, networkResponse.headers)).sentRequestAtMillis(networkResponse.sentRequestAtMillis).receivedResponseAtMillis(networkResponse.receivedResponseAtMillis).cacheResponse(cacheResponse.stripBody())workResponse(networkResponse.stripBody()).build()networkResponse.body.close()// Update the cache after combining headers but before stripping the// Content-Encoding header (as performed by initContentStream()).//在剥离Content-Enconding 字段前更新缓存cache!!.trackConditionalCacheHit()cache.update(cacheResponse, response)return response.also {listener.cacheHit(call, it)}} else {cacheResponse.body.closeQuietly()}}//利用网络返回数据，构建响应数据val response = networkResponse!!.newBuilder().cacheResponse(cacheResponse?.stripBody())workResponse(networkResponse.stripBody()).build()//如果缓存对象不为空，则设置缓存if (cache != null) {if (response.promisesBody() && CacheStrategy.isCacheable(response, networkRequest)) {// Offer this request to the cache.val cacheRequest = cache.put(response)return cacheWritingResponse(cacheRequest, response).also {if (cacheResponse != null) {// This will log a conditional cache miss only.//提交数据给缓存，同时记录缓存未命中listener.cacheMiss(call)}}}//只缓存GET请求的数据if (HttpMethod.invalidatesCache(networkRequest.method)) {try {cache.remove(networkRequest)} catch (_: IOException) {// The cache cannot be written.}}}return response}
其实，okhttp就是将整个网络请求过程进行了分层，所以对于计算机基础学好是真的很重要，上层永远在变，但是底层基础想要改变则需要长时间的演变。所以请注重基础!
ConnectionInterceptor - 连接拦截器
这一层是完成网络请求中，连接的建立，比如什么TCP握手，TLS/SSL握手这些操作的。该层的源码看起来是很少的，但是实际上完成的的很多，也比较难分析，所以笔者不会像上面的拦截器一样只是对其Intercept方法进行简单分析就ok了，笔者会适当展开，当然限于水平，也只能适当！
咱们看源码（很少）：
@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {val realChain = chain as RealInterceptorChain// 别看下面这一行代码，分析起来，可以重新写一篇了！！！val exchange = realChain.call.initExchange(realChain) val connectedChain = realChain.copy(exchange = exchange)return connectedChain.proceed(realChain.request)}
进入到initExchange方法内部看看：
在这之前，笔者介绍一下 Exchange 和 ExchangeFinder以及codec
Exchange ：一次数据交换、可以理解为一条连接客户端和服务端的连接。
ExchangeFinder 可以理解为寻找这条连接的工具，寻找一条可用的连接以及相应的一些信息。
codec：编解码器。
internal fun initExchange(chain: RealInterceptorChain): Exchange {...val exchangeFinder = this.exchangeFinder!!//寻找可用的连接val connection = exchangeFinder.find()//获取格式兼容的编码器 http1.1/2.0val codec = connection.newCodec(client, chain)val result = Exchange(this, eventListener, exchangeFinder, codec)this.interceptorScopedExchange = resultthis.exchange = resultsynchronized(this) {this.requestBodyOpen = truethis.responseBodyOpen = true}if (canceled) throw IOException("Canceled")return result}
那么实际上val connection = exchangeFinder.find() 这行代码 才是重点！！！！它要寻找一条可用的连接。我们知道okhttp是有连接池的，所以在这一步，我们会优先利用可复用的连接，实在不行才会创建。还记得在RetryAndFollowInterceptor笔者说过 exchangeFinder的初始化吗？我们在这就用到了。实际上它按照客户端是否支持快速回退有两种不同的实现，感兴趣的可以去看下。那么这里笔者就只能写到这个层面了。外链。
NetWorkInterceptor - 网络拦截器
这个拦截器也是由我们自己添加的，主要的作用是用于监测网络。具体就不展开写了。自行了解。
CallServerInterceptor - 请求拦截器
在ConnectionInterceptor完成TCP、SSL/TLS、获取编码解码器 等操作之后，就会交由最后一个拦截器CallServerInterceptor去发送请求与服务器交互数据。
override fun intercept(chain: Interceptor.Chain): Response {
...try {//使用对应的编码器进行http请求头的构建exchange.writeRequestHeaders(request)if (HttpMethod.permitsRequestBody(request.method) && requestBody != null) {// If there's a "Expect: 100-continue" header on the request, wait for a "HTTP/1.1 100// Continue" response before transmitting the request body. If we don't get that, return// what we did get (such as a 4xx response) without ever transmitting the request body.if ("100-continue".equals(request.header("Expect"), ignoreCase = true)) {exchange.flushRequest()responseBuilder = exchange.readResponseHeaders(expectContinue = true)exchange.responseHeadersStart()invokeStartEvent = false}if (responseBuilder == null) {if (requestBody.isDuplex()) {// Prepare a duplex body so that the application can send a request body later.exchange.flushRequest()val bufferedRequestBody = exchange.createRequestBody(request, true).buffer()requestBody.writeTo(bufferedRequestBody)} else {// Write the request body if the "Expect: 100-continue" expectation was met.val bufferedRequestBody = exchange.createRequestBody(request, false).buffer()requestBody.writeTo(bufferedRequestBody)bufferedRequestBody.close()}} else {exchange.noRequestBody()if (!exchange.connection.isMultiplexed) {// If the "Expect: 100-continue" expectation wasn't met, prevent the HTTP/1 connection// from being reused. Otherwise we're still obligated to transmit the request body to// leave the connection in a consistent state.exchange.noNewExchangesOnConnection()}}} else {exchange.noRequestBody()}if (requestBody == null || !requestBody.isDuplex()) {exchange.finishRequest()}} catch (e: IOException) {if (e is ConnectionShutdownException) {throw e // No request was sent so there's no response to read.}if (!exchange.hasFailure) {throw e // Don't attempt to read the response; we failed to send the request.}sendRequestException = e}try {if (responseBuilder == null) {responseBuilder = exchange.readResponseHeaders(expectContinue = false)!!if (invokeStartEvent) {exchange.responseHeadersStart()invokeStartEvent = false}}var response = responseBuilder.request(request).handshake(exchange.connection.handshake()).sentRequestAtMillis(sentRequestMillis).receivedResponseAtMillis(System.currentTimeMillis()).build()var code = response.codeif (code == 100) {// Server sent a 100-continue even though we did not request one. Try again to read the// actual response status.responseBuilder = exchange.readResponseHeaders(expectContinue = false)!!if (invokeStartEvent) {exchange.responseHeadersStart()}response = responseBuilder.request(request).handshake(exchange.connection.handshake()).sentRequestAtMillis(sentRequestMillis).receivedResponseAtMillis(System.currentTimeMillis()).build()code = response.code}exchange.responseHeadersEnd(response)response = if (forWebSocket && code == 101) {// Connection is upgrading, but we need to ensure interceptors see a non-null response body.response.stripBody()} else {response.newBuilder().body(exchange.openResponseBody(response)).build()}if ("close".equals(response.request.header("Connection"), ignoreCase = true) ||"close".equals(response.header("Connection"), ignoreCase = true)) {exchange.noNewExchangesOnConnection()}if ((code == 204 || code == 205) && response.body.contentLength() > 0L) {throw ProtocolException("HTTP $code had non-zero Content-Length: ${response.body.contentLength()}")}return response} catch (e: IOException) {if (sendRequestException != null) {sendRequestException.addSuppressed(e)throw sendRequestException}throw e}}
参考
okhttp源码
OkHttp源码解析
听说你很熟悉Okhttp
Okhttp中类作用解析