概览
这个拦截器的作用是缓存，整体的流程都是围绕一个叫缓存策略来的，其中里面有两个重要的参数networkRequest和cacheResponse这两个代表了网络和缓存，通过判断两个参数是否为null来执行网络请求和缓存的策略。
看源码
public final class CacheInterceptor implements Interceptor {
final @Nullable InternalCache cache;//代码4
@Override public Response intercept(Chain chain) throws IOException {
Response cacheCandidate = cache != null//代码1
? cache.get(chain.request())
: null;
...
}
...
}
这段源码展示了获取当前存在的缓存，代码1的意思是需要看看当前有没有配置缓存，缓存的配置是程序员自己配的，具体的方法如下：
new OkHttpClient.Builder().cache(new Cache(new File("xxx/yyy"),1024));
Okhttp.Cache到底是用文件还是用数据库或是用其他什么东东做缓存的呢？我们进去看看
public final class Cache implements Closeable, Flushable {//代码3
...
@Nullable CacheRequest put(Response response) {
...
DiskLruCache.Editor editor = null;//代码2
try {
editor = cache.edit(key(response.request().url()));
if (editor == null) {
return null;
}
entry.writeTo(editor);
return new CacheRequestImpl(editor);
} catch (IOException e) {
abortQuietly(editor);
return null;
}
...
}
...
}
看到代码2这里的DiskLruCache实锤了，使用的是文件做的存储。那如果要自定义缓存怎么办，首先，不能继承Cache，不信你看代码3Cache被定义成了final类，无法被继承。如果有需要可以继续加一个拦截器，将数据在拦截器中处理。
等等，代码4中的类好像不是Cache吧？！没错，我们看看源码究竟做了啥，下面这段代码是用来生成InternalCache的
public class OkHttpClient implements Cloneable, Call.Factory, WebSocket.Factory {
...
@Nullable InternalCache internalCache() {
return cache != null ? cache.internalCache : internalCache;//代码5
}
...
}
public final class Cache implements Closeable, Flushable {
private static final int VERSION = 201105;
private static final int ENTRY_METADATA = 0;
private static final int ENTRY_BODY = 1;
private static final int ENTRY_COUNT = 2;
final InternalCache internalCache = new InternalCache() {//代码6
@Override public @Nullable Response get(Request request) throws IOException {
return Cache.this.get(request);
}
@Override public @Nullable CacheRequest put(Response response) throws IOException {
return Cache.this.put(response);
}
@Override public void remove(Request request) throws IOException {
Cache.this.remove(request);
}
@Override public void update(Response cached, Response network) {
Cache.this.update(cached, network);
}
@Override public void trackConditionalCacheHit() {
Cache.this.trackConditionalCacheHit();
}
@Override public void trackResponse(CacheStrategy cacheStrategy) {
Cache.this.trackResponse(cacheStrategy);
}
};
...
}
代码流向:代码5->代码6，这里做的事情就是新增了一个InternalCache实例，然后将里面的get、put、等方法的实现交给当前cache的实例Cache.this实现，看到这我感受到了okhttp开发团队那深深地不想让你去继承Cache类而自定义缓存方式地恶意，你看，他们宁愿用这种方式去折腾也不愿意把Cache旁边的final关键字拿掉。。。这意味着你根本不可能用数据库来存储缓存。
再往下看
public final class CacheInterceptor implements Interceptor {
@Override public Response intercept(Chain chain) throws IOException {
...
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();
Request networkRequest = strategy.networkRequest;
Response cacheResponse = strategy.cacheResponse;
...
}
}
这段代码中，两个关键人物登场了
networkRequest：发起网络请求数据
cacheResponse：使用本地的缓存
这两个的值直接决定了缓存策略最终会怎么去实际地执行，看下表
| networkRequest | cacheResponse | 说明 |
|---|---|---|
| Null | Not Null | 直接使用缓存 |
| Not Null | Null | 向服务器发起请求 |
| Null | Null | 即不去网络请求，也不去拿缓存数据，okhttp直接报错并返回504 |
| Not Null | Not Null | 发起请求，若得到响应为304(无修改)，则更新缓存响应并返回 |
总结起来就一句话：要是只有缓存就不去请求网络，要是只有网络就不读缓存，如果两个都有就先网络后更新掉缓存，保证缓存最新然后返回。
这里只要有个印象，接下来我们继续往下走
public final class CacheInterceptor implements Interceptor {
Response cacheCandidate = cache != null
? cache.get(chain.request())
: null;
...
CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate)//代码8
.get();//代码10
Response cacheResponse = strategy.cacheResponse;
...
@Override public Response intercept(Chain chain) throws IOException {
...
if (cacheCandidate != null && cacheResponse == null) {//代码7
closeQuietly(cacheCandidate.body()); // The cache candidate wasn't applicable. Close it.
}
...
}
...
}
代码7中做了两个判空地判断，等等，容我看下代码8中的构造方法
public Factory(long nowMillis, Request request, Response cacheResponse) {
this.nowMillis = nowMillis;
this.request = request;
this.cacheResponse = cacheResponse;//代码9
...
}
代码流向：代码8->代码9，这两个代码不是实锤了cacheCandidate == cacheResponse 吗？那你这代码7搞两个判断有什么意义？两个不都是一样的吗？
老话说的好，事出反常必有妖
代码10里面一定做了其他的事情，我们跟进去康康
public final class CacheStrategy {
...
CacheStrategy(Request networkRequest, Response cacheResponse) {//代码13
this.networkRequest = networkRequest;
this.cacheResponse = cacheResponse;
}
...
public CacheStrategy get() {
CacheStrategy candidate = getCandidate();//代码11
if (candidate.networkRequest != null && request.cacheControl().onlyIfCached()) {
// We're forbidden from using the network and the cache is insufficient.
return new CacheStrategy(null, null);
}
return candidate;
}
private CacheStrategy getCandidate() {//代码12
// 你传过来的cacheCandidate参数本身就是null，所以我只能给你null
if (cacheResponse == null) {
return new CacheStrategy(request, null);
}
// 如果是https的请求，但是你之前缓存的Response没有握手的信息，
//那你这连接之前压根就没建立啊（握手信息也有可能是被okhttp给处理了），所以返回null
if (request.isHttps() && cacheResponse.handshake() == null) {
return new CacheStrategy(request, null);
}
// 做了一堆返回状态码的判断，
//一些特殊的返回状态码它就不让你去进行缓存，
// 允许你进行缓存的状态码，还得去看看请求或响应的header中Cache-Control请求头里是不是都没有no-store，
if (!isCacheable(cacheResponse, request)) {
return new CacheStrategy(request, null);
}
CacheControl requestCaching = request.cacheControl();
//用户自定义为noCache不让缓存
//请求头If-Modified-Since 或请求头If-None-Match对应的值不为空
//满足上述任意一种cacheCandidate == null
if (requestCaching.noCache() || hasConditions(request)) {
return new CacheStrategy(request, null);
}
CacheControl responseCaching = cacheResponse.cacheControl();
//这里开始其实就是判断缓存是否在有效期内，
//如果在有效期内：cacheCandidate != null newWorkRequest == null，只使用缓存
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.
//走到这里说明缓存是过期的，下面是缓存的过期处理
String conditionName;
String conditionValue;
if (etag != null) {//代码14
conditionName = "If-None-Match";//代码15
conditionValue = etag;//代码16
} else if (lastModified != null) {//代码17~
conditionName = "If-Modified-Since";
conditionValue = lastModifiedString;
} else if (servedDate != null) {
conditionName = "If-Modified-Since";
conditionValue = servedDateString;//~代码18
} 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);
}
}
代码流向：代码11->代码12，代码12返回的是CacheStrategy实体，而从代码13中的构造函数中就直接决定了cacheResponse是否为null，具体的释义见代码注释。
代码流向：代码14->代码15->代码16
代码14中出现了一个etag这个字段的意思是，资源在服务器中的唯一标识，这个标识的作用是资源在服务器列表中变化后etag也会进行改变，客户端捕捉到这种改变后会相应地进行一些操作。
比如，昨天看了新闻列表，服务端把etag=11111返回了，今天再去刷手机的时候必然还要去请求下新闻列表的api，这个时候会把这个etag传给服务器,If-None-Match：11111,服务器一看，不对啊，现在的etag早就变成了22222了，这时候服务端就会返回一个新的新闻列表。假如服务端新闻列表的etag还是11111，那就说明这天压根就没有什么新的新闻动态，于是就返给客户端304（Not Modified）未修改的http状态码回去，然后让客户端进行处理。
代码流向：代码17~->~代码18
这里顺便说明一下If-Modified-Since，这个header的作用是客户端向服务端传递最后一次更改缓存的时间，服务端接收到了这个时间后，会对比下在这个时间以后还有没有做过更改，如果没有做过更改就返回304，否则就返回更新过的数据。
如果从代码14开始的判断都没有命中，意味着需要请求网络了，所以缓存策略会使得netRequest != null ， cacheResponse == null从而去请求网络获取最新值。
如果命中了，就会修改请求头并发起请求。
缓存策略这一块基本上就是这么点事情，总结一下就是说如果你连基本的使用缓存的条件都不满足（值代码12开始的那一串判断），就乖乖给我走网络，你满足了使用缓存的条件，那我还得看看这个缓存是不是过期了，过期了的话你也得走网络，过期了我还得看看etag和最后修改时间有没有，如果有就加到请求头中，如果都没有就直接执行网络请求。总之就是贼矫情，贼含蓄。
我们继续往下跟代码
public final class CacheInterceptor implements Interceptor {
...
@Override public Response intercept(Chain chain) throws IOException {
...
if (networkRequest == null && cacheResponse == null) {//代码19
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();
}
...
}
...
}
这段代码的判断就是说，你又不要网络请求，又不能拿缓存里的，okhttp当然不卵你，直接给你个504（Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求）
再往下跟
public final class CacheInterceptor implements Interceptor {
...
@Override public Response intercept(Chain chain) throws IOException {
...
if (networkRequest == null) {//代码20
return cacheResponse.newBuilder()
.cacheResponse(stripBody(cacheResponse))
.build();
}
...
}
...
}
代码19中已经判断过了两个都为null就返回，那说明代码20补全后肯定是这样的
if (networkRequest == null && cacheResponse != null)
不然呢，补全后是if (networkRequest == null && cacheResponse == null)? 那不是跟代码19一摸一样吗？那不就走不到这里了吗？
所以说代码20这边的意思是只走缓存，并且责任链不会再往下走了
到这里为止，如果代码还能继续往下走，就表示要交给下一个拦截器得到返回的结果了
public final class CacheInterceptor implements Interceptor {
...
@Override public Response intercept(Chain chain) throws IOException {
...
networkResponse = chain.proceed(networkRequest);//代码21
...
if (cacheResponse != null) {
if (networkResponse.code() == HTTP_NOT_MODIFIED) {//代码22
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);//代码23
return response;
} else {
closeQuietly(cacheResponse.body());
}
}
...
}
...
}
代码21发起请求后会返回请求的结果，走到代码22后有个判断，如果服务器返回304（HTTP_NOT_MODIFIED），那么说明无修改，就执行代码23更新缓存
更新缓存就是将网络请求的数据中的头信息，握手信息，最后更改的信息，etag等信息覆盖到原来的cache中对应的信息中。其中返回的内容是不会被更新的，比如说新闻列表，因为304返回的本来就是无内容的，你把缓存中的内容给覆盖成无内容的，那不就没数据了嘛。
这块更新的内容就不去深挖了，感兴趣的可以看看Cache.update()->Entry.writeTo()这里面的方法
接下来代码继续往下走
public final class CacheInterceptor implements Interceptor {
...
@Override public Response intercept(Chain chain) throws IOException {
...
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);
return cacheWritingResponse(cacheRequest, response);
}
if (HttpMethod.invalidatesCache(networkRequest.method())) {
try {
cache.remove(networkRequest);
} catch (IOException ignored) {
// The cache cannot be written.
}
}
}
...
}
...
}
走到这里之后做的事情就是调用put方法覆盖缓存了，具体看上面的注释
整个缓存拦截器的工作原理大概就是这样，只是进行了浅层的解析，也还有一些问题没有说清楚，比如缓存的有效期定义，以后会慢慢补全，如有错误欢迎留言区留言。