介绍
在上一篇中，我们知道了 Glide 框架的最基本的执行流程，那么只知道基本执行流程，这显然是不够的，我们要深挖 Glide 框架的细节处理原理，比如缓存机制，图片处理等，这一篇我们就一起去探索 Glide 的缓存机制。
Glide 缓存机制可以说是设计的非常完美，考虑的非常周全，下面就以一张表格来说明下 Glide 缓存。
| 缓存类型 | 缓存代表 | 说明 |
|---|---|---|
| 活动缓存 | ActiveResources | 如果当前对应的图片资源是从内存缓存中获取的，那么会将这个图片存储到活动资源中。 |
| 内存缓存 | LruResourceCache | 图片解析完成并最近被加载过，则放入内存中 |
| 磁盘缓存-资源类型 | DiskLruCacheWrapper | 被解码后的图片写入磁盘文件中 |
| 磁盘缓存-原始数据 | DiskLruCacheWrapper | 网络请求成功后将原始数据在磁盘中缓存 |
如果对 Glide 执行流程不明白的可以先看 Android 图片加载框架 Glide 4.9.0 (一) 从源码的角度分析一次最简单的执行流程
在介绍缓存原理之前，先来看一张加载缓存执行顺序，先有个印象。
缓存 key 生成
不管是内存缓存还是磁盘缓存，存储的时候肯定需要一个唯一 key 值，那么 Glide cache key 是怎么生成的？通过上一篇源码加载流程介绍，我们知道在 Engine 的 load 函数中进行对 key 的生成。下面我们就通过代码来看一下。
public class Engine implements EngineJobListener,
MemoryCache.ResourceRemovedListener,
EngineResource.ResourceListener {
…
public synchronized LoadStatus load(
GlideContext glideContext,
Object model,
Key signature,
int width,
int height,
Class<?> resourceClass, Class transcodeClass, Priority priority, DiskCacheStrategy diskCacheStrategy, Map
…
}
…
}
//生成 key
EngineKey buildKey(Object model, Key signature, int width, int height,
Map<Class<?>, Transformation<?>> transformations, Class<?> resourceClass, Class<?> transcodeClass, Options options) {
return new EngineKey(model, signature, width, height, transformations, resourceClass,
transcodeClass, options);
}
复制代码
class EngineKey implements Key {
…
@Override
public boolean equals(Object o) {
if (o instanceof EngineKey) {
EngineKey other = (EngineKey) o;
return model.equals(other.model)
&& signature.equals(other.signature)
&& height == other.height
&& width == other.width
&& transformations.equals(other.transformations)
&& resourceClass.equals(other.resourceClass)
&& transcodeClass.equals(other.transcodeClass)
&& options.equals(other.options);
}
return false;
}
@Override
public int hashCode() {
if (hashCode == 0) {
hashCode = model.hashCode();
hashCode = 31 * hashCode + signature.hashCode();
hashCode = 31 * hashCode + width;
hashCode = 31 * hashCode + height;
hashCode = 31 * hashCode + transformations.hashCode();
hashCode = 31 * hashCode + resourceClass.hashCode();
hashCode = 31 * hashCode + transcodeClass.hashCode();
hashCode = 31 * hashCode + options.hashCode();
}
return hashCode;
}
…
}
复制代码
根据注释和代码可以看到传入的参数之多，主要是根据 url ，签名，宽高等，其内部重写了 hashCode，equals，来保证对象的唯一性。
内存缓存
通过下面代码开启内存缓存，当然 Glide 默认是为我们开启了内存缓存所以不需要我们调用 skipMemoryCache
//在 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);
}
return active;
}
//继承 WeakReference 弱引用，避免内存泄漏。
@VisibleForTesting
static final class ResourceWeakReference extends WeakReference<EngineResource<?>> {
…
}
复制代码
通过上面代码我们知道活动缓存是 Map + WeakReference 来进行维护的，这样做的好处是避免图片资源内存泄漏。
存储活动资源
通过文章开头表格中提到，活动资源是加载内存资源之后存储的，那么我们就来看下何时加载内存资源，看下面代码。
还是在Engine load函数中
//1. 如果活动缓存中没有，就加载 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;
}
// 加载内存中图片资源
private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) { if (!isMemoryCacheable) { return null; } //2\. 拿到内存缓存，内部将当前的 key 缓存 remove 了 EngineResource<?> cached = getEngineResourceFromCache(key);
if (cached != null) {
// 3. 如果内存缓存不为空，则引用计数器 +1
cached.acquire();
//4. 添加进活动缓存中
activeResources.activate(key, cached);
}
return cached;
}
复制代码
通过注释 4 ，我们知道在拿到内存缓存的时候，先将内存缓存的当前 key 删除了，然后添加到活动缓存中。
清理活动资源
通过上一篇 Android 图片加载框架 Glide 4.9.0 (一) 从源码的角度分析一次最简单的执行流程 中得知，我们是在EngineJob中发出的通知回调，告知Engine onResourceReleased来删除 活动资源。下面我们在回顾一下执行流程，那么我们就从 EngineJob 发出通知开始看吧:
class EngineJob implements DecodeJob.Callback,
Poolable {
…
@Override
public void onResourceReady(Resource resource, DataSource dataSource) {
synchronized (this) {
this.resource = resource;
this.dataSource = dataSource;
}
notifyCallbacksOfResult();
}
@Synthetic
void notifyCallbacksOfResult() {
…
//回调上层 Engine 任务完成了
listener.onEngineJobComplete(this, localKey, localResource);
//遍历资源回调给 ImageViewTarget ,并显示
for (final ResourceCallbackAndExecutor entry : copy) {
entry.executor.execute(new CallResourceReady(entry.cb));
}
//这里是通知发出上层删除活动资源数据
decrementPendingCallbacks();
}
…
}
//重要的就是这里了
@Synthetic
synchronized void decrementPendingCallbacks() {
if (decremented == 0) {
if (engineResource != null) {
//如果不为空，那么就调用内部 release 函数
engineResource.release();
}
}
}
复制代码
看一下 EngineResource 的 release 函数
class EngineResource implements Resource {
…
void release() {
synchronized (listener) {
synchronized (this) {
if (acquired <= 0) {
throw new IllegalStateException(“Cannot release a recycled or not yet acquired resource”);
}
//这里每次调用一次 release 内部引用计数法就会减一，到没有引用也就是为 0 的时候 ，就会通知上层
if (–acquired == 0) {
//回调出去，Engine 来接收
listener.onResourceReleased(key, this);
}
}
}
}
…
}
复制代码
根据注释，我们知道这里用了引用计数法，有点像 GC 回收的 引用计数法的影子。也就是说，当完全没有使用这样图片的时候，就会把活动资源清理掉，接着往下看，会调用 Engine 的 onResourceReleased 函数。
public class Engine implements EngineJobListener,
MemoryCache.ResourceRemovedListener,
EngineResource.ResourceListener {
。。。
//接收来自 EngineResource 的调用回调
@Override
public synchronized void onResourceReleased(Key cacheKey, EngineResource<?> resource) {
//1. 收到当前图片没有引用，清理图片资源
activeResources.deactivate(cacheKey);
//2. 如果开启了内存缓存
if (resource.isCacheable()) {
//3. 将缓存存储到内存缓存中。
cache.put(cacheKey, resource);
} else {
resourceRecycler.recycle(resource);
}
}
。。。
}
复制代码
通过上面注释 1 可以知道，这里首先会将缓存图片从 activeResources 中移除，然后再将它 put 到 LruResourceCache 内存缓存当中。这样也就实现了正在使用中的图片使用弱引用来进行缓存，不在使用中的图片使用 LruCache 来进行缓存的功能，设计的真的很巧妙。
LruResourceCache 内存资源
获取内存资源
不知道有没有小伙伴注意到，其实在讲活动资源存储的时候已经涉及到了内存缓存的存储，下面我们在来看一下，具体代码如下:
public class Engine implements EngineJobListener,
MemoryCache.ResourceRemovedListener,
EngineResource.ResourceListener {
…//忽略一些成员变量跟构造函数
public synchronized LoadStatus load(
…//忽略参数
) {
…
//1. 加载内存缓存
EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
if (cached != null) {
//如果内存缓存中有，就通知上层，最后在 SingleRequest 接收
cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey(“Loaded resource from cache”, startTime, key);
}
return null;
}
}
…
}
private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) { if (!isMemoryCacheable) { return null; } //2\. 通过 getEngineResourceFromCache 获取内存资源 EngineResource<?> cached = getEngineResourceFromCache(key);
if (cached != null) {//如果内存资源存在
//则引用计数 +1
cached.acquire();
//3. 将内存资源存入活动资源
activeResources.activate(key, cached);
}
return cached;
}
private EngineResource<?> getEngineResourceFromCache(Key key) { //通过 Engine load 中传参可知，cache 就是 Lru 内存资源缓存 //2.1 这里是通过 remove 删除来拿到缓存资源 Resource<?> cached = cache.remove(key);
final EngineResource<?> result; if (cached == null) { result = null; } else if (cached instanceof EngineResource) { result = (EngineResource<?>) cached;
} else {
result = new EngineResource<>(cached, true /isMemoryCacheable/, true /isRecyclable/);
}
return result;
}
复制代码
通过注释1得知，这里是开始加载内存缓存中的资源；
通过注释2.1 可知，这里通过 Lru 内存缓存的 remove 来拿到内存缓存
最后将内存存储到活动缓存中，并缓存当前找到的内存缓存。
这里的活动缓存跟内存缓存紧密联系在一起，环环相扣，就像之前我们的疑问，为什么 Glide 会设计 2 个内存缓存的原因了。
存储内存资源
通过 EngineResource 的引用计数法机制 release 函数，只要没有引用那么就回调，请看下面代码：
class EngineJob implements DecodeJob.Callback,
Poolable {
…
@Override
public void onResourceReady(Resource resource, DataSource dataSource) {
synchronized (this) {
this.resource = resource;
this.dataSource = dataSource;
}
notifyCallbacksOfResult();
}
@Synthetic
void notifyCallbacksOfResult() {
…
//这里是通知发出上层删除活动资源数据
decrementPendingCallbacks();
}
…
}
//重要的就是这里了
@Synthetic
synchronized void decrementPendingCallbacks() {
if (decremented == 0) {
if (engineResource != null) {
//如果不为空，那么就调用内部 release 函数
engineResource.release();
}
}
}
void release() {
synchronized (listener) {
synchronized (this) {
//引用计数为 0 的时候，回调。
if (–acquired == 0) {
listener.onResourceReleased(key, this);
}
}
}
}
复制代码
最后会回调到 Engine 的 onResourceReleased 函数：
@Override
public synchronized void onResourceReleased(Key cacheKey, EngineResource<?> resource) {
//1. 清理活动缓存
activeResources.deactivate(cacheKey);
//如果开启了内存缓存
if (resource.isCacheable()) {
//2. 清理出来的活动资源，添加进内存缓存
cache.put(cacheKey, resource);
} else {
resourceRecycler.recycle(resource);
}
}
复制代码
到了这里我们知道，在清理活动缓存的时候添加进了内存缓存。
清理内存缓存
这里的清理是在获取内存缓存的时候通过 remove 清理掉的，详细可以看内存缓存获取的方式。
内存缓存小结
通过上面分析可知，内存缓存有活动缓存和内存资源缓存，下面看一个图来总结下它们相互之间是怎么配合交换数据的。
总结下步骤:
- 第一次加载没有获取到活动缓存。
- 接着加载内存资源缓存，先清理掉内存缓存，在添加进行活动缓存。
- 第二次加载活动缓存已经存在。
- 当前图片引用为 0 的时候，清理活动资源，并且添加进内存资源。
- 又回到了第一步，然后就这样环环相扣。
磁盘缓存
在介绍磁盘缓存之前先看一张表格
| 缓存表示 | 说明 |
|---|---|
| DiskCacheStrategy.NONE | 表示不开启磁盘缓存 |
| DiskCacheStrategy.RESOURCE | 表示只缓存转换之后的图片。 |
| DiskCacheStrategy.ALL | 表示既缓存原始图片，也缓存转换过后的图片。 |
| DiskCacheStrategy.DATA | 表示只缓存原始图片 |
| DiskCacheStrategy.AUTOMATIC | 根据数据源自动选择磁盘缓存策略（默认选择） |
上面这 4 中参数其实很好理解，这里有一个概念需要记住，就是当我们使用 Glide 去加载一张图片的时候，Glide 默认并不会将原始图片展示出来，而是会对图片进行压缩和转换，总之就是经过种种一系列操作之后得到的图片，就叫转换过后的图片。而 Glide 默认情况下在硬盘缓存的就是 DiskCacheStrategy.AUTOMATIC
以下面的代码来开启磁盘缓存:
Glide.
with(MainActivity.this.getApplication()).
//使用磁盘资源缓存功能
diskCacheStrategy(DiskCacheStrategy.RESOURCE).
into(imageView);
复制代码
知道了怎么开启，下面我们就来看一下磁盘缓存的的加载与存储。
这 2 个加载流程几乎一模一样，只是加载的数据源不同，下面我们具体来看一下
DiskCacheStrategy.RESOURCE 资源类型
获取资源数据
通过上一篇Glide 加载流程 我们知道，如果在活动缓存、内存缓存中没有找数据，那么就重新开启一个 GlideExecutor 线程池在 DecodeJob run 执行新的请求，下面我们就直接来看 DecodeJob run 函数，跟着它去找 资源数据的加载:
class DecodeJob implements DataFetcherGenerator.FetcherReadyCallback,
Runnable,
Comparable<DecodeJob<?>>,
Poolable {
…
@Override
public void run() {
…
try {
//如果取消就通知加载失败
if (isCancelled) {
notifyFailed();
return;
}
//1. 执行runWrapped
runWrapped();
} catch (CallbackException e) {
…
}
}
…
}
private void runWrapped() {
switch (runReason) {
case INITIALIZE:
//2. 找到执行的状态
stage = getNextStage(Stage.INITIALIZE);
//3. 找到具体执行器
currentGenerator = getNextGenerator();
//4. 开始执行
runGenerators();
break;
…
}
}
private DataFetcherGenerator getNextGenerator() {
switch (stage) {
case RESOURCE_CACHE: //3.1解码后的资源执行器
return new ResourceCacheGenerator(decodeHelper, this);
case DATA_CACHE://原始数据执行器
return new DataCacheGenerator(decodeHelper, this);
case SOURCE://新的请求，http 执行器
return new SourceGenerator(decodeHelper, this);
case FINISHED:
return null;
default:
throw new IllegalStateException("Unrecognized stage: " + stage);
}
}
复制代码
通过上面分析的代码跟注释，我们知道这里是在找具体的执行器，找完了之后注释 4 开始执行，现在我们直接看注释 4。先提一下 注释 3.1 因为外部我们配置的是 RESOURCE 磁盘资源缓存策略，所以直接找到的是 ResourceCacheGenerator 执行器。
private void runGenerators() {
//如果当前任务没有取消，执行器不为空，那么就执行 currentGenerator.startNext() 函数
while (!isCancelled && currentGenerator != null
&& !(isStarted = currentGenerator.startNext())) {
stage = getNextStage(stage);
最后
都说三年是程序员的一个坎，能否晋升或者提高自己的核心竞争力，这几年就十分关键。
技术发展的这么快，从哪些方面开始学习，才能达到高级工程师水平，最后进阶到Android架构师/技术专家？我总结了这 5大块；
我搜集整理过这几年阿里，以及腾讯，字节跳动，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 PDF（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。
Java语言与原理；
大厂，小厂。Android面试先看你熟不熟悉Java语言
高级UI与自定义view；
自定义view，Android开发的基本功。
性能调优；
数据结构算法，设计模式。都是这里面的关键基础和重点需要熟练的。
NDK开发；
未来的方向，高薪必会。
前沿技术；
组件化，热升级，热修复，框架设计
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
我在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多
当然，想要深入学习并掌握这些能力，并不简单。关于如何学习，做程序员这一行什么工作强度大家都懂，但是不管工作多忙，每周也要雷打不动的抽出 2 小时用来学习。
不出半年，你就能看出变化！
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
Java语言
[外链图片转存中…(img-JP55tbcQ-1715108368321)]
高级UI与自定义view；
自定义view，Android开发的基本功。
[外链图片转存中…(img-1MDchRv3-1715108368323)]
性能调优；
数据结构算法，设计模式。都是这里面的关键基础和重点需要熟练的。
[外链图片转存中…(img-NZ2l34sw-1715108368324)]
NDK开发；
未来的方向，高薪必会。
[外链图片转存中…(img-C1NUW8t5-1715108368325)]
前沿技术；
组件化，热升级，热修复，框架设计
[外链图片转存中…(img-kCoUoZ4E-1715108368326)]
网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。
我在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多
当然，想要深入学习并掌握这些能力，并不简单。关于如何学习，做程序员这一行什么工作强度大家都懂，但是不管工作多忙，每周也要雷打不动的抽出 2 小时用来学习。
不出半年，你就能看出变化！
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
8300
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
