使用Retrofit和Okhttp实现网络缓存，更新于2016.02.02

本文使用 Retrofit2.0.0-beta2、Okhttp 2.6.0（Okhttp3.0之后api写法有变化）

• 配置Okhttp的Cache
• 配置请求头中的cache-control或者统一处理所有请求的请求头
• 云端配合设置响应头或者自己写拦截器修改响应头中cache-control

最后实现的效果是：有网的时候根据你每个接口设置的需要缓存的时间（1分钟、5分钟等）进行缓存，过了时间重新请求；没网的时候读缓存。

在这里插一句为什么要做缓存，或者说有什么好处？
减少服务器负荷，降低延迟提升用户体验。复杂的缓存策略会根据用户当前的网络情况采取不同的缓存策略，比如在2g网络很差的情况下，提高缓存使用的时间；不用的应用、业务需求、接口所需要的缓存策略也会不一样，有的要保证数据的实时性，所以不能有缓存，有的你可以缓存5分钟，等等。你要根据具体情况所需数据的时效性情况给出不同的方案。当然你也可以全部都一样的缓存策略，看你自己。

1.配置okhttp中的Cache

OkHttpClient okHttpClient = new OkHttpClient();
File cacheFile = new File(context.getCacheDir(), "[缓存目录]");
Cache cache = new Cache(cacheFile, 1024 * 1024 * 100); //100Mb
okHttpClient.setCache(cache);

2.配置请求头中的cache-control

缓存的相关知识和参数的说明,我是个链接1
缓存的相关知识和参数的说明,我是个链接2

在Retrofit中，我们可以通过@Headers来配置，如：

@Headers("Cache-Control: public, max-age=3600)
@GET("merchants/{shopId}/icon")
Observable<ShopIconEntity> getShopIcon(@Path("shopId") long shopId);

没有设置的可以即为有网的时候不进行缓存。

或者你所有接口在有网的时候都不需要缓存或者都需要缓存且时间一样，那么也不用配置每个接口的@Headers的Cache-Control了。

3.云端配合设置响应头或者自己写拦截器修改响应头response中cache-control

到这一步缓存就已经待在你的缓存目录了。
如果云端有处里cache的话，就已经可以了。
但是很可能云端没有处理，所以返回的响应头中cache-control是no-cache，这时候你还是无法做缓存，大家可以用okhttp的写日志拦截器查看响应头的内容。

[ Okhttp Interceptors 使用说明,我是个链接](https://github.com/square/okhttp/wiki/Interceptors" target="_blank)

如果云端现在不方便处理的话，你也可以自己搞定缓存的，那就是写拦截器修改响应头中的cache-control。我把请求头中的cache-control读出来然后设置到了响应头中。

设置拦截器：
REWRITE_CACHE_CONTROL_INTERCEPTOR拦截器需要同时设置networkInterceptors和interceptors（OKHTTP3.0配置是否有效待我测试）

okHttpClient.interceptors().add(LoggingInterceptor);
okHttpClient.networkInterceptors().add(REWRITE_CACHE_CONTROL_INTERCEPTOR);
okHttpClient.interceptors().add(REWRITE_CACHE_CONTROL_INTERCEPTOR);

拦截器如下：云端响应头拦截器，用来配置缓存策略

/**
 * 云端响应头拦截器，用来配置缓存策略
 * Dangerous interceptor that rewrites the server's cache-control header.
 */
private final Interceptor REWRITE_CACHE_CONTROL_INTERCEPTOR = chain -> {
    Request request = chain.request();
    if(!NetUtils.hasNetwork(context)){
        request = request.newBuilder()
                .cacheControl(CacheControl.FORCE_CACHE)
                .build();
        Logger.t(TAG).w("no network");
    }
    Response originalResponse = chain.proceed(request);
    if(NetUtils.hasNetwork(context)){
        //有网的时候读接口上的@Headers里的配置，你可以在这里进行统一的设置
        String cacheControl = request.cacheControl().toString();
        return originalResponse.newBuilder()
                .header("Cache-Control", cacheControl)
                .removeHeader("Pragma")
                .build();
    }else{
        return originalResponse.newBuilder()
                .header("Cache-Control", "public, only-if-cached, max-stale=2419200")
                .removeHeader("Pragma")
                .build();
    }
};

最后日志拦截器也贴上来吧

private final Interceptor LoggingInterceptor = chain -> { 
    Request request = chain.request(); 
    long t1 = System.nanoTime();
    Logger.t(TAG).i(String.format("Sending request %s on %s%n%s", request.url(),  chain.connection(), request.headers()));
    Response response = chain.proceed(request); 
    long t2 = System.nanoTime(); 
    Logger.t(TAG).i(String.format("Received response for %s in %.1fms%n%s", response.request().url(), (t2 - t1) / 1e6d, response.headers())); 
    return response; 
};

以下测试Cache-Control的配置在请求头和响应头中都有且一样。

max-stale在请求头设置有效，在响应头设置无效。(因为max-stale是请求头设置参数,参考上面的缓存相关的知识第二个链接)
max-stale和max-age同时设置的时候，缓存失效的时间按最长的算。
关于max-age和max-stale我这里做了一个测试：
测试结果：
我在请求头中设置了：Cache-Control: public, max-age=60,max-stale=120,响应头的Cache-Control和请求头一样。

• 在第一次请求数据到一分钟之内，响应头有：Cache-Control: public, max-age=60,max-stale=120
• 在1分钟到3分钟在之间，响应头有：Cache-Control: public, max-age=60,max-stale=120
  Warning: 110 HttpURLConnection "Response is stale"
  可以发现多了一个Warning。
• 三分钟的时候：重新请求了数据，如此循环，如果到了重新请求的节点此时没有网，则请求失败。

另外关于缓存有一个rxcache也可以试试。

感谢@Picasso_L一起讨论研究