上一篇文章《Glide原理解析(一):加载流程分析》主要大致地分析了Glide加载图片的整体流程,这一篇主要解决的上一篇遗留的一个问题:
Glide Engine 如何加载图片,内部涉及到Glide的缓存模块
上篇文章在SingleRequest中获取到了ViewTarget的宽高之后(假定是ImageView),onSizeReady()调用了engine的load()方法
loadStatus = engine.load(
glideContext,
model,
requestOptions.getSignature(),
this.width,
this.height,
requestOptions.getResourceClass(),
transcodeClass,
priority,
requestOptions.getDiskCacheStrategy(),
requestOptions.getTransformations(),
requestOptions.isTransformationRequired(),
requestOptions.isScaleOnlyOrNoTransform(),
requestOptions.getOptions(),
requestOptions.isMemoryCacheable(),
requestOptions.getUseUnlimitedSourceGeneratorsPool(),
requestOptions.getUseAnimationPool(),
requestOptions.getOnlyRetrieveFromCache(),
this);
在看Engine的load()方法之前,先看下Engine主要的数据结构
private final Jobs jobs;
负责缓存EngineJob的管理类private final EngineKeyFactory keyFactory;
负责创建缓存的keyprivate final DecodeJobFactory decodeJobFactory;
负责创建DecodeJob, DecodeJob负责从缓存或原始资源解码转换private final EngineJobFactory engineJobFactory;
负责创建EngineJob,EngineJob负责处理DecodeJob的加载结果private final ResourceRecycler resourceRecycler;
当资源被移除或者释放时,负责回收资源(可能是被回收到其他的LruCache中去)private final MemoryCache cache;
内部是LruCache缓存private final LazyDiskCacheProvider diskCacheProvider;
内部是DiskLruCache缓存private final ActiveResources activeResources;
内部是弱引用缓存,当前活跃的缓存资源
看完了上面的数据结构,开始load()加载资源
// Engine.java
public <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) {
// 根据图像类型、原始宽高、目标宽高、转换等各种因素创建一个Key
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);
return null;
}
// 从LruCache资源获取
EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
if (cached != null) {
// 获取成功,直接回调返回
cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
return null;
}
// 从DiskLruCache资源获取
EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
if (current != null) {
// 获取成功,需要进一步转码
current.addCallback(cb);
return new LoadStatus(cb, current);
}
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);
// 添加engineJob到jobs中管理
jobs.put(key, engineJob);
engineJob.addCallback(cb);
// 开始加载
engineJob.start(decodeJob);
return new LoadStatus(cb, engineJob);
}
在开始看engineJob如何加载之前,先看下一个问题:
一般来说我们都是使用LruCache和DiskLruCache作为缓存,为什么Glide还用上了弱引用缓存?
如果你仔细的看你可以注意到从LruCache加载资源方法,有些奇怪:
private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {
...
// 从LruCache获取资源
EngineResource<?> cached = getEngineResourceFromCache(key);
if (cached != null) {
cached.acquire();
// 加入到activeResources弱引用
activeResources.activate(key, cached);
}
return cached;
}
private EngineResource<?> getEngineResourceFromCache(Key key) {
// 从LruCache获取资源,并且移除它
Resource<?> cached = cache.remove(key);
...
return result;
}
相信你看到了,从LruCache获取资源并将它移除,加入到弱引用缓存中。后面终于想清楚了:
LruCache是有容量限制的,比如说设定10个,那么当前活跃图片如果有8个,那么LruCache其中有8个是当前活跃图片,2个缓存之前使用过的图片。
加入了弱引用缓存以后,LruCache可以缓存10个之前使用过的图片,并且因为弱引用的特性,不会复制副本,占据内存。
在不增加缓存内存容量限制的情况下,弱引用缓存极大地增大了Glide的命中率。
继续看engineJob.start(decodeJob)
// EngineJob.java
public void start(DecodeJob<R> decodeJob) {
this.decodeJob = decodeJob;
// 根据是否从缓存加载选定不同的线程池
GlideExecutor executor = decodeJob.willDecodeFromCache()
? diskCacheExecutor
: getActiveSourceExecutor();
// 加入到线程池中,继续到decodeJob.run()
executor.execute(decodeJob);
}
注释写得蛮清楚,继续到DecodeJob.run()
// DecodeJob.java
public void run() {
...
runWrapped();
...
}
private void runWrapped() {
switch (runReason) {
case INITIALIZE:
// 首次获取
stage = getNextStage(Stage.INITIALIZE);
currentGenerator = getNextGenerator();
runGenerators();
break;
case SWITCH_TO_SOURCE_SERVICE:
// 从获取Disk资源失败重新获取
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);
}
}
在runWrapped中还使用了状态者模式,对应有三种资源:
Data: 原始的图片缓存数据
Resource: 经过处理的图片缓存数据(例如旋转裁剪转换)
Source:无缓存数据
代码会依次走DataCacheGenerator、ResourceCacheGenerator、SourceGenerator,如果一个无法处理就传递给下一个Generator。
这里假定是首次加载数据,就会走到 SourceGenerator ,并且runGenerators()方法调用SourceGenerator.runNext()
// SourceGenerator.java
public boolean startNext() {
// dataToCache 表示已经获取到的资源
if (dataToCache != null) {
Object data = dataToCache;
dataToCache = null;
// 将数据缓存
cacheData(data);
}
// cacheData 会生成sourceCacheGenerator,交由sourceCacheGenerator缓存处理器处理
if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
// 到这里,说明不需要去获取数据
return true;
}
sourceCacheGenerator = null;
loadData = null;
boolean started = false;
// 以下部分就是根据缓存策略和各个ModelLoader去加载对应的资源
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;
}
ModelLoader 是一个工厂接口,用于将任意复杂的数据模型转换为具体数据类型,从而能够使用DataFetcher去获取由该模型表示的资源的数据。
LoadData 一系列Key和DataFetcher组合的一个数据结构。
HttpGlideUrlLoader ModelLoader实现类,内部会构建一个HttpUrlFetcher对象。
FileLoader ModelLoader实现类,内部会构建一个FileFetcher对象。
在Glide初始化的时候有注册了各种ModelLoader,包括了HttpGlideUrlLoader
registry.append(GlideUrl.class, InputStream.class, new HttpGlideUrlLoader.Factory())
HttpGlideUrlLoader 内部构造了 HttpUrlFetcher ,调用了 HttpUrlFetcher 的loadData()加载网络数据
// HttpUrlFetcher
public void loadData(@NonNull Priority priority,
@NonNull DataCallback<? super InputStream> callback) {
try {
InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
callback.onDataReady(result);
} catch (IOException e) {
callback.onLoadFailed(e);
}
}
private InputStream loadDataWithRedirects(URL url, int redirects, URL lastUrl,
Map<String, String> headers) throws IOException {
...
// 利用HttpUrlConnection
urlConnection = connectionFactory.build(url);
for (Map.Entry<String, String> headerEntry : headers.entrySet()) {
urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
}
// 设置 HttpUrlConnection 参数
urlConnection.setConnectTimeout(timeout);
urlConnection.setReadTimeout(timeout);
urlConnection.setUseCaches(false);
urlConnection.setDoInput(true);
urlConnection.setInstanceFollowRedirects(false);
urlConnection.connect();
stream = urlConnection.getInputStream();
if (isCancelled) {
// 被取消
return null;
}
final int statusCode = urlConnection.getResponseCode();
if (isHttpOk(statusCode)) {
// 成功
return getStreamForSuccessfulRequest(urlConnection);
} else if (isHttpRedirect(statusCode)) {
// 重定向
String redirectUrlString = urlConnection.getHeaderField("Location");
if (TextUtils.isEmpty(redirectUrlString)) {
throw new HttpException("Received empty or null redirect url");
}
URL redirectUrl = new URL(url, redirectUrlString);
cleanup();
return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers);
}
}
千辛万苦终于到最后一步的网络加载,底层是利用HttpUrlConnection加载数据
public void onDataReady(Object data) {
DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
// 如果可以缓存
if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
dataToCache = data; // 将网络获取到资源缓存在SourceGenerator中
cb.reschedule(); // DecodeJob会再次执行
} else {
cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
loadData.fetcher.getDataSource(), originalKey);
}
}
SourceGenerator再次执行到了startNext(),但是dataToCache已经有数据,在cacheData内部生成了 DataCacheGenerator
// SourceGenerator.java
public boolean startNext() {
// dataToCache 表示已经获取到的资源
if (dataToCache != null) {
Object data = dataToCache;
dataToCache = null;
// 将数据缓存
cacheData(data);
}
// cacheData 会生成 sourceCacheGenerator,交由 sourceCacheGenerator 缓存处理器处理
if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
// 到这里,说明不需要去获取数据
return true;
}
...
}
// SourceGenerator.java
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);
}
可见,SourceGenerator第二次执行的时候将缓存写入,并且生成 DataCacheGenerator,并交给DataCacheGenerator.startNext()。
DataCacheGenerator内部会回调 FetcherReadyCallback.onDataFetcherReady(),其实 FetcherReadyCallback就是 SourceGenerator ,依次SourceGenerator会回调到DecodeJob,依次回到EngineJob,最后到Target中,调用ImageView.setImageBitmap()。
总结
Glide使用了弱引用缓存、LruCache、DiskLruCache,底层默认利用了HttpUrlConnection加载数据资源,中间处理转换细节很复杂。
参考:
原创文章,作者:奋斗,如若转载,请注明出处:https://blog.ytso.com/6269.html