缓存和生命周期是 Glide 的精华。
一、资源封装
Glide 总共有三级缓存，分别是：
活动缓存
LRU 内存缓存
磁盘缓存
整个资源的获取流程是比较复杂的，一张图来说就是这样：
具体而言就是：
加载图片的时候，首先从活动缓存中获取，如果没有，则去LRU 内存缓存中获取
如果LRU内存缓存中有的话，则将图片剪切（图片从内存缓存中移动到活动缓存中，LRU内存缓存自己就没有了）到活动缓存并且使用
如果 LRU 内存中没有的话，则会请求网络，请求成功后保存到磁盘缓存中，并且复制一份到活动缓存供马上使用
当监听到生命周期执行 onDestroy （非 Application 生命周期情况下利用空白 Fragment 监听），则会将活动缓存中的图片移入LRU内存缓存中
注意，LRU 内存缓存和 磁盘缓存都采用了 LRU 算法存储图片
资源封装
Glide 的资源封装，是将图片 url 作为 key（需要处理下，比如是用sh256处理） ，Bitmap 作为 Value
活动缓存（ActiveCache.java）
提到缓存，肯定就涉及到：容器、put 、get 这三个
活动缓存的容器就使用一个 普通的 HashMap 即可，因为只需要存储目前正在使用的图片，其中key 为 处理过的 url ，value 为封装的 Bitmap 即可。同时各个元素添加进来的时候实现接口 callback ，方便在生命周期变化的时候回收和移动封装的 Bitmap 。
内存缓存(MemoryCache.java)
LRUCache 的实现中，sizeOf 默认是返回 1 ，意味着，默认情况下每个元素的大小是 1 不是实际的图片大小。所以在 MemoryCache.java （继承了 LRUCache 类）需要重写其 sizeOf 方法。
Android 获取 Bitmap 的大小
在最开始的时候，使用 Bitmap.getRowBytes ，这个方法最终是在 native 层实现的。到了 API 12 也就是 3.0 的时候，开始更改方法，变成了 Bitmap.getByteCount() ，它是在 Java 层实现的。到了 API 19 也就是 4.4 的时候，又变成了 Bitmap.getAllocationByteCount 了，又放到 Native 层实现了。
说一下，为什么我们设计的时候，需要将 url 进行处理后才能作为key ？这是因为我们磁盘存储文件的时候，命名不能包含斜杠和冒号等内容，会直接报错的的
