如何实现一个独立于网络请求框架的缓存（与retrofit无缝衔接

2017-11-01  本文已影响312人  陈文超happylion

转载请注明出处：
如何实现一个独立于网络请求框架的缓存（与retrofit无缝衔接）

地址：http://www.jianshu.com/p/de0ec94ca5c1
目录

1 前言

首先声明，文章中cache-retrofit框架原理部分不是我想出来的。归功于前同事夏恩龙同学。感谢他，散花~ 。我现在维护这个框架，在这个框架上增加了一些功能。因为感觉这个框架还挺不错的。所以讲一下它的原理：怎么实现一个与retrofit的网络请求框架无缝衔接的缓存。这个需要的提出是这样的：猫眼/美团/点评使用的网络请求的client并不一致，猫眼使用的是okhttp，美团/点评使用的是Shark 长连接。长连接自带的缓存机制不是很好用，没有完全实现okhttp的cache-control。所以就需要一个脱离网络请求框架之外的缓存实现，且缓存的使用需要对业务透明（与retrofit类似）。

如果你项目中的retrofit中的callFactory是okhttp client的话，okhttp已经帮我们实现好了cache-control，所以如果我们一直都使用okhttp作为网络请求的client，并且没有那么多的缓存定制需求，那么cache-control这样缓存策略（文件缓存）方式挺好的，但是如果你有一些特殊要求，比如prefer-network，需要知道获取的数据源来自网络或本地（当你cache-control的参数为时间段时，不能确定数据来源），已经不再使用okhttp（采用长连接）等，这些时候你就不得不自己实现一套缓存来解决以上问题。

2 okhttp自带的文件缓存

我们先看下cache-control的策略，这样对之后的缓存参数替换、cache-cotrol的优缺点都有一定帮助。

2.1 cache-control缓存

cache-control 传入的参数为：force-network，force-cache，或一个时间段。意义为：如果传入的是force-network，那么就从网络中加载，然后更新本地相应url的缓存，更新改缓存的时间戳。如果force-cache，那么就使用本地。如果是一个时间段，那么会把当前请求的时间和请求url对应缓存的时间戳做差值，如果差值大于cache-control的时间段，那么就进行网络请求，更新同上，如果小于时间段，那么就走本地。

这种cache-control的方式管理缓存的方式的优点是，使用一个参数就可以区分缓存是否过期/使用网络/使用本地。

同样这样带来一些小问题：

2.2 使用okhttp自带缓存存在的问题

通过前面的分析，我们的缓存最好对业务透明，也就是说仍然使用retrofit网络请求的api service 接口，只是多传入两个参数。缓存需要与retrofit的callfactory隔离。这样在替换call factory时，缓存逻辑不需要任何改变。即，我们的目标是实现一个带缓存的retrofit。

3 怎么实现一个带缓存的retrofit

3.1 与retrofit相比，带缓存的retrofit的使用区别

关于缓存策略，前面指出了，需要两个参数：loadPolicy，cacheTime。 loadPolicy相比cache-control增加了prefer-network。

3.2 内部如何实现-动态代理

既然为了上层业务使用透明，数据请求api 还是采用retrofit的接口形式。那么就需要和
retrofit一样，使用动态代理方式来代理api service 接口。
在数据请求时，多传递一个loadPocily和cacheTime。在动态代理中，先根据loadPocily和cacheTime来决定使用网络还是使用cache，如果使用本地，那么直接从本地DiskLruCache获取序列化数据，然后使用反序列化工具（比如序列化字符串->Gson.fromJson（）->T）生成反序列化对象返回。如果使用网络，那么使用retrofit代理来执行真正的网络请求，因为retrofit内部已经完成了反序列化工作(序列化字符串->GsonConverterFactory.responseBodyConverter()->gson.fromJson()->T)，所以得到的是反序列对象，把该对象序列化后，存入disLruCache中。
注意，DiskLruCache中存储的字符串是retrofit已经生成好的对象简单的进行fromJson/toGson,所以对于某个model，DiskLruCache的序列化和后台返回的序列化字符串可能不一样。因为后台的json字符串需要经过GsonConverterFactory.responseBodyConverter()->gson.fromJson()才能进行转换成对象。GsonConverterFactory.responseBodyConverter()中可以对后台的json字符串做处理（比如去掉一层括号），gson也可以添加自定义的jsonAdapter来解析某个json字符串，这样才生成最终的model对象。将这个model对象直接序列化后的字符串很可能与后台的json字符串不一样。当然这样不影响使用，因为缓存里的是不是后台的gson字符串无所谓，能反序列化成想要的对象即可。

3.3 大致代码

获取api service的接口类T的Class类型，传入ache-retrofit中，返回api service的接口类T的代理类：

 Class<T> service=T.class
 T cachedRetrofit=cacheNet.create(service);

业务中，使用cachedRetrofit调用api service的接口方法

Observable result=cachedRetrofit.getHotCommentKeyList(...)

cache-retrofit实现（在txt中手打的，排版丑，莫笑，哈哈）:

    T cachedRetrofit= 
    (T)Proxy.newProxyInstance(service.getClassLoader(), new Class[]{service}, new InvocationHandler(){
  
 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
 
 //使用缓存
 loadRecord();
 ...
 //需要网络加载
 T serviceProxy=retrofit.create（service）
  Observable result =method.invoke(serviceProxy,args).onErrorResumeNext(loadExpiredRecord()).doOnNext(saveData());//保存数据
  ...
  return serviceProxy;
  ...
 
 }
}
）;

3.4 实现时注意问题：loadPolicy，cacheTime参数传递到哪里？

使用动态代理时，注意一个问题。从上面的代码，可以看到，代理的参数method和args会直接给到retrofit的代理进行反射调用。所以api service接口的方法参数中不能含有loadPolicy，cacheTime参数（因为如果pi service接口的方法参数中含有这两个参数，那么retrofit的代理反射调用method时，method中就会含有loadPolicy，cacheTime参数。这样肯定是不对的。那可不可以通过loadPolicy，cacheTime参数分析完使用哪种方式加载后，然后将这两个参数从method中删掉，然后再给retrofit的代理使用？不可以，因为Method中没有removeParam的api）。所以，既然不能把loadPolicy，cacheTime参数添加到api service接口方法中，那么loadPolicy，cacheTime只能作为生成接口代理的参数的一部分。

如果需要使用接口隔离，接口可以大致写成：

  Interface ICacheNet{
  
    T serviceProxy create（String loadPolicy，String cacheTime,Class<T> service）
    
  }

这样的话，如果需要使用cacheRetrofit，那么传入三个参数即可。如果仍然使用retrofit，那么前两个参数传入不处理即可。所以对于服务来说，尽量使用接口隔离把，因为你不知道什么时候就需要你进行服务替换。

大致的思路就是这样的，当然除了以上这些，还需要添加序列/反序列化时的处理逻辑、DiskLruCache逻辑、key逻辑（method+args+自定义key参数），当然上面提到的“如何判断使用缓存还是网络”也需要进一步的具体化。不过核心的东西就是以上这些。

上一篇下一篇

猜你喜欢

热点阅读