QuickCache缓存原理解析

QuickCache前序

在写QuickCache之前,我也进行了诸多的思考和考量，更多的出发点是源于，到底有没有自己写QuickCache的必要性，于是我于是我查阅和研究了当前市面的所成型的缓存部分的技术，发现，还是有自己写一个的必要性，原因基于以下几点：

首先关于访问网络的请求，我本身在项目中所用的是okHttp，如果用ok的缓存机制，那就是用其拦截器进行缓存的相关操作;但是其本身只支持get访问的网络缓存，并不支持post访问的网络缓存,在使用该拦截器去执行POST请求的时候，会发现，即使在log中看到了读取缓存，但是实际上缓存目录里什么都没有。实际上是因为get请求一般较为持久，而post需要携带参数，会经常改动，所以没必要缓存，这个机制从Okhttp的源码里也可以看到：

//Cache类的put方法
private CacheRequest put(Response response) throws IOException {
String requestMethod = response.request().method();

if (HttpMethod.invalidatesCache(response.request().method())) {
try {
remove(response.request());
} catch (IOException ignored) {
}
return null;
}
//如果请求方式不用get，就直接跳过了
if (!requestMethod.equals("GET")) {
return null;
}
//省略代码
}

现在有非常成熟的本地缓存操作框架DisLruCache，我也思考过用这个，但发现还是满足不了需求，原因是：

DisLruCache其中并没有支持对不同账号下的数据进行缓存，不同账号下，相同的接口和请求参数返回的数据可能是不同的。

DisLruCache 并没有对key进行别名设置的方法，当没有别名的情况下，在其他地方想对这一条缓存进行操作的话，可能便利性不是那么的高，复杂度和代码的冗余量也会有所增加。

DisLruCache缓存在本地硬盘中，并没有对不同接口的缓存做目录区分，例如在listView或recyclerView等有分页缓存的情况下，当某页的某一条目被进行了删除操作，那么后面页缓存的数据与当前数据会有错位的情况，所以需要将当前所以缓存页进行清空重新获取，而DisLruCache实现起来同样复杂度也还是比较高

所以基于以上的考虑，于是就自己写了QuickCache。

gitHub（内含的Readme有相关调用的API文档）

优势：

- 可控于每一条缓存的时间，进行单独设定（通常的都是全局的设定，而这可以这条是时效性，那条三个小时，再一条八个小时。。等等）

- 可控于每一条缓存的管理，删除等操作，不单单是时间过期（通常的就是被动的时间过期进行删除，而这可主动进行管理）

- 有网络没网络都访问缓存，通过后台的推送更新缓存进行预加载

- 最大限度上，减轻了服务器的访问压力

- 最大限度上，减少了用户的流量使用

- 让用户感受到了极致加载体验

- 支持不同账号下的缓存

- 支持删除一个接口下的所有缓存

添加QucikCache之前动态GIF展示　　　　　　-添加QucikCache之后动态GIF展示

用法

AndroidStudio

allprojects {
repositories {
jcenter()
<!--在项目的根gradle下添加如下这行代码-->
maven{url 'https://jitpack.io'}
}
}

<!--项目的gradle下添加-->
compile 'com.github.LiXiangABC:QuickCache:v2.0.1'

１.初始化QucikCache

##### 在　Application　中对　QuickCacheUtil　进行初始化

QuickCacheUtil.getInstance().setContext(getApplication();

２.使用QucikCache

示例：

<!--设置请求参数-->
LinkedHashMap<String, String> mLinkedHashMap = new LinkedHashMap<String, String>();
mLinkedHashMap.put("ordercode", getArguments().getString("ordercode"));

<!--调用LoadingCacheString()方法进行相关参数的设定-->
QuickCacheUtil.getInstance().LoadingCacheString()
.setTag(this)
.setAlias(NetWorkURLBean.QUEUE_ORDER_INFO + getArguments().getString("ordercode"))
.setRequestType(QuickCacheUtil.RequestType.post)
.setUrl(NetWorkURLBean.QUEUE_ORDER_INFO)
.setParams(mLinkedHashMap)
.setIsOpenNetWork(true)
.setIsRefreshCache(false)
.setOrc(new onResponseCacheListener() {
@Override
public void onResponseCache(String onResponseData) {
<!--在此执行获取到数据 onResponseData 的后续操作-->
}
}
).commit();

1.请求用到的API

[b]QuickCacheUtil.getInstance().LoadingCacheString() 返回的 LoadingCacheStringBean API说明[/b]

API	描述
setTag(Object tag)	为当前的请求设定一个标记，当展示页面被关闭，就会依据Tag取消当前网络请求，防止内存泄漏。
setAlias(String alias)	为当前的请求设定一个别名，通过别名可以在内存或者本地硬盘中找到这条CacheItem。
setValidTime(int validTime)	为当前请求获取到的数据设定有效期时间(1=1min; 默认为8*60 -> 8个小时)
setRequestType(QuickCacheUtil.RequestType requestType)	为请求设定请求类型，QuickCacheUtil.RequestType为枚举，有四种枚举类型：post,get,put,delete。
setUrl(String url)	URL地址
setParams(Map

2.对内存管理用到的一些API

[b]QuickCacheUtil.getCacheManager() 返回的 CacheManager 提供的一些API说明[/b]

API	描述
setCacheMapLength(int length)	设定内存中存储的最大CacheItem数量，默认值为1000。
setCacheMapSize(int size)	设定对内存占用的MaxSize，默认值为内存的1/16。
setlocalSize(int size)	设定本地的缓存区域大小，默认为10M，1=1M。

QuickCache内部结构UML原理解析

由于CSDN本身不支持UML中的一些功能，为了能够更好的展示清楚逻辑，放在了有道云上；【点击查看】—>QuickCache内部结构UML原理解析

QuickCache中ThreadTheTaskScheduler轮询原理与代码封装

QuickCache读取缓存的实现逻辑UML原理解析

由于CSDN本身不支持UML中的一些功能，为了能够更好的展示清楚逻辑，放在了有道云上；【点击查看】—>QuickCache读取缓存的实现逻辑UML原理解析