Android-图片加载框架-Glide-4-9-0-(二)-切入源码层深入分析-Glide-缓存策略

最后

有任何问题,欢迎广大网友一起来交流,分享高阶Android学习视频资料和面试资料包~

偷偷说一句:群里高手如云,欢迎大家加群和大佬们一起交流讨论啊!

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

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 清理掉的,详细可以看内存缓存获取的方式。

内存缓存小结

通过上面分析可知,内存缓存有活动缓存和内存资源缓存,下面看一个图来总结下它们相互之间是怎么配合交换数据的。

总结下步骤:

  1. 第一次加载没有获取到活动缓存。
  2. 接着加载内存资源缓存,先清理掉内存缓存,在添加进行活动缓存。
  3. 第二次加载活动缓存已经存在。
  4. 当前图片引用为 0 的时候,清理活动资源,并且添加进内存资源。
  5. 又回到了第一步,然后就这样环环相扣。

磁盘缓存

在介绍磁盘缓存之前先看一张表格

缓存表示说明
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);
currentGenerator = getNextGenerator();
if (stage == Stage.SOURCE) {
reschedule();
return;
}
}

}
复制代码

通过上面代码可知,主要是执行 currentGenerator.startNext() 就句代码,currentGerator 是一个接口,通过注释 3.1 我们知道这里它的实现类是 ResourceCacheGenerator ,那么我们具体看下 ResourceCacheGenerator 的 startNext 函数;

class ResourceCacheGenerator implements DataFetcherGenerator,
DataFetcher.DataCallback {

@Override
public boolean startNext() {

while (modelLoaders == null || !hasNextModelLoader()) {
resourceClassIndex++;


//1. 拿到资源缓存 key
currentKey =
new ResourceCacheKey(// NOPMD AvoidInstantiatingObjectsInLoops
helper.getArrayPool(),
sourceId,
helper.getSignature(),
helper.getWidth(),
helper.getHeight(),
transformation,
resourceClass,
helper.getOptions());
//2. 通过 key 获取到资源缓存
cacheFile = helper.getDiskCache().get(currentKey);
if (cacheFile != null) {
sourceKey = sourceId;
modelLoaders = helper.getModelLoaders(cacheFile);
modelLoaderIndex = 0;
}
}

loadData = null;
boolean started = false;
while (!started && hasNextModelLoader()) {
//3. 获取一个数据加载器
ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);
//3.1 为资源缓存文件,构建一个加载器,这是构建出来的是 ByteBufferFileLoader 的内部类 ByteBufferFetcher
loadData = modelLoader.buildLoadData(cacheFile,
helper.getWidth(), helper.getHeight(), helper.getOptions());
if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {
started = true;
//3.2 利用 ByteBufferFetcher 加载,最后把结果会通过回调给 DecodeJob 的 onDataFetcherReady 函数
loadData.fetcher.loadData(helper.getPriority(), this);
}
}

}
复制代码

通过上面注释可以得到几点信息

  1. 首先根据 资源 ID 等一些信息拿到资源缓存 Key
  2. 通过 key 拿到缓存文件
  3. 构建一个 ByteBufferFetcher 加载缓存文件
  4. 加载完成之后回调到 DecodeJob 中。

存储资源数据

先来看下面一段代码:

class DecodeJob implements DataFetcherGenerator.FetcherReadyCallback,
Runnable,
Comparable<DecodeJob<?>>,
Poolable {

private void notifyEncodeAndRelease(Resource resource, DataSource dataSource) {

stage = Stage.ENCODE;
try {
//1. 是否可以将转换后的图片缓存
if (deferredEncodeManager.hasResourceToEncode()) {
//1.1 缓存入口
deferredEncodeManager.encode(diskCacheProvider, options);
}
} finally {

}
onEncodeComplete();
}
}

void encode(DiskCacheProvider diskCacheProvider, Options options) {
GlideTrace.beginSection(“DecodeJob.encode”);
try {
//1.2 将 Bitmap 缓存到资源磁盘
diskCacheProvider.getDiskCache().put(key,
new DataCacheWriter<>(encoder, toEncode, options));
} finally {
toEncode.unlock();
GlideTrace.endSection();
}
}
复制代码

通过上面我们知道 http 请求到图片输入流之后经过一系列处理,转换得到目标 Bitmap 资源,最后通过回调到 DecodeJob 进行缓存起来。

清理资源缓存

  1. 用户主动通过系统来清理
  2. 卸载软件
  3. 调用 DisCache.clear();

DiskCacheStrategy.DATA 原始数据类型

获取原始数据

参考上小节DiskCacheStrategy.RESOURCE 获取资源,不同的是把 ResourceCacheGenerator 换成 DataCacheGenerator 加载了。

存储原始数据

这里既然存的是原始数据那么我们直接从 http 请求之后的响应数据开始查看,通过上一篇我们知道是在 HttpUrlFetcher 中请求网络,直接定位到目的地:

public class HttpUrlFetcher implements DataFetcher {

@Override
public void loadData(@NonNull Priority priority,
@NonNull DataCallback<? super InputStream> callback) {
long startTime = LogTime.getLogTime();
try {
//1. 通过 loadDataWithRedirects 来进行http 请求,返回 InputStream
InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
//2. 将请求之后的数据返回出去
callback.onDataReady(result);
} catch (IOException e) {

} finally {

}
}
}
复制代码

根据注释可以得知,这里主要用于网络请求,请求响应数据回调给 MultiModelLoader 中。我们看下 它具体实现:

class MultiModelLoader<Model, Data> implements ModelLoader<Model, Data> {

@Override
public void onDataReady(@Nullable Data data) {
//如果数据不为空,那么就回调给 SourceGenerator
if (data != null) {
callback.onDataReady(data);
} else {
startNextOrFail();
}
}

}
复制代码

这里的 callback 指的是 SourceGenerator ,继续跟

class SourceGenerator implements DataFetcherGenerator,
DataFetcher.DataCallback,
DataFetcherGenerator.FetcherReadyCallback {

@Override
public void onDataReady(Object data) {
DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
//1. 收到网络下载好的图片原始数据,赋值给成员变量 dataToCache
dataToCache = data;
//2. 交给 EngineJob
cb.reschedule();
} else {
cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
loadData.fetcher.getDataSource(), originalKey);
}
}

学习分享

在当下这个信息共享的时代,很多资源都可以在网络上找到,只取决于你愿不愿意找或是找的方法对不对了

很多朋友不是没有资料,大多都是有几十上百个G,但是杂乱无章,不知道怎么看从哪看起,甚至是看后就忘

如果大家觉得自己在网上找的资料非常杂乱、不成体系的话,我也分享一套给大家,比较系统,我平常自己也会经常研读。

2021最新上万页的大厂面试真题

七大模块学习资料:如NDK模块开发、Android框架体系架构…

只有系统,有方向的学习,才能在段时间内迅速提高自己的技术。

这份体系学习笔记,适应人群:
第一,学习知识比较碎片化,没有合理的学习路线与进阶方向。
第二,开发几年,不知道如何进阶更进一步,比较迷茫。
第三,到了合适的年纪,后续不知道该如何发展,转型管理,还是加强技术研究。如果你有需要,我这里恰好有为什么,不来领取!说不定能改变你现在的状态呢!
由于文章内容比较多,篇幅不允许,部分未展示内容以截图方式展示 。

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

我也分享一套给大家,比较系统,我平常自己也会经常研读。

2021最新上万页的大厂面试真题

[外链图片转存中…(img-9QvJlzLi-1715222862541)]

七大模块学习资料:如NDK模块开发、Android框架体系架构…

[外链图片转存中…(img-FeEvZ76c-1715222862541)]

只有系统,有方向的学习,才能在段时间内迅速提高自己的技术。

这份体系学习笔记,适应人群:
第一,学习知识比较碎片化,没有合理的学习路线与进阶方向。
第二,开发几年,不知道如何进阶更进一步,比较迷茫。
第三,到了合适的年纪,后续不知道该如何发展,转型管理,还是加强技术研究。如果你有需要,我这里恰好有为什么,不来领取!说不定能改变你现在的状态呢!
由于文章内容比较多,篇幅不允许,部分未展示内容以截图方式展示 。

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值