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。
优势:
- 可控于每一条缓存的时间,进行单独设定(通常的都是全局的设定,而这可以这条是时效性,那条三个小时,再一条八个小时。。等等)
- 可控于每一条缓存的管理,删除等操作,不单单是时间过期(通常的就是被动的时间过期进行删除,而这可主动进行管理)
- 有网络没网络都访问缓存,通过后台的推送更新缓存进行预加载
- 最大限度上,减轻了服务器的访问压力
- 最大限度上,减少了用户的流量使用
- 让用户感受到了极致加载体验
- 支持不同账号下的缓存
- 支持删除一个接口下的所有缓存
- 添加QucikCache之前动态GIF展示 -添加QucikCache之后动态GIF展示
用法
- AndroidStudio
allprojects {
repositories {
jcenter()
<!--在项目的根gradle下添加如下这行代码-->
maven{url 'https://jitpack.io'}
}
}
<!--项目的gradle下添加-->
compile 'com.github.LiXiangABC:QuickCache:v2.0.1'
1.初始化QucikCache
##### 在 Application 中对 QuickCacheUtil 进行初始化
QuickCacheUtil.getInstance().setContext(getApplication();
2.使用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
QuickCacheUtil.getInstance().LoadingCacheString() 返回的 LoadingCacheStringBean API说明
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
QuickCacheUtil.getCacheManager() 返回的 CacheManager 提供的一些API说明
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原理解析