OkHttp源码流程分析(response篇)
2020-12-31 本文已影响0人
A邱凌
前言
我们之前阅读了Request的整体流程 没看过的同学可以参考OkHttp源码流程分析(request篇)
还有response的处理没有分析 我们知道OkHttp的请求与响应的过程是个责任链的调用 也就是U型调用 所以我们这次和Request篇的顺序反过来分析
CallServerInterceptor&ConnectInterceptor
这两个拦截器主要的功能是创建server端连接以及与server端交互数据 所以我们可以跳过这两个
BridgeInterceptor
我们之前已经分析过 BridgeInterceptor在请求的过程中 主要是对header进行处理 包括gzip压缩,cookie添加等等
在响应过程中 主要是做了gzip解压已经cookie保存等等 源码比较简单 我们直接来看一下源码👆
@Throws(IOException::class)
override fun intercept(chain: Interceptor.Chain): Response {
......request处理
val networkResponse = chain.proceed(requestBuilder.build())
//处理header中Set-Cookie内容 将cookie保存
cookieJar.receiveHeaders(userRequest.url, networkResponse.headers)
//将原始request放入response中
val responseBuilder = networkResponse.newBuilder()
.request(userRequest)
if (transparentGzip &&
"gzip".equals(networkResponse.header("Content-Encoding"), ignoreCase = true) &&
networkResponse.promisesBody()) {
val responseBody = networkResponse.body
if (responseBody != null) {
//封装成GzipSource 重写read方法 解压gzip
val gzipSource = GzipSource(responseBody.source())
val strippedHeaders = networkResponse.headers.newBuilder()
.removeAll("Content-Encoding")
.removeAll("Content-Length")
.build()
//精简header
responseBuilder.headers(strippedHeaders)
val contentType = networkResponse.header("Content-Type")
responseBuilder.body(RealResponseBody(contentType, -1L, gzipSource.buffer()))
}
}
return responseBuilder.build()
}
RetryAndFollowUpInterceptor
这个拦截器我们在上篇有讲 主要是处理像超时、重定向等错误 所以我们在上篇并没有过多的去看这个拦截器
现在我们就看一下 RetryAndFollowUpInterceptor是如何进行对不同的code做处理的
我们直接看一下关键代码 逻辑也比较简单
@Throws(IOException::class)
override fun intercept(chain: Interceptor.Chain): Response {
......
//这里是一个无限循环 直到超过重试次数 或者抛出异常为终止
while (true) {
......request
try {
if (call.isCanceled()) {
throw IOException("Canceled")
}
try {
response = realChain.proceed(request)
newExchangeFinder = true
} catch (e: RouteException) {
......
continue
} catch (e: IOException) {
......
continue
}
// Attach the prior response if it exists. Such responses never have a body.
if (priorResponse != null) {
response = response.newBuilder()
.priorResponse(priorResponse.newBuilder()
.body(null)
.build())
.build()
}
val exchange = call.interceptorScopedExchange
//这里会根据不同的code 确定是否需要创建newRequest
val followUp = followUpRequest(response, exchange)
if (followUp == null) {
if (exchange != null && exchange.isDuplex) {
call.timeoutEarlyExit()
}
closeActiveExchange = false
return response
}
val followUpBody = followUp.body
if (followUpBody != null && followUpBody.isOneShot()) {
closeActiveExchange = false
return response
}
response.body?.closeQuietly()
//如果超过重试次数 则抛出异常
if (++followUpCount > MAX_FOLLOW_UPS) {
throw ProtocolException("Too many follow-up requests: $followUpCount")
}
request = followUp
priorResponse = response
} finally {
call.exitNetworkInterceptorExchange(closeActiveExchange)
}
}
}
我们看到有一个while死循环 会对code进行不同重试等处理 我们看一下followUpRequest()方法
@Throws(IOException::class)
private fun followUpRequest(userResponse: Response, exchange: Exchange?): Request? {
val route = exchange?.connection?.route()
val responseCode = userResponse.code
val method = userResponse.request.method
when (responseCode) {
//HTTP代理验证
HTTP_PROXY_AUTH -> {
val selectedProxy = route!!.proxy
if (selectedProxy.type() != Proxy.Type.HTTP) {
throw ProtocolException("Received HTTP_PROXY_AUTH (407) code while not using proxy")
}
return client.proxyAuthenticator.authenticate(route, userResponse)
}
//401
HTTP_UNAUTHORIZED -> return client.authenticator.authenticate(route, userResponse)
//临时重定向
HTTP_PERM_REDIRECT, HTTP_TEMP_REDIRECT -> {
// "If the 307 or 308 status code is received in response to a request other than GET
// or HEAD, the user agent MUST NOT automatically redirect the request"
if (method != "GET" && method != "HEAD") {
return null
}
return buildRedirectRequest(userResponse, method)
}
//300~303
HTTP_MULT_CHOICE, HTTP_MOVED_PERM, HTTP_MOVED_TEMP, HTTP_SEE_OTHER -> {
return buildRedirectRequest(userResponse, method)
}
//超时
HTTP_CLIENT_TIMEOUT -> {
// 408's are rare in practice, but some servers like HAProxy use this response code. The
// spec says that we may repeat the request without modifications. Modern browsers also
// repeat the request (even non-idempotent ones.)
if (!client.retryOnConnectionFailure) {
// The application layer has directed us not to retry the request.
return null
}
val requestBody = userResponse.request.body
if (requestBody != null && requestBody.isOneShot()) {
return null
}
val priorResponse = userResponse.priorResponse
if (priorResponse != null && priorResponse.code == HTTP_CLIENT_TIMEOUT) {
// We attempted to retry and got another timeout. Give up.
return null
}
if (retryAfter(userResponse, 0) > 0) {
return null
}
return userResponse.request
}
HTTP_UNAVAILABLE -> {
val priorResponse = userResponse.priorResponse
if (priorResponse != null && priorResponse.code == HTTP_UNAVAILABLE) {
// We attempted to retry and got another timeout. Give up.
return null
}
if (retryAfter(userResponse, Integer.MAX_VALUE) == 0) {
// specifically received an instruction to retry without delay
return userResponse.request
}
return null
}
HTTP_MISDIRECTED_REQUEST -> {
// OkHttp can coalesce HTTP/2 connections even if the domain names are different. See
// RealConnection.isEligible(). If we attempted this and the server returned HTTP 421, then
// we can retry on a different connection.
val requestBody = userResponse.request.body
if (requestBody != null && requestBody.isOneShot()) {
return null
}
if (exchange == null || !exchange.isCoalescedConnection) {
return null
}
exchange.connection.noCoalescedConnections()
return userResponse.request
}
else -> return null
}
}
我们看到会解析code 像重定向、超时重试等 会重新创建Request 然后重新进行请求
Interceptor和NetworkInterceptors区别
我们分析完Request和Response的流程之后 就会明白两者的区别
不管是否进行重定向错误重试等 Interceptor永远只会调用一次
而每一次重新请求都会调用NetworkInterceptors
比如我们请求http://www.origin.com 然后重定向到 http://www.new.com
Interceptor只会调用一次
而NetworkInterceptors会调用至少两次
所以我们在选择拦截器的过程中 如果需要对完整的请求流程都深度掌握 比如打印网络日志 就可以使用NetworkInterceptors
如果我们只需要加入我们自己的拦截器 并不关心网络的流向 则可以使用Interceptor拦截器
