QuickCache前序
在写QuickCache之前,我也进行了诸多的思考和考量，更多的出发点是源于，到底有没有自己写QuickCache的必要性，于是我于是我查阅和研究了当前市面的所成型的缓存部分的技术，发现，还是有自己写一个的必要性，原因基于以下几点：
首先关于访问网络的请求，我本身在项目中所用的是okHttp，如果用ok的缓存机制，那就是用其拦截器进行缓存的相关操作;但是其本身只支持get访问的网络缓存，并不支持post访问的网络缓存,在使用该拦截器去执行POST请求的时候，会发现，即使在log中看到了读取缓存，但是实际上缓存目录里什么都没有。实际上是因为get请求一般较为持久，而post需要携带参数，会经常改动，所以没必要缓存，这个机制从Okhttp的源码里也可以看到：
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;
}
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
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原理解析
由于本身不支持UML中的一些功能，为了能够更好的展示清楚逻辑，放在了有道云上；【点击查看】—>QuickCache内部结构UML原理解析
QuickCache中ThreadTheTaskScheduler轮询原理与代码封装
QuickCache读取缓存的实现逻辑UML原理解析
由于本身不支持UML中的一些功能，为了能够更好的展示清楚逻辑，放在了有道云上；【点击查看】—>QuickCache读取缓存的实现逻辑UML原理解析
