Glide引入http缓存
需求背景
社交圈子， 黄暴图片审核，如果失败，地址指向的图片被替换掉。
服务端在图片返回的header里，带上了缓存有效时间。
思路分析
在url不变的情况下，图片发生了变化，glide是不知道的。
我们需要在图片缓存期结束后，再次发起http请求获取图片数据。
Glide提供了signature()这个函数，让我们可以在url不改的情况下，再次发起新的http请求。
因此，针对每个图片url，我们使用值记录缓存失效次数，在每次缓存过期后+1，让本地缓存失效，达到重新发起网络请求的目的
流程分析
一次图片请求解析的流程如下
图片请求流
url决定了每次是否发起新的请求，因此从url变换的角度，流转图如下
url数据流转
本地数据库存储了白名单地址上，缓存期内所有的url，因此从数据库的变化角度，流转图如下
-
新增、修改
新增、修改数据库
- 查询
- 在第一步录入的时候，需要拿到已有缓存时间判断是否过期、tick
- 在生成signature的时候，需要拿到tick。
- 删除
在定期清理过时记录的任务里，检测到当前时间N天以前就过期的记录
框架分析
核心功能解析
扩展阅读
glide缓存机制
Glide缓存介绍
默认情况下，Glide 会在开始一个新的图片请求之前检查以下多级的缓存：
- 活动资源 (Active Resources) - 现在是否有另一个 View 正在展示这张图片？
- 内存缓存 (Memory cache) - 该图片是否最近被加载过并仍存在于内存中？
- 资源类型（Resource） - 该图片是否之前曾被解码、转换并写入过磁盘缓存？
- 数据来源 (Data) - 构建这个图片的资源是否之前曾被写入过文件缓存？
前两步检查图片是否在内存中，如果是则直接返回图片。后两步则检查图片是否在磁盘上，以便快速但异步地返回图片。
因为磁盘缓存使用的是哈希键，所以并没有一个比较好的方式来简单地删除某个特定url或文件路径对应的所有缓存文件。如果你只允许加载或缓存原始图片的话，问题可能会变得更简单，但因为Glide还会缓存缩略图和提供多种变换(transformation)，它们中的任何一个都会导致在缓存中创建一个新的文件，而要跟踪和删除一个图片的所有版本无疑是困难的。
因为通常改变标识符比较困难或者根本不可能，所以Glide也提供了 签名 API 来混合（你可以控制的）额外数据到你的缓存键中。签名(signature)适用于媒体内容，也适用于你可以自行维护的一些版本元数据。
- MediaStore 内容 - 对于媒体存储内容，你可以使用Glide的
MediaStoreSignature类作为你的签名。MediaStoreSignature允许你混入修改时间、MIME类型，以及item的方向到缓存键中。这三个属性能够可靠地捕获对图片的编辑和更新，这可以允许你缓存媒体存储的缩略图。 - 文件 - 你可以使用
ObjectKey来混入文件的修改日期。 - Url - 尽管最好的让 url 失效的办法是让 server 保证在内容变更时对URL做出改变，你仍然可以使用
ObjectKey来混入任意数据（比如版本号）
磁盘缓存策略（Disk Cache Strategy）
DiskCacheStrategy 可被 diskCacheStrategy 方法应用到每一个单独的请求。 目前支持的策略允许你阻止加载过程使用或写入磁盘缓存，选择性地仅缓存无修改的原生数据，或仅缓存变换过的缩略图，或是兼而有之。
默认的策略叫做 AUTOMATIC ，它会尝试对本地和远程图片使用最佳的策略。当你加载远程数据（比如，从URL下载）时，AUTOMATIC 策略仅会存储未被你的加载过程修改过(比如，变换，裁剪–译者注)的原始数据，因为下载远程数据相比调整磁盘上已经存在的数据要昂贵得多。对于本地数据，AUTOMATIC 策略则会仅存储变换过的缩略图，因为即使你需要再次生成另一个尺寸或类型的图片，取回原始数据也很容易。
