OkHttp深入理解（3）BridgeInterceptor与CacheInterceptor

上一篇笔记主要记录了RetryAndFollowUpInterceptor的功能，主要负责根据response决定是否对请求进行重定向。这篇笔记记录链中的下两个结点BridgeInterceptor与CacheInterceptor。

---

BridgeInterceptor

BridgeInterceptor负责在request阶段对请求头添加一些字段，在response阶段对响应进行一些gzip解压操作。

Request阶段

在Request阶段，BridgeInterceptor主要做了添加请求首部字段的操作。具体如下：

RequestBody body = userRequest.body();    if (body != null) {      MediaType contentType = body.contentType();      if (contentType != null) {        requestBuilder.header("Content-Type", contentType.toString());      }      long contentLength = body.contentLength();      if (contentLength != -1) {        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) {      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;    if (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {      transparentGzip = true;      requestBuilder.header("Accept-Encoding", "gzip");    }    List<Cookie> cookies = cookieJar.loadForRequest(userRequest.url());    if (!cookies.isEmpty()) {      requestBuilder.header("Cookie", cookieHeader(cookies));    }    if (userRequest.header("User-Agent") == null) {      requestBuilder.header("User-Agent", Version.userAgent());    }

各个字段解析如下：

字段名 含义 Content-Type 实体主体的媒体类型 Content-Length 实体主体的大小（单位：字节） Transfer-Encoding 指定报文主体的传输编码方式 Host 客户端指定想访问的http服务器的域名/IP和端口号 Connection 当client和server通信时对于长链接如何进行处理 Accept-Encoding 优先的内容编码 Range 实体的字节范围 Cookie 设置cookies User-Agent HTTP客户端程序的信息

Response阶段

客户端收到response之后，判断是否需要进行gzip解压，然后将response返回。

Gzip是一种流行的文件压缩算法，现在的应用十分广泛，尤其是在Linux平台。当应用Gzip压缩到一个纯文本文件时，效果是非常明显的，大约可以减少70％以上的文件大小。这取决于文件中的内容。

   Response networkResponse = chain.proceed(requestBuilder.build());    HttpHeaders.receiveHeaders(cookieJar, userRequest.url(), networkResponse.headers());    Response.Builder responseBuilder = networkResponse.newBuilder()        .request(userRequest);    if (transparentGzip        && "gzip".equalsIgnoreCase(networkResponse.header("Content-Encoding"))        && HttpHeaders.hasBody(networkResponse)) {        //进行解压      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)));    }    return responseBuilder.build();

要注意的是，返回的response中读取到的request是没有进行BridgeInterceptor中添加header处理的、客户端原始的request。这也是为什么需要使用Response.Builder进行重新构建response的原因

以上就是BridgeInterceptor的大概逻辑。

---

CacheInterceptor

CacheInterceptor负责在request阶段判断是否有缓存，是否需要重新请求。在response阶段负责把response缓存起来。

CacheInterceptor的总体流程大致是：
1. 读取候选缓存（创建Client时可配置）
2. 创建缓存策略（根据头信息，判断强制缓存、对比缓存等策略）
3. 根据策略，不需要网络请求且没有缓存时构建一个状态码为504的Response，提示错误
4. 根据策略，不需要网络请求但存在缓存时，将缓存返回
5. 前面步骤都没返回，则从网络中读取（推进到链中的下一个结点继续执行）
6. 获取到网络返回的networkResponse，如果状态码为304（Not Modified），说明缓存可用，直接返回缓存结果
7. 如果步骤6没有返回，则说明缓存已过期，则根据网络中返回的networkResponse构建response
8. 将网络中返回的Response缓存
9. 返回response

源码解析如下：

public Response intercept(Chain chain) throws IOException {//获取构建Client时设置的cache    Response cacheCandidate = cache != null        ? cache.get(chain.request())        : null;    long now = System.currentTimeMillis();//创建缓存策略    CacheStrategy strategy = new CacheStrategy.Factory(now, chain.request(), cacheCandidate).get();    Request networkRequest = strategy.networkRequest;    Response cacheResponse = strategy.cacheResponse;    if (cache != null) {      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 {      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 = 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);        return cacheWritingResponse(cacheRequest, response);      }      if (HttpMethod.invalidatesCache(networkRequest.method())) {        try {          cache.remove(networkRequest);        } catch (IOException ignored) {          // The cache cannot be written.        }      }    }    return response;  }

源码中有许多注释，大致逻辑还是比较清晰的。但是缓存策略中还有许多细节没有深入了解。等以后有空时再补充。

需要注意的是，OkHttp只提供了针对GET请求的缓存，因为GET请求的参数都放在url中，因此url可以作为唯一标识；而POST请求的参数在RequestBody中，url无法作为唯一标识。如果要实现对POST请求的缓存，需要手动写一个Interceptor。针对POST的缓存，可以通过读取RequestBody中的参数，计算MD5，拼接请求的url作为唯一标识，然后利用Sqlite或者DiskLruCache以文件形式缓存到手机上。