QuickCache缓存原理解析

QuickCache前序

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

1. 首先关于访问网络的请求，我本身在项目中所用的是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;    }    //省略代码  }

1. 现在有非常成熟的本地缓存操作框架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原理解析

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

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

---

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

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