深度学习-Android-图片加载框架-Glide-(二)-切入源码层深入分析-Glide-缓存策略(2)

//在 BaseRequestOptions 成员变量中默认为内存缓存开启。
private boolean isCacheable = true;

//调用层调用
Glide.
with(MainActivity.this.getApplication()).
//开启使用内存缓存
skipMemoryCache(true).
into(imageView);
复制代码

现在缓存 key 有了之后，就可以根据 key 拿到对应的缓存了，通过文章开始的介绍，我们知道先加载活动缓存，如果活动缓存没有在加载内存缓存，先看下代码；

public class Engine implements EngineJobListener,
MemoryCache.ResourceRemovedListener,
EngineResource.ResourceListener {

…

public synchronized LoadStatus load(
…//参数
) {
…
//1. 生成缓存唯一 key 值，model 就是图片地址
EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
resourceClass, transcodeClass, options);

//2. 优先加载内存中的活动缓存 - ActiveResources
EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
if (active != null) {
cb.onResourceReady(active, DataSource.MEMORY_CACHE);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey(“Loaded resource from active resources”, startTime, key);
}
return null;
}

//3. 如果活动缓存中没有，就加载 LRU 内存缓存中的资源数据。
EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
if (cached != null) {
cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey(“Loaded resource from cache”, startTime, key);
}
return null;
}

…

}
复制代码

Glide 为什么会设计 2 个内存缓存

不知道大家通过上面代码跟注释(2，3 ) , 有没有发现为什么 Glide 会弄 2 个内存缓存（一个 Map + 弱引用，一个 LRU 内存缓存），大家有没有想过为什么？在看 郭霖大神对 Glide 缓存机制分析 中说道， ActiveResources 就是一个弱引用的 HashMap ，用来缓存正在使用中的图片,使用 ActiveResources 来缓存正在使用中的图片，可以保护这些图片不会被 LruCache 算法回收掉 ，起初当我看见这句话的时候，我是真的很不理解，因为 Lru 是最近最少时候才会回收尾端数据，那么这里的 ActiveResources 来缓存正在使用中的图片，可以保护这些图片不会被 LruCache 算法回收掉 ，我是越想越觉得矛盾，后来中午吃饭的时候，灵光一闪突然想到了一种情况，我也不知道是不是这样，先看下面一张图。

详细举例说明: 比如我们 Lru 内存缓存 size 设置装 99 张图片，在滑动 RecycleView 的时候，如果刚刚滑动到 100 张，那么就会回收掉我们已经加载出来的第一张，这个时候如果返回滑动到第一张，会重新判断是否有内存缓存，如果没有就会重新开一个 Request 请求，很明显这里如果清理掉了第一张图片并不是我们要的效果。所以在从内存缓存中拿到资源数据的时候就主动添加到活动资源中，并且清理掉内存缓存中的资源。这么做很显然好处是 保护不想被回收掉的图片不被 LruCache 算法回收掉,充分利用了资源。 我也不知道这样理解是否正确，希望如果有其它的含义，麻烦告知一下，谢谢 ！

上面我们说到了 Glide 为什么会设计 2 个内存缓存，下面我们就对这 2 个缓存的 存/取/删 来具体说明下。

ActiveResources 活动资源

获取活动资源

通过之前的介绍我们知道，活动缓存是在Engine load中获取

public synchronized LoadStatus load(
…//参数
) {

//1. 优先加载内存中的活动缓存 - ActiveResources
EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
if (active != null) {
// 如果找到获取资源，就返回上层
cb.onResourceReady(active, DataSource.MEMORY_CACHE);
return null;
}
…

}

@Nullable
private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable) { if (!isMemoryCacheable) { return null; } // 通过 活动资源的 get 函数拿到活动资源的缓存 EngineResource<?> active = activeResources.get(key);
if (active != null) {
//正在使用，引用计数 +1
active.acquire();
}

return active;
}

复制代码

继续看 get 的具体实现

final class ActiveResources {

//
@VisibleForTesting
final Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>();
private final ReferenceQueue<EngineResource<?>> resourceReferenceQueue = new ReferenceQueue<>();

…

//外部调用 get 函数拿到活动资源缓存
@Nullable
synchronized EngineResource<?> get(Key key) {
//通过 HashMap + WeakReference 的存储结构
//通过 HashMap 的 get 函数拿到活动缓存
ResourceWeakReference activeRef = activeEngineResources.get(key);
if (activeRef == null) {
return null;
}

EngineResource<?> active = activeRef.get();
if (active == null) {
cleanupActiveReference(activeRef);
}