Glide 4.9源码解析-缓存策略
本文Glide源码基于4.9,版本下载地址如下：Glide 4.9
前言
在分析了Glide的图片加载流程后，更加发觉到Glide的强大，于是这篇文章将继续深入分析Glide的缓存策略。不过今天的文章的源码很多基于上一篇加载流程的基础之上，因此还没有看上一篇的小伙伴，建议先去阅读Glide4.9源码解析-图片加载流程效果会更佳哟！
一、设计
1. 二级缓存
- 内存缓存：基于LruCache和弱引用机制
- 磁盘缓存：基于DiskLruCache进行封装
Glide有几级缓存？对于这个问题，网上的答案不一，有的认为是五级缓存，也有的认为是三级缓存，但我个人认为是二级缓存，因为个人感觉网络加载并不属于缓存（如果有错误，欢迎在评论指出）
2. 缓存策略
内存缓存–>磁盘缓存–>网络加载
Glide的缓存策略大致是这样的：假设同时开启了内存缓存和磁盘缓存，当程序请求获取图片时，首先从内存中获取，如果内存没有就从磁盘中获取，如果磁盘中也没有，那就从网络上获取这张图片。当程序第一次从网络加载图片后，就将图片缓存到内存和磁盘上。
二、流程
1. 生成缓存key
1.1 作用
缓存key是实现内存和磁盘缓存的唯一标识
1.2 原理
重写equals和hashCode方法，来确保只有key对象的唯一性
1.3 源码解析
生成缓存key的地方其实就在于我们上一篇文章提到的过的Engine的load方法中
Engine#load
public synchronized <R> LoadStatus load(GlideContext glideContext,Object model,Key signature,int width,int height,Class<?> resourceClass,Class<R> transcodeClass,Priority priority,DiskCacheStrategy diskCacheStrategy,Map<Class<?>, Transformation<?>> transformations,boolean isTransformationRequired,boolean isScaleOnlyOrNoTransform,Options options,boolean isMemoryCacheable,boolean useUnlimitedSourceExecutorPool,boolean useAnimationPool,boolean onlyRetrieveFromCache,ResourceCallback cb,Executor callbackExecutor) {long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;//创建EngineKey对象EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,resourceClass, transcodeClass, options);......return new LoadStatus(cb, engineJob);}
这里会调用keyFactory的buildkey方法来创建EngineKey对象，并将load传入的数据（String,URL等），图片的宽高，签名，设置参数等传进去。
KeyFactory#buildKey
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);}
可以发现KeyFactory的buildKey方法就是简单的返回了一个EngineKey对象。所以我们来看看这个EngineKey
EngineKey
class EngineKey implements Key {private final Object model;private final int width;private final int height;private final Class<?> resourceClass;private final Class<?> transcodeClass;private final Key signature;private final Map<Class<?>, Transformation<?>> transformations;private final Options options;private int hashCode;EngineKey(Object model,Key signature,int width,int height,Map<Class<?>, Transformation<?>> transformations,Class<?> resourceClass,Class<?> transcodeClass,Options options) {this.model = Preconditions.checkNotNull(model);this.signature = Preconditions.checkNotNull(signature, "Signature must not be null");this.width = width;this.height = height;this.transformations = Preconditions.checkNotNull(transformations);this.resourceClass =Preconditions.checkNotNull(resourceClass, "Resource class must not be null");this.transcodeClass =Preconditions.checkNotNull(transcodeClass, "Transcode class must not be null");this.options = Preconditions.checkNotNull(options);}@Overridepublic 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;}@Overridepublic 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;}....
}你会发现在EngineKey中重写equals和hashcode方法，这样就能确保只有传入EngineKey的所有参数都相同的情况下才认为是同一个EngineKey对象。
2. 内存缓存
2.1 作用
防止应用重复将图片数据读取到内存
2.2 原理
缓存原理：弱引用机制和LruCache算法
弱引用机制：当JVM进行垃圾回收时，无论当前的内存是否足够，都会回收掉弱引用关联的对象
LruCache算法：内部采用LinkedHashMap以强引用的方式存储外界的缓存对象，当缓存满时，LruCache会移除较早使用的缓存对象，然后添加新的缓存对象
缓存实现：正在使用的图片使用弱引用机制进行缓存，不在使用中的图片使用LruCache来进行缓存。
2.3 配置
Glide默认情况下是开启了内存缓存的，即你不需要做任何处理，只需要通过下面代码正常调用Glide的三部曲即可。
Glide.with(getContext()).load(url).into(imageView);
那我们要关闭内存缓存咋整呢？强大的Glide当然思考了这种问题，Glide提供了非常便捷的API，因此我们只需要通过调用来RequestOptions.skipMemoryCacheOf()并传入true，表示跳过内存缓存，即禁用内存缓存。
Glide.with(getContext()).load(url).apply(RequestOptions.skipMemoryCacheOf(true)).into(imageView);
2.4 源码解析
在前面我们提到了两种类型的内存缓存，那么Glide是如何协调两者的呢？让我们继续回到Engine的load方法
Engine#load
public synchronized <R> LoadStatus load(...) {//创建EngineKey对象EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,resourceClass, transcodeClass, options);//检查内存的弱引用缓存是否有目标图片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;}//检查内存的Lrucache缓存是否有目标图片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;}..... }
在上面的方法中我们可以发现首先根据宽高，图片URL地址等生成key，然后根据key首先调用loadFromActiveResources获取内存的弱引用缓存的图片，如果获取不到弱引用缓存的图片，才调用loadFromCache获取内存的LruCache缓存。因此我们先来看看Glide对弱引用缓存的操作。
1. 弱引用缓存
1.1 获取
从上面Engine的load方法中，我们知道获取弱引用缓存会调用Engine的loadFromActiveResources方法
Engine#loadFromActiveResources
private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable) {if (!isMemoryCacheable) {return null;}//重点关注get方法，从弱引用中拿数据EngineResource<?> active = activeResources.get(key);if (active != null) {//将EngineResource的引用计数加1active.acquire();}return active;}
这里首先会调用ActiveResources的get方法获取到图片资源，然后将EngineResource的引用计数加一，因为此时EngineResource指向了弱引用缓存的图片资源。
ActiveResources#get
final Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>(); synchronized EngineResource<?> get(Key key) {//从弱引用HashMap中取出对应的弱引用对象ResourceWeakReference activeRef = activeEngineResources.get(key);if (activeRef == null) {return null;}EngineResource<?> active = activeRef.get();//如果弱引用中关联的EngineResource对象不存在，即EngineResourse被回收if (active == null) {//清理弱引用缓存，恢复EngineResource，并保存到LruCache缓存中 cleanupActiveReference(activeRef);}return active;}
在ActiveResources中的get中，会通过activeEngineResources的get方法得到了数据的弱引用对象，而这个activeEngineResources其实就是个HashMap,所以可以根据key值来找到这个弱引用对象。而我们要找的图片资源其实就是这个弱引用对象关联的对象，让我们来看看ResourceWeakReference的实现
static final class ResourceWeakReference extends WeakReference<EngineResource<?>> {@SuppressWarnings("WeakerAccess") @Synthetic final Key key;@SuppressWarnings("WeakerAccess") @Synthetic final boolean isCacheable;@Nullable @SuppressWarnings("WeakerAccess") @Synthetic Resource<?> resource;@Synthetic@SuppressWarnings("WeakerAccess")ResourceWeakReference(@NonNull Key key,@NonNull EngineResource<?> referent,@NonNull ReferenceQueue<? super EngineResource<?>> queue,boolean isActiveResourceRetentionAllowed) {super(referent, queue);this.key = Preconditions.checkNotNull(key);this.resource =referent.isCacheable() && isActiveResourceRetentionAllowed? Preconditions.checkNotNull(referent.getResource()) : null;isCacheable = referent.isCacheable();}....}
}可以发现这个类其实继承了WeakReference，所以当gc发生时，会回收掉ResourceWeakReference对象关联的EngineResource对象，这个对象封装了我们所要获取的图片资源。另外这个类还保存了图片资源和图片资源的缓存key,这是为了当关联的EngineResource对象被回收时，可以利用保存的图片资源来恢复EngineResource对象，然后保存到LruCache缓存中并根据key值从HashMap中删除掉关联了被回收的EngineResource对象的弱引用对象。可以看下EngineResourse被回收的情况
ActiveResources#cleanupActiveReference
void cleanupActiveReference(@NonNull ResourceWeakReference ref) {synchronized (listener) {synchronized (this) {//将该弱引用缓存从HashMap中删除activeEngineResources.remove(ref.key);//判断缓存是否可用//isCacheable默认情况下为true//当配置中设置了RequestOptions.skipMemoryCacheOf()的值的话://1.当skipMemoryCacheOf传入true时为false,即关闭内存缓存//2.当skipMemoryCacheOf传入false时为true，即开启内存缓存if (!ref.isCacheable || ref.resource == null) {return;}//恢复EngineResource，其中这个对象封装了图片资源EngineResource<?> newResource =new EngineResource<>(ref.resource, /*isCacheable=*/ true, /*isRecyclable=*/ false);newResource.setResourceListener(ref.key, listener);//回调，该listener为Engine对象listener.onResourceReleased(ref.key, newResource);}}}Engine#onResourceReleased
public synchronized void onResourceReleased(Key cacheKey, EngineResource<?> resource) {//删除弱引用缓存activeResources.deactivate(cacheKey);//如果开启了内存缓存if (resource.isCacheable()) {//将弱引用缓存的数据缓存到LruCache缓存中 cache.put(cacheKey, resource);} else {resourceRecycler.recycle(resource);}}这样当弱引用缓存所关联的图片资源被回收时，会将图片资源保存到LruCache缓存中，从而保证了当获取不到弱引用缓存的图片时，可以获取的到该图片的LruCache缓存。
1.2 存储
弱引用缓存的存储体现在了两个地方：
- 在主线程展示图片前
- 获取LruCache缓存时
下面将对这两个地方分别进行解剖！
在主线程展示图片前存储
在讲弱引用缓存的存储前，我们首先要明白这个弱引用缓存保存到图片资源到底是图片的原始数据（图片输入流）还是转换后的图片资源，搞明白的话，找到弱引用存储的地方就不是问题了。这里我就不再细讲如何搞明白这个问题，其中一个思路就是从Engine的load方法中获取到弱引用缓存的操作入手，即回调入手。
//检查内存弱引用缓存是否有目标图片EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);if (active != null) {//此时回调的是SingleRequest的onResourceReady方法cb.onResourceReady(active, DataSource.MEMORY_CACHE);if (VERBOSE_IS_LOGGABLE) {logWithTimeAndKey("Loaded resource from active resources", startTime, key);}return null;}这个方法其实在上篇文章图片加载流程也提到过，然后追踪下去你就会发现其实最后就是展示这个图片资源，因此我们可以确定这个图片资源应该就是转换后的图片，所以存储弱引用缓存应该是在转换图片后的操作。（这里我直接讲出存储所在的位置，如果想自己深究可以看看上篇文章图片加载流程中的“在主线程中显示图片”这个步骤的代码）最后我们会发现在EngineJob的notifyCallbacksOfResult方法中找到了弱引用缓存入口
EngineJob#notifyCallbacksOfResult
void notifyCallbacksOfResult() {ResourceCallbacksAndExecutors copy;Key localKey;EngineResource<?> localResource;.....//内部缓存存储的入口//实际上调用的是Engine的onEngineJobCompletelistener.onEngineJobComplete(this, localKey, localResource);for (final ResourceCallbackAndExecutor entry : copy) {//回到主线程展示照片entry.executor.execute(new CallResourceReady(entry.cb));}//通知上层删除弱引用缓存数据decrementPendingCallbacks();}没错其入口就是我们在Glide图片加载流程提到过的回到主线程展示照片代码的前面，即回调了Engine的onEngineJobComplete来存储弱引用缓存
Engine#onEngineJobComplete
public synchronized void onEngineJobComplete(EngineJob<?> engineJob, Key key, EngineResource<?> resource) {if (resource != null) {resource.setResourceListener(key, this);//如果开启内存缓存的话，将解析后的图片添加到弱引用缓存if (resource.isCacheable()) {activeResources.activate(key, resource);}}jobs.removeIfCurrent(key, engineJob);}ActiveResources#activate
synchronized void activate(Key key, EngineResource<?> resource) {//构建弱引用对象ResourceWeakReference toPut =new ResourceWeakReference(key, resource, resourceReferenceQueue, isActiveResourceRetentionAllowed);//将获取到的缓存图片存储到弱引用对象的HashMap中//key值不重复返回null,key值重复返回旧对象ResourceWeakReference removed = activeEngineResources.put(key, toPut);if (removed != null) {//如果key值重复，就将之前的弱引用对象的图片资源置为null removed.reset();}}从这里也可以得到一个结论：正在使用的图片会存储到弱引用缓存中而不是LruCache缓存
获取LruCache缓存时存储
由于这个操作同时也涉及了LruCache的获取，故可以直接看下面对LruCache获取的解析
1.3 删除
弱引用缓存的删除其实体现在两处：
- JVM进行GC时
- 弱引用缓存对象引用计数为0时
JVM进行GC时
当JVM进行GC时，由于弱引用对象的特性，导致了弱引用缓存所关联的对象也会被回收，然后就会删除掉这个弱引用缓存对象，这部分我们在弱引用缓存获取的时候也分析过，这里不再进行解析（忘记的可以回头看看前面弱引用获取的分析）。
弱引用缓存对象引用计数为0时
细心的你不知有没有发现，其实在上面对缓存入口的分析时其实已经贴出了弱引用缓存删除的代码语句。不过为了方便阅读，在这里我还是再次直接贴出来。
EngineJob#notifyCallbacksOfResult
//内部缓存存储的入口//实际上调用的是Engine的onEngineJobCompletelistener.onEngineJobComplete(this, localKey, localResource);for (final ResourceCallbackAndExecutor entry : copy) {//回到主线程展示照片entry.executor.execute(new CallResourceReady(entry.cb));}//通知上层删除弱引用缓存数据decrementPendingCallbacks();EngineJob#decrementPendingCallbacks
synchronized void decrementPendingCallbacks() {.....if (decremented == 0) {if (engineResource != null) {//重点关注engineResource.release();}release();}}这里调用了EngineResource的release方法，让我们来看看
EngineResource#release
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) {//回调，listener为Engine类型 listener.onResourceReleased(key, this);}}}}在这里使用了著名的判断对象是否存活的算法-引用计数法，每次调用EngineResource对象的release方法，都会令该引用减一，当引用计数为0时，表示已经不再使用该对象，即图片不再使用时，就会回调Engine的onResourceReleased方法
Engine#onResourceReleased
public synchronized void onResourceReleased(Key cacheKey, EngineResource<?> resource) {//删除弱引用缓存activeResources.deactivate(cacheKey);//如果开启了内存缓存if (resource.isCacheable()) {//将弱引用缓存的数据缓存到LruCache缓存中 cache.put(cacheKey, resource);} else {resourceRecycler.recycle(resource);}}跟上面存储弱引用缓存时提到的发生GC的情况一样，最终会删除弱引用缓存，然后将该图片资源添加到LruCache缓存中。从这里也可以验证了我们上文提到的内存缓存的原理中的缓存实现：正在使用的图片使用弱引用机制进行缓存，不在使用中的图片使用LruCache来进行缓存。
2. LruCache缓存
2.1 获取
上文我们提到，获取内存缓存时，如果获取不到弱引用缓存时才会调用loadFromCache获取LruCache缓存。让我们看看Engine的loadFromCache方法
Engine#loadFromCache
private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {//isMemoryCacheable默认情况下为true//当配置中设置了RequestOptions.skipMemoryCacheOf()的值的话://1.当skipMemoryCacheOf传入true时为false,即关闭内存缓存//2.当skipMemoryCacheOf传入false时为true，即开启内存缓存if (!isMemoryCacheable) {return null;}//获取图片缓存,并将该缓存从LruCache缓存中删除EngineResource<?> cached = getEngineResourceFromCache(key);if (cached != null) {//将EngineResource的引用计数加1 cached.acquire();//将内存缓存存入弱引用缓存中//好处：保护这些图片不会被LruCache算法回收掉activeResources.activate(key, cached);}return cached;}获取LruCache缓存跟弱引用缓存的获取操作很相似，首先调用了getEngineResourceFromCache来获取图片资源，然后将EngineResource的引用计数加1，并且还会将获取到的图片资源存储到弱引用缓存中。这里我们只分析getEngineResourceFromCache方法，因为调用ActiveResource的activate存储到弱引用缓存我们已经在上面弱引用缓存的存储中分析过了。
EngineResource#getEngineResourceFromCache
/*** 作用：获取图片缓存* 过程：根据缓存key从cache中取值* 注：此cache对象为Glide构建时创建的LruResourceCache对象，说明使用的是LruCache算法*/private EngineResource<?> getEngineResourceFromCache(Key key) {//当获取到缓存图片时，从缓存中移除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;}在上面需注意的是该cache就是LruCache缓存的cache，另外你会发现获取图片缓存竟然不是调用cache的get方法，而是cache的remove方法，这就是Glide缓存策略的奇妙之处了。当获取到LruCache缓存的同时会删除掉该LruCache缓存，然后将该缓存存储到弱引用缓存中，这是为了保护这些图片不会被LruCache算法回收掉。
2.2 存储
当弱引用缓存删除时，会将缓存存储到LruCache缓存中。（分析可以看弱引用缓存删除操作）
2.3 删除
当获取LruCache缓存的同时对该LruCache缓存进行删除操作。（分析可以看LruCache缓存的获取操作）
2.5 小结
分析完内存缓存，你会发现弱引用缓存和LruCache缓存真的是环环相扣，密不可分，很多操作都是有关联性的。其流程图如下：
流程图的前提：开启内存缓存，关闭磁盘缓存
3. 磁盘缓存
3.1 作用
防止应用重复的从网络或从其它地方下载和读取数据
3.2 原理
使用Glide自定义的DiskLruCache算法
DiskLruCache算法是基于LruCache算法，该算法的应用场景是存储设备的缓存，即磁盘缓存。
3.3 配置
磁盘缓存也是默认开启的，默认情况下磁盘缓存的类型为DiskCacheStrategy.AUTOMATIC，当然可以通过代码关闭或者选择其它类型的磁盘缓存
Glide.with(getContext()).load(url).apply(RequestOptions.diskCacheStrategyOf(DiskCacheStrategy.RESOURCE)).into(imageView);diskCacheStrategyOf的相关参数说明如下：
| 参数 | 说明 |
|---|---|
| DiskCacheStrategy.AUTOMATIC |
这是默认的最优缓存策略： 本地：仅存储转换后的图片（RESOURCE） 网络：仅存储原始图片（DATA）。因为网络获取数据比解析磁盘上的数据要昂贵的多 |
| DiskCacheStrategy.NONE | 不开启磁盘缓存 |
| DiskCacheStrategy.RESOURCE | 缓存转换过后的图片 |
| DiskCacheStrategy.DATA | 缓存原始图片，即原始输入流。它需要经过压缩转换，解析等操作才能最终展示出来 |
| DiskCacheStrategy.ALL | 既缓存原始图片，又缓存转换后的图片 |
注：Glide加载图片默认是不会将一张原始图片展示出来的，而是将原始图片经过压缩转换，解析等操作。然后将转换后的图片展示出来。
3.4 源码解析
下列源码解析的前提：开启了磁盘缓存
虽然说上面的参数有五种，但其实我们只需要分析其中两种就能理解其它参数了。没错，接下来我们将分析RESOURCE类型和DATA类型。在分析前我们先回顾下Engine的load方法
Engine#load
public synchronized <R> LoadStatus load(.....) {......//创建EngineKey对象EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,resourceClass, transcodeClass, options);//检查内存弱引用缓存是否有目标图片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;}//检查内存中Lrucache缓存是否有目标图片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;}//走到这表示内存中没有图片，则开启新线程加载图片........//创建EngineJob对象，用来开启线程（异步加载图片）EngineJob<R> engineJob =engineJobFactory.build(key,isMemoryCacheable,useUnlimitedSourceExecutorPool,useAnimationPool,onlyRetrieveFromCache);DecodeJob<R> decodeJob =decodeJobFactory.build(glideContext,model,key,signature,width,height,resourceClass,transcodeClass,priority,diskCacheStrategy,transformations,isTransformationRequired,isScaleOnlyOrNoTransform,onlyRetrieveFromCache,options,engineJob);jobs.put(key, engineJob);engineJob.addCallback(cb, callbackExecutor);engineJob.start(decodeJob);return new LoadStatus(cb, engineJob);}从上面可以发现如果获取不到内存缓存时，会开启线程来加载图片。从上篇文章Glide 4.9源码解析-图片加载流程我们可以知道，接下来会执行DecodeJob的run方法。
DecodeJob
public void run() {.....//重点关注，调用runWrappedrunWrapped();}private void runWrapped() {switch (runReason) {case INITIALIZE://获取任务场景stage = getNextStage(Stage.INITIALIZE);//获取这个场景的执行者currentGenerator = getNextGenerator();//执行者执行任务runGenerators();break;case SWITCH_TO_SOURCE_SERVICE:runGenerators();break;case DECODE_DATA:decodeFromRetrievedData();break;default:throw new IllegalStateException("Unrecognized run reason: " + runReason);}}private DataFetcherGenerator getNextGenerator() {switch (stage) {case RESOURCE_CACHE://获取转换后图片的执行者return new ResourceCacheGenerator(decodeHelper, this);case DATA_CACHE://获取原始图片的执行者return new DataCacheGenerator(decodeHelper, this);case SOURCE:// 无缓存, 网络获取数据的执行者return new SourceGenerator(decodeHelper, this);case FINISHED:return null;default:throw new IllegalStateException("Unrecognized stage: " + stage);}}可以发现在上述的方法中首先要找到对于场景的执行者然后执行任务。而执行者有三个，在上篇文章我们分析的是无缓存的情况，即网络获取数据的执行者。接下来我们就得分析获取转换后图片的执行者和获取原始突破的执行者。
1. RESOURCE缓存（转换图片）
1.1 获取
由于我们现在配置的缓存策略为RESOURCE，故对于执行者将是获取转换图片的执行者ResourceCacheGenerator,接下来会执行者会执行任务，让我们看看runGenerators方法
Engine#runGenerators
private void runGenerators() {currentThread = Thread.currentThread();startFetchTime = LogTime.getLogTime();boolean isStarted = false;// 调用 currentGenerator.startNext() 执行了请求操作//我们这里主要分析的是无缓存情况，所以这里的currentGenerator应该是ResourceCacheGeneratorwhile (!isCancelled && currentGenerator != null&& !(isStarted = currentGenerator.startNext())) {stage = getNextStage(stage);currentGenerator = getNextGenerator();if (stage == Stage.SOURCE) {reschedule();return;}}因为我们现在的执行者为ResourceCacheGenerator，所以会调用ResourceCacheGenerator的startNext来进行获取图片。
ResourceCacheGenerator#startNext
public boolean startNext() {....while (modelLoaders == null || !hasNextModelLoader()) {.....Key sourceId = sourceIds.get(sourceIdIndex);Class<?> resourceClass = resourceClasses.get(resourceClassIndex);Transformation<?> transformation = helper.getTransformation(resourceClass);//构建获取缓存数据的key,这个key中传入了图片大小，变换等参数//即根据各种变换的条件获取缓存数据，故这个执行者就是用来获取变换之后的缓存数据currentKey =new ResourceCacheKey(// NOPMD AvoidInstantiatingObjectsInLoopshelper.getArrayPool(),sourceId,helper.getSignature(),helper.getWidth(),helper.getHeight(),transformation,resourceClass,helper.getOptions());//从缓存中获取缓存信息//首先通过getDiskCache获取DiskCache对象//然后通过key获取到转换过后的资源cacheFile = helper.getDiskCache().get(currentKey);if (cacheFile != null) {sourceKey = sourceId;//该modeLoaders的类型为File类型的modelLoaders = helper.getModelLoaders(cacheFile);modelLoaderIndex = 0;}}loadData = null;boolean started = false;while (!started && hasNextModelLoader()) {//获取数据加载器ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);//构建一个加载器，构建出来的是ByteBufferFileLoaderloadData = modelLoader.buildLoadData(cacheFile,helper.getWidth(), helper.getHeight(), helper.getOptions());if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {started = true;//调用了ByteBufferFileLoader的内部类ByteBufferFetcher的loadData//最后会把结果回调给DecodeJob的onDataFetcherReadyloadData.fetcher.loadData(helper.getPriority(), this);}}return started;}可以发现在ResourceCacheGenerator的startNext方法中，首先根据图片的参数，宽高等信息拿到缓存key,然后通过缓存key获取到磁盘上的文件，即磁盘缓存。最后通过加载器的loadData来处理获取到的磁盘缓存，由于磁盘缓存是File类型，根据Glide的注册表registry中可以找到该加载器其实是ByteBufferFileLoader（具体查找可看上篇博客的分析），故最后会调用ByteBufferFileLoader内部类ByteBufferFetcher的loadData方法来处理磁盘缓存。
ByteBufferFileLoader.ByteBufferFetcher#loadData
public void loadData(@NonNull Priority priority,@NonNull DataCallback<? super ByteBuffer> callback) {ByteBuffer result;try {//获取对应磁盘上的转换过后的数据result = ByteBufferUtil.fromFile(file);} catch (IOException e) {if (Log.isLoggable(TAG, Log.DEBUG)) {Log.d(TAG, "Failed to obtain ByteBuffer for file", e);}callback.onLoadFailed(e);return;}//此callback为ResourceCacheGenerator callback.onDataReady(result);}在loadData中会通过ByteBufferUtil工具类来获取对应磁盘文件的数据，然后通过回调ResourceCacheGenerator的onDataReady方法将数据回调出去。
ResourceCacheGenerator#onDataReady
public void onDataReady(Object data) {//此时的cb为DecodeJob，即调用了DecodeJob的onDataFetcherReadycb.onDataFetcherReady(sourceKey, data, loadData.fetcher, DataSource.RESOURCE_DISK_CACHE,currentKey);}进行回调DecodeJob的onDataFetcherReady
DecodeJob#onDataFetcherReady
public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,DataSource dataSource, Key attemptedKey) {//将各种值赋值给成员变量this.currentSourceKey = sourceKey;this.currentData = data;this.currentFetcher = fetcher;this.currentDataSource = dataSource;this.currentAttemptingKey = attemptedKey;if (Thread.currentThread() != currentThread) {runReason = RunReason.DECODE_DATA;callback.reschedule(this);} else {GlideTrace.beginSection("DecodeJob.decodeFromRetrievedData");try {//解析获取的数据decodeFromRetrievedData();} finally {GlideTrace.endSection();}}}接下来就会对数据进行压缩转换等操作，然后进行展示（在上篇文章已经分析，这里不再进行后续的分析）。
1.2 存储
由于我们分析的是转换后的图片的存储，故其存储位置应该是在对原始图片压缩转换解析等一系列操作完后进行的，根据上一篇文章的分析，我们直接看DecodeJob的decodeFromRetrievedData方法
DecodeJob
private void decodeFromRetrievedData() {if (Log.isLoggable(TAG, Log.VERBOSE)) {logWithTimeAndKey("Retrieved data", startFetchTime,"data: " + currentData+ ", cache key: " + currentSourceKey+ ", fetcher: " + currentFetcher);}Resource<R> resource = null;try {//转换后的图片资源resource = decodeFromData(currentFetcher, currentData, currentDataSource);} catch (GlideException e) {e.setLoggingDetails(currentAttemptingKey, currentDataSource);throwables.add(e);}if (resource != null) {//通知外界资源获取成功 notifyEncodeAndRelease(resource, currentDataSource);} else {runGenerators();}}private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {.....//图片加载流程时重点关注的地方notifyComplete(result, dataSource);stage = Stage.ENCODE;try {//是否可以将转换的图片缓存if (deferredEncodeManager.hasResourceToEncode()) {//磁盘缓存入口 deferredEncodeManager.encode(diskCacheProvider, options);}} finally {if (lockedResource != null) {lockedResource.unlock();}}onEncodeComplete();}我们在通知外界资源获取成功即notifyEncodeAndRelease方法中发现了RESOURCE类型的磁盘缓存的入口。
DecodeJob.DeferredEncodeManager#encode
void encode(DiskCacheProvider diskCacheProvider, Options options) {GlideTrace.beginSection("DecodeJob.encode");try {//将图片资源缓存到资源磁盘diskCacheProvider.getDiskCache().put(key,new DataCacheWriter<>(encoder, toEncode, options));} finally {toEncode.unlock();GlideTrace.endSection();}}在encode方法中通过DiskCacheProvider获取到DiskCache，然后调用put方法将图片资源缓存到磁盘上。
1.3 删除
由于缓存在了磁盘上，故删除不仅仅由代码控制。常见的删除方式如下：
- 用户主动删除手机上的对应文件
- 卸载软件
- 调用DiskCache.clear()
2. DATA缓存（原始图片）
2.1 获取
通过上面的分析我们知道原始图片对应的执行者为DataCacheGenerator，故还是会调用DataCacheGenerator的startNext方法来获取磁盘缓存
DataCacheGenerator#startNext
public boolean startNext() {while (modelLoaders == null || !hasNextModelLoader()) {.....Key sourceId = cacheKeys.get(sourceIdIndex);@SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")//构建缓存key Key originalKey = new DataCacheKey(sourceId, helper.getSignature());//获取缓存key的磁盘资源cacheFile = helper.getDiskCache().get(originalKey);if (cacheFile != null) {this.sourceKey = sourceId;modelLoaders = helper.getModelLoaders(cacheFile);modelLoaderIndex = 0;}}loadData = null;boolean started = false;while (!started && hasNextModelLoader()) {ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);loadData =modelLoader.buildLoadData(cacheFile, helper.getWidth(), helper.getHeight(),helper.getOptions());if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {started = true;loadData.fetcher.loadData(helper.getPriority(), this);}}return started;}你会发现其实这个startNext方法与刚刚分析的ResourceCacheGenerator的startNext几乎是一样，不同的是缓存key的构建参数是不一样的，因为原始图片的缓存key是不需要图片的宽高，配置，变换等参数。然后接下来的分析与转换图片获取的分析是一致的，这里不再进行分析。
2.2 存储
我们知道原始图片说白了就是网络获取后得到的原始的输入流，通过上一篇加载流程的分析，我们知道获取到原始输入流是在HttpUrlFetcher的loadData方法中
HttpUrlFetcher#loadData
public void loadData(@NonNull Priority priority,@NonNull DataCallback<? super InputStream> callback) {long startTime = LogTime.getLogTime();try {//获取网络图片的输入流 InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());//将inputStream回调出去，回调了SourceGenerator的onDataReadycallback.onDataReady(result);} catch (IOException e) {if (Log.isLoggable(TAG, Log.DEBUG)) {Log.d(TAG, "Failed to load data for url", e);}callback.onLoadFailed(e);} finally {if (Log.isLoggable(TAG, Log.VERBOSE)) {Log.v(TAG, "Finished http url fetcher fetch in " + LogTime.getElapsedMillis(startTime));}}}在获取到原始输入流后，会调用SourceGenerator的onDataReady将输入流回调出去
SourceGenerator#onDataReady
public void onDataReady(Object data) {DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();//如果开启了磁盘缓存if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {//将网络获取到的原始数据，赋值给dataToCache dataToCache = data;//调用DecodeJob的reschedule，用线程池执行任务，实际上就是再次调用SourceGenerator的startNextcb.reschedule();} else {//没有开启磁盘缓存cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,loadData.fetcher.getDataSource(), originalKey);}}由于我们开启了磁盘缓存，故会将原始数据赋值给dataToCache，然后回调了DecodeJob的reschedule。
DecodeJob#reschedule
public void reschedule() {runReason = RunReason.SWITCH_TO_SOURCE_SERVICE;//此时的callback为EngineJobcallback.reschedule(this);}这里继续回调了EngineJob的reschedule方法
EngineJob#reschedule
public void reschedule(DecodeJob<?> job) {//再次切换到网络线程，执行DecodeJob的run方法getActiveSourceExecutor().execute(job);}这里的job为DecodeJob,而getActiveSourceExecutor()会拿到线程池，所以reschedule方法其实会继续执行DecodeJob的run方法，然后拿到网络获取数据的执行者SourceGenerator，再次执行SourceGenerator的startNext方法（考虑到篇幅，不再贴其中的流程代码了，详细可以看上篇文章Glide 4.9源码解析-图片加载流程。
不过估计在这里可能有人会疑问，我们明明开启了磁盘缓存，为什么会获取到无缓存，网络获取数据的执行者呢？这是因为我们在存储原始图片的前提下，肯定是磁盘没有缓存，因此会从网络加载图片得到原始图片的输入流，然后回调，回调后当然还是拿到网络获取数据的执行者SourceGenerator。让我们再来看看这个startNext方法。
SourceGenerator#startNext
public boolean startNext() {//第二次进入//现在dataToCache不等于null，为原始图片if (dataToCache != null) {Object data = dataToCache;dataToCache = null;//放入缓存 cacheData(data);}//当原始图片放入磁盘缓存后，sourceCacheGenerator为DataCacheGenerator//然后继续执行DataCacheGenerator的startNext方法if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {return true;}//走到这，说明是没有开启磁盘缓存或获取不到磁盘缓存的情况下 sourceCacheGenerator = null;loadData = null;boolean started = false;while (!started && hasNextModelLoader()) {loadData = helper.getLoadData().get(loadDataListIndex++);if (loadData != null&& (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())|| helper.hasLoadPath(loadData.fetcher.getDataClass()))) {started = true;loadData.fetcher.loadData(helper.getPriority(), this);}}return started;}通过上面的分析我们知道此时的dataToCache是不为null的，而是原始图片，所以会调用cacheData方法将原始图片放入到磁盘缓存中。(如果你阅读了Glide图片加载流程的话，就会发现我们在图片加载流程的时候分析的其实是下面的代码，即没有开启缓存或获取不到磁盘缓存的情况）这里我们继续看cacheData方法
SourceGenerator#cacheData
private void cacheData(Object dataToCache) {long startTime = LogTime.getLogTime();try {Encoder<Object> encoder = helper.getSourceEncoder(dataToCache);DataCacheWriter<Object> writer =new DataCacheWriter<>(encoder, dataToCache, helper.getOptions());//构建缓存key originalKey = new DataCacheKey(loadData.sourceKey, helper.getSignature());//存储原始图片helper.getDiskCache().put(originalKey, writer);......} finally {loadData.fetcher.cleanup();}//构造一个DataCacheGenerator对象，用来加载刚保存的磁盘缓存sourceCacheGenerator =new DataCacheGenerator(Collections.singletonList(loadData.sourceKey), helper, this);}在cacheData方法中会通过DiskCache的put方法将缓存key，原始图片等存储到磁盘中。然后会构造DataCacheGenerator对象，这时候我们看回SourceGenerator的startNext方法，由于此时的sourceCacheGenerator已经是DataCacheGenerator对象了，所以会调用DataCacheGenerator的startNext方法来获取磁盘缓存中的原始图片。
2.3 删除
由于原始图片的缓存也属于磁盘缓存，故跟RESOURCE缓存一样删除不仅仅由代码控制，常见删除方式如下：
- 用户主动删除手机上的对应文件
- 卸载软件
- 调用DiskCache.clear()
3.5 小结
从上面的分析可以发现Glide中首先会读取转换后的图片的缓存，然后再读取原始图片的缓存。但是存储的时候恰恰相反，首先存储的是原始图片的缓存，再存储转换后的图片，不过获取和存储都受到Glide使用API的设置的影响。其流程图如下：
流程图的前提：关闭内存缓存或获取不到内存缓存，开启磁盘缓存
总结
通过对Glide缓存策略的分析，发现了Glide的缓存机制是多么的复杂，但又是多么的出色啊，所以用起来才会这么流畅和舒服。分析到这,Glide的缓存策略也就讲完了，而对Glide这个强大的图片开源库的源码分析也告一段落了，通过对Glide的图片加载流程和缓存策略的源码解析，让我更加佩服Glide这个强大的开源库。
参考文章：
- Android 图片加载框架 Glide 4.9.0 (二) 从源码的角度分析 Glide 缓存策略
- Android源码分析：手把手带你分析 Glide的缓存功能
- Android图片加载框架最全解析（三），深入探究Glide的缓存机制
Glide 4.9源码解析-缓存策略相关推荐
- Glide 4.9源码解析-图片加载流程
本文Glide源码基于4.9,版本下载地址如下:Glide 4.9 前言 由于Glide源码真的很复杂,因此本文只分析和贴出与图片加载流程相关的功能以及代码.另外本文Glide源码基于4.9,与3.x ...
- Android 图片加载框架Gilde源码解析
1.使用Gilde显示一张图片 Glide.with(this).load("https://cn.bing.com/sa/simg/hpb/xxx.jpg").into(imag ...
- Android Glide图片加载框架（二）源码解析之into()
文章目录 一.前言 二.源码解析 1.into(ImageView) 2.GlideContext.buildImageViewTarget() 3.RequestBuilder.into(Targe ...
- Android Glide图片加载框架（二）源码解析之load()
文章目录 一.前言 二.源码分析 1.load() Android Glide图片加载框架系列文章 Android Glide图片加载框架(一)基本用法 Android Glide图片加载框架(二)源 ...
- Android Glide图片加载框架（二）源码解析之with()
文章目录 一.前言 二.如何阅读源码 三.源码解析 1.with() Android Glide图片加载框架系列文章 Android Glide图片加载框架(一)基本用法 Android Glide图 ...
- [源码解析] 深度学习流水线并行 PipeDream(6)--- 1F1B策略
[源码解析] 深度学习流水线并行 PipeDream(6)- 1F1B策略 文章目录 [源码解析] 深度学习流水线并行 PipeDream(6)--- 1F1B策略 0x00 摘要 0x01 流水线比 ...
- Android经典著名的百大框架源码解析（retrofit、Okhttp、Glide、Zxing、dagger等等）
我们Android程序员每天都要和源码打交道.经过数年的学习,大多数程序员可以"写"代码,或者至少是拷贝并修改代码.而且,我们教授编程的方式强调编写代码的艺术,而不是如何阅读代码. ...
- Android Glide 3.7.0 源码解析(八) , RecyclableBufferedInputStream 的 mark/reset 实现
个人博客传送门 一.mark / reset 的作用 Android Glide 3.7.0 源码解析(七) , 细说图形变换和解码有提到过RecyclableBufferedInputStream ...
- YYCache 源码解析（一）：使用方法，架构与内存缓存的设计
YYCache是国内开发者ibireme开源的一个线程安全的高性能缓存组件,代码风格简洁清晰,阅读它的源码有助于建立比较完整的缓存设计的思路,同时也能巩固一下双向链表,线程锁,数据库操作相关的知识. ...
最新文章
- Javascript与框架prototype,JQyuery调研
- python的编程模式-使用简单工厂模式来进行Python的设计模式编程
- 女生学计算机有什么要求,女生学计算机专业好吗？
- java中的排序算法——归并排序
- CentOS 6.3下源码安装LAMP(Linux+Apache+Mysql+Php)环境
- 创建分区表+分区表的分类+创建散列分区表+查看散列分区表分区中的数据+创建列表分区表+查看列表分区表分区中的数据...
- mysql英文版怎么调中文_MYSQL 5.6安装设置中英文翻译
- ASP.NET MVC Filter过滤机制（过滤器、拦截器）
- [css] 如何使用css3实现一个div设置多张背景图片？
- 科普 | 知识图谱相关的名词解释
- Java Socket笔记-利用tcp socket搭建CS模型
- ASP.NET操作简单的xml，增删改查
- 50岁，投资理财方面接触较少，手上有280万，该如何操作？
- html有序列表和无序列表
- python 字符串以及通过dos命令运行py脚本
- IntelliJ IDEA 中文语言包插件
- 立创3D文件转成stp文件应用到AD中
- POE交换机和普通交换机哪里不同?POE交换机和普通交换机哪个好？
- mysql三个表连接语句_INNER JOIN连接两个表、三个表、五个表的SQL语句
- Socket error Event: 32 Error: 10053.