简介:大三学生党一枚!主攻Android开发,对于Web和后端均有了解。
个人语录:取乎其上,得乎其中,取乎其中,得乎其下,以顶级态度写好一篇的博客。
前面已经简单的介绍了拦截器的概念和每一种拦截器的作用,凭借这一点还不足以打动面试官,还需要对每一个拦截器的源码有所了解,才能够扛住面试官的各种问题!
@TOC
1.RetryAndFollowUpInterceptor
1.1 源码分析
我们知道拦截器链执行procced
方法执行拦截器链中的每一个拦截器,拦截器则调用自身的intercept
方法执行,所以我们只需要对intercept
进行分析就可以了。
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();//从拦截器链获得原始的request请求,请求信息包含了url,携带的请求体等,如果需要重定向,可能会对Request做修改更新
RealInterceptorChain realChain = (RealInterceptorChain) chain;
Call call = realChain.call();//获得call请求的原始对象,下面会用到
EventListener eventListener = realChain.eventListener();
//创建StreamAllocation对象,他主要负责分配stream,这个对象在这里创建,却没有被使用
//他在后面的拦截会被使用,很重要
StreamAllocation streamAllocation = new StreamAllocation(client.connectionPool(),
createAddress(request.url()), call, eventListener, callStackTrace);
this.streamAllocation = streamAllocation;
int followUpCount = 0;//重试次数,默认最大重试次数是20
Response priorResponse = null;//这个priorResponse记录之前一次请求返回的Response
while (true) {
if (canceled) {
//如果已经取消该请求,立即释放streamAllocation,结束该请求,后面的拦截器都不会执行了
streamAllocation.release();
throw new IOException("Canceled");
}
Response response;//这个Resonse记录每次请求返回的response,
//就是根据response的返回结果判断是否需要重试的
boolean releaseConnection = true;//是否要释放connection的标志位
try {
response = realChain.proceed(request, streamAllocation, null, null);//调用下一个拦截器获得Response
releaseConnection = false;
} catch (RouteException e) {
//如果捕捉到路由异常
// The attempt to connect via a route failed. The request will not have been sent.
if (!recover(e.getLastConnectException(), streamAllocation, false, request)) {
throw e.getFirstConnectException();
}
releaseConnection = false;
continue;//尝试重新请求
} catch (IOException e) {
//捕捉到IO异常
// An attempt to communicate with a server failed. The request may have been sent.
boolean requestSendStarted = !(e instanceof ConnectionShutdownException);
if (!recover(e, streamAllocation, requestSendStarted, request)) throw e;
releaseConnection = false;
continue;//尝试重新请求
} finally {
//最后释放所有的资源
// We're throwing an unchecked exception. Release any resources.
if (releaseConnection) {
streamAllocation.streamFailed(null);
streamAllocation.release();
}
}
// Attach the prior response if it exists. Such responses never have a body.
//不保存响应体,所以body为null
if (priorResponse != null) {
//保存最新的Response,第一次执行请求这个if判断不会被执行
response = response.newBuilder()
.priorResponse(priorResponse.newBuilder()
.body(null)
.build())
.build();
}
Request followUp;//如果followUp为空表示没必要进行重试,直接返回response
try {
//followUpRequest是判断有没有必要进行重试的方法,他需要根据response进行判断得到followUp
followUp = followUpRequest(response, streamAllocation.route());
} catch (IOException e) {
streamAllocation.release();
throw e;
}
if (followUp == null) {
//如果followUp为空表示没必要进行重试,直接返回response
streamAllocation.release();
return response;
//下面的都不会被执行了
}
closeQuietly(response.body());
if (++followUpCount > MAX_FOLLOW_UPS) {
//超过重试次数,释放资源,不再重试,抛出异常
streamAllocation.release();
throw new ProtocolException("Too many follow-up requests: " + followUpCount);
}
if (followUp.body() instanceof UnrepeatableRequestBody) {
//如果是不能重复请求的请求体,就直接释放连接
streamAllocation.release();
throw new HttpRetryException("Cannot retry streamed HTTP body", response.code());
}
if (!sameConnection(response, followUp.url())) {
//比较是否是同一个host,port,schema
streamAllocation.release();//如果不是,先释放原来建立好的连接
streamAllocation = new StreamAllocation(client.connectionPool(),
createAddress(followUp.url()), call, eventListener, callStackTrace);
//获取最新followUp请求中指定的url建立流
this.streamAllocation = streamAllocation;//重新赋值
} else if (streamAllocation.codec() != null) {
throw new IllegalStateException("Closing the body of " + response
+ " didn't close its backing stream. Bad interceptor?");
}
request = followUp;//将请求改为重定向最新的请求
priorResponse = response;//记录最新的Response
}
}
1.2 工作原理
这些分析需要看懂才能明白RetryAndFollowUpInterceptor
拦截器的工作原理!
看完源代码以后,我们来简单梳理一下RetryAndFollowUpInterceptor
的工作原理。
原理:当
RetryAndFollowUpInterceptor
拦截器指定intercept
方法时,第一次执行时,会调用后面的拦截器链获得返回的Response
,然后根据Response
中的信息,最主要的就是状态码,重试次数,请求体是否允许重复请求,决定是否需要进行重新连接,既然要进行重新请求,那么有可能会对url进行改变,如果改变就不能使用之前建立好的stream
,需要重新建立。根据状态码判断如果不需要重新连接,则该请求直接返回Response
,工作结束!
2.BridgeInterceptor
当在RetryAndFollowUpInterceptor
拦截器中调用拦截器链的执行方法时,将会被执行的就是BridgeInterceptor
拦截器,先从源码分析再讲解原理.
2.1 源码分析
根据之前说的BridgeInterceptor
的作用,就是把用户传来的Request
转换成符合网络请求格式的Request
,把网络返回的Response
(可能被压缩过)转换成用户可以用的Response
,所以该拦截器就是对Request
和Response
做操作
@Override
public Response intercept(Chain chain) throws IOException {
Request userRequest = chain.request();
Request.Builder requestBuilder = userRequest.newBuilder();
//requestBuilder就是根据用户传来的Request创建一个请求构造,添加上一些请求字段
RequestBody body = userRequest.body();//获取请求体,一般请求体不需要被改变
if (body != null) {
MediaType contentType = body.contentType();
if (contentType != null) {
//添加Content-type字段
requestBuilder.header("Content-Type", contentType.toString());
}
long contentLength = body.contentLength();
if (contentLength != -1) {
//添加content-length字段
requestBuilder.header("Content-Length", Long.toString(contentLength));
requestBuilder.removeHeader("Transfer-Encoding");
} else {
//添加传输编码字段
requestBuilder.header("Transfer-Encoding", "chunked");
requestBuilder.removeHeader("Content-Length");
}
}
if (userRequest.header("Host") == null) {
//添加host字段
requestBuilder.header("Host", hostHeader(userRequest.url(), false));
}
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.
boolean transparentGzip = false; //是否支持Gzip压缩的标志位
if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {
//如果用户的接受编码为空,也就是对接受Response的编码没有要求,则允许Gzip压缩编码
transparentGzip = true;
requestBuilder.header("Accept-Encoding", "gzip");
}
List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());
//支持cookies
if (!cookies.isEmpty()) {
requestBuilder.header("Cookie", cookieHeader(cookies));
}
if (userRequest.header("User-Agent") == null) {
//指定发起请求的平台,引擎,版本号等信息
requestBuilder.header("User-Agent", Version.userAgent());
}
//对Reuqest的设置好了,再接着调用下一个拦截器获得Response,然后对Response进行处理返回给用户
Response networkResponse = chain.proceed(requestBuilder.build());
HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());
//着手根据网络返回的Response构建返回给用户的Response
Response.Builder responseBuilder = networkResponse.newBuilder()
.request(userRequest);
if (transparentGzip
&& "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))
&& HttpHeaders.hasBody(networkResponse)) {
//这是个复杂的判断逻辑,首先就是我们允许了Gzip编码,
// 第二个是响应的内容编码确实Gzip编码,第三个就是Response有返回体,
//任何一个条件不成立都没必要执行这一步
GzipSource responseBody = new GzipSource(networkResponse.body().source());
Headers strippedHeaders = networkResponse.headers().newBuilder()
.removeAll("Content-Encoding")
.removeAll("Content-Length")
.build();
//上面的这一系列操作,就是移除一系列头部,只返回重要信息给用户
responseBuilder.headers(strippedHeaders);
String contentType = networkResponse.header("Content-Type");
responseBuilder.body(new RealResponseBody(contentType, -1L, Okio.buffer(responseBody)));
}
//返回最后处理好的Response,retryAndFollowUpInterceptor就是根据此结果
//判断是否要重试。
return responseBuilder.build();
}
2.2 工作原理
BridgeInterceptor原理:对用户传入的请求做处理,在程序员编写代码时只需要指定Url和请求体,但是事实上,一个完整的请求报文远不止这些信息,BridgeInterceptor帮我们做了这些事,添加各种请求报文所需要的字段,然后再传递给下一个拦截器去执行。对于得到的返回结果Response,其内容可能经过了Gzip压缩,所以BridgeInterceptor帮我们做了解压缩。
这像极了爱情!!!
3.CacheInterceptor
CacheInterceptor的的作用就是缓存网络请求,注意只能缓存GET类型的请求。他是怎么实现缓存的呢?看一下源码一探究竟。
3.1 源码解析
@Override
public Response intercept(Chain chain) throws IOException {
//cache是构建缓存拦截器时指定的
//根据Request的url判断是否有缓存
Response cacheCandidate = cache != null
? cache.get(chain.request())
: null;
long now = System.currentTimeMillis();
//缓存策略,会有详细介绍
//当有请求到达时,需要判断该请求是否有缓存,该缓存是否可用,依次构建策略
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
//如果networkRequest==null,就调用缓存
Request networkRequest = strategy.networkRequest;
//如果cacheResponse==null,就是用网络请求
Response cacheResponse = strategy.cacheResponse;
//如果两者都为null,则返回fail
if (cache != null) {
//这里的cache是在我们创建OkhttpClient时指定的
cache.trackResponse(strategy);
}
if (cacheCandidate != null && cacheResponse == null) {
//如果有缓存,但是缓存不可用,关闭
closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
}
// If we're forbidden from using the network and the cache is insufficient, fail.
if (networkRequest == null && cacheResponse == null) {
//如果网络不可用并且缓存不可用,直接返回失败
return new Response.Builder()
.request(chain.request())
.protocol(Protocol.HTTP_1_1)
.code(504)
.message("Unsatisfiable Request (only-if-cached)")
.body(Util.EMPTY_RESPONSE)
.sentRequestAtMillis(-1L)
.receivedResponseAtMillis(System.currentTimeMillis())
.build();
}
// If we don't need the network, we're done.
if (networkRequest == null) {
//如果不需要网络,缓存可用,返回缓存
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
//到了这一步,说明网络可用,并且没有可用的缓存
Response networkResponse = null;
try {
//调用下一个拦截器获取Response
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) {
closeQuietly(cacheCandidate.body());
}
}
// If we have a cache response too, then we're doing a conditional get.
if (cacheResponse != null) {
//如果该请求之前有缓存
if (networkResponse.code() == HTTP_NOT_MODIFIED) {
// 说明缓存还是有效的,则合并网络响应和缓存结果。同时更新缓存;
//并且从网络请求得到的response的响应码,更新缓存
Response response = cacheResponse.newBuilder()
.headers(combine(cacheResponse.headers(), networkResponse.headers()))
.sentRequestAtMillis(networkResponse.sentRequestAtMillis())
.receivedResponseAtMillis(networkResponse.receivedResponseAtMillis())
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
networkResponse.body().close();
// Update the cache after combining headers but before stripping the
// Content-Encoding header (as performed by initContentStream()).
cache.trackConditionalCacheHit();//更新命中率等一些操作
cache.update(cacheResponse, response);//更新缓存
return response;//返回结果
} else {
closeQuietly(cacheResponse.body());
}
}
Response response = networkResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.networkResponse(stripBody(networkResponse))
.build();
if (cache != null) {
if (HttpHeaders.hasBody(response) && CacheStrategy.isCacheable(response, networkRequest)) {
// Offer this request to the cache.
CacheRequest cacheRequest = cache.put(response);
//这一步是真正的向缓存中添加Response
return cacheWritingResponse(cacheRequest, response);
}
if (HttpMethod.invalidatesCache(networkRequest.method())) {
try {
cache.remove(networkRequest);
} catch (IOException ignored) {
// The cache cannot be written.
}
}
}
return response;
}
CacheInterceptor的源码有点乱,需要多看几遍,这里在说一下缓存策略以及缓存的存取
缓存策略作用的描述
Given a request and cached response,
this figures out whether to use the network, the cache, or both.
给定一个请求和缓存的Response
,他能够帮助我们决定是否使用网络,使用缓存或者都是。
重要代码展示:如何通过传入请求和缓存得到策略的
private CacheStrategy getCandidate() {
// No cached response.
if (cacheResponse == null) {
//如果没有缓存,则进行网络请求
return new CacheStrategy(request, null);
}
// Drop the cached response if it's missing a required handshake.
if (request.isHttps() && cacheResponse.handshake() == null) {
//如果是https请求并且握手信息丢失,也需要进行网络请求
return new CacheStrategy(request, null);
}
// If this response shouldn't have been stored, it should never be used
// as a response source. This check should be redundant as long as the
// persistence store is well-behaved and the rules are constant.
if (!isCacheable(cacheResponse, request)) {
//判断请求是否可以被缓存,如果不可以,直接使用网络
return new CacheStrategy(request, null);
}
CacheControl requestCaching = request.cacheControl();
if (requestCaching.noCache() || hasConditions(request)) {
return new CacheStrategy(request, null);
}
CacheControl responseCaching = cacheResponse.cacheControl();
//从这里开始
long ageMillis = cacheResponseAge();
long freshMillis = computeFreshnessLifetime();
if (requestCaching.maxAgeSeconds() != -1) {
freshMillis = Math.min(freshMillis, SECONDS.toMillis(requestCaching.maxAgeSeconds()));
}
long minFreshMillis = 0;
if (requestCaching.minFreshSeconds() != -1) {
minFreshMillis = SECONDS.toMillis(requestCaching.minFreshSeconds());
}
long maxStaleMillis = 0;
if (!responseCaching.mustRevalidate() && requestCaching.maxStaleSeconds() != -1) {
maxStaleMillis = SECONDS.toMillis(requestCaching.maxStaleSeconds());
}
//到这里结束,就是为了判断缓存是否过期,具体细节无需要关注。
if (!responseCaching.noCache() && ageMillis + minFreshMillis < freshMillis + maxStaleMillis) {
Response.Builder builder = cacheResponse.newBuilder();
if (ageMillis + minFreshMillis >= freshMillis) {
builder.addHeader("Warning", "110 HttpURLConnection \"Response is stale\"");
}
long oneDayMillis = 24 * 60 * 60 * 1000L;
if (ageMillis > oneDayMillis && isFreshnessLifetimeHeuristic()) {
builder.addHeader("Warning", "113 HttpURLConnection \"Heuristic expiration\"");
}
return new CacheStrategy(null, builder.build());
}
// Find a condition to add to the request. If the condition is satisfied, the response body
// will not be transmitted.
//流程走到这,说明缓存已经过期了
//添加请求头:If-Modified-Since或者If-None-Match
//etag与If-None-Match配合使用
//lastModified与If-Modified-Since配合使用
//前者和后者的值是相同的
//区别在于前者是响应头,后者是请求头。
//后者用于服务器进行资源比对,看看是资源是否改变了。
// 如果没有,则本地的资源虽过期还是可以用的
String conditionValue;
if (etag != null) {
//默认是null的
conditionName = "If-None-Match";
conditionValue = etag;
} else if (lastModified != null) {
//The last modified date of the cached response, if known.
conditionName = "If-Modified-Since";
conditionValue = lastModifiedString;
} else if (servedDate != null) {
conditionName = "If-Modified-Since";
conditionValue = servedDateString;
} else {
return new CacheStrategy(request, null); // No condition! Make a regular request.
}
Headers.Builder conditionalRequestHeaders = request.headers().newBuilder();
Internal.instance.addLenient(conditionalRequestHeaders, conditionName, conditionValue);
Request conditionalRequest = request.newBuilder()
.headers(conditionalRequestHeaders.build())
.build();
return new CacheStrategy(conditionalRequest, cacheResponse);
}
缓存策略并不复杂,还有缓存的存取采用的是DiskLru
,根据url
的md5
的hex
值作为键去存取,想要深入的可以看一下DiskLruCahce的源码。
3.2 工作原理
原理:底层是基于DiskLruCache,对于一个请求,
1.没有缓存,直接网络请求;
2.如果是https,但没有握手,直接网络请求;
3.不可缓存,直接网络请求;
4.请求头nocache或者请求头包含If-Modified-Since或者If-None-Match,则需要服务器验证本地缓存是不是还能继续使用,直接网络请求;
5.可缓存,并且ageMillis + minFreshMillis < freshMillis + maxStaleMillis(意味着虽过期,但可用,只是会在响应头添加warning),则使用缓存;
6.缓存已经过期,添加请求头:If-Modified-Since或者If-None-Match,进行网络请求;
4.总结
剩下两个拦截器会在下一篇博客讲解,最后还会有个对Okhttp总体的整理和相关的面试题!
先别走,我有一个资源学习群要推荐给你,它是白嫖党的乐园,小白的天堂!
别再犹豫,一起来学习!