Glide源码分析(五),EngineJob与DecodeJob
在Glide源码分析(三),Engine加载资源过程文中,我们分析到Engine#load的最后一步,创建好了一对EngineJob和DecodeJob,随之调用EngineJob的start方法,启动加载任务。下面分析整个一个执行过程,文中相关情景下的方法特定调用的结果是还是基于一下这段code,虽然是由特殊入口,并不影响我们理解整个框架,反而是一个很好的突破口,理解代码的思想。示例代码如下:
Glide.with(this)
.load("https://p.upyun.com/docs/cloud/demo.jpg")
.into(imageView);
此时的情景就是加载一个普通的http url对象。下面我们开始分析,加载的起点,也就是从EngineJob#start开始。
1. EngineJob#start
public void start(DecodeJob<R> decodeJob) {
this.decodeJob = decodeJob;
GlideExecutor executor = decodeJob.willDecodeFromCache()
? diskCacheExecutor
: getActiveSourceExecutor();
executor.execute(decodeJob);
}
这个方法是根据当前条件,选取一个GlideExecutor,它实现了ExecutorService,然后由它去执行decodeJob。通过decodeJob的willDecodeFromCache方法,决定是使用哪一个。Glide里面,封装了很几种类型的线程池对象,这里无需深究哪个线程池这个细节。显然DecodeJob是一个Runnable对象,最终执行之后,都是触发DecodeJob的run方法。
2.DecodeJob#run
@Override
public void run() {
// This should be much more fine grained, but since Java's thread pool implementation silently
// swallows all otherwise fatal exceptions, this will at least make it obvious to developers
// that something is failing.
GlideTrace.beginSectionFormat("DecodeJob#run(model=%s)", model);
// Methods in the try statement can invalidate currentFetcher, so set a local variable here to
// ensure that the fetcher is cleaned up either way.
DataFetcher<?> localFetcher = currentFetcher;
try {
if (isCancelled) {
notifyFailed();
return;
}
runWrapped();
} catch (Throwable t) {
// Catch Throwable and not Exception to handle OOMs. Throwables are swallowed by our
// usage of .submit() in GlideExecutor so we're not silently hiding crashes by doing this. We
// are however ensuring that our callbacks are always notified when a load fails. Without this
// notification, uncaught throwables never notify the corresponding callbacks, which can cause
// loads to silently hang forever, a case that's especially bad for users using Futures on
// background threads.
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "DecodeJob threw unexpectedly"
+ ", isCancelled: " + isCancelled
+ ", stage: " + stage, t);
}
// When we're encoding we've already notified our callback and it isn't safe to do so again.
if (stage != Stage.ENCODE) {
throwables.add(t);
notifyFailed();
}
if (!isCancelled) {
throw t;
}
} finally {
// Keeping track of the fetcher here and calling cleanup is excessively paranoid, we call
// close in all cases anyway.
if (localFetcher != null) {
localFetcher.cleanup();
}
GlideTrace.endSection();
}
}
执行run方法时候,首先检查isCancelled标志位,它是一个volatile变量,保证了多线程之间的可见性,由此可知道DecodeJob是支持取消的。如果此时,已经被取消,则会调用notifyFailed方法,它里面主要是通过callback回调告知上层调用者,这里就是EngineJob,其二是清理和重置DecodeJob里面的一些资源。另外如果未被取消,如果有任何异常出现,则会进入catch方法块,也会看条件进行一些回调和清理资源,同时在finally代码块中,执行已经结束,localFetcher记录着当前的currentFetcher对象,这个时候会通知DataFetcher的cleanup清理资源,因为DecodeJob是可被复用的,显然第一次运行localFetcher是null,后面我们分析到了这个再具体看看它的用处。下面我们分析重点方法,runWapped这个的执行逻辑。
3. DecodeJon#runWapped
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 Stage getNextStage(Stage current) {
switch (current) {
case INITIALIZE:
return diskCacheStrategy.decodeCachedResource()
? Stage.RESOURCE_CACHE : getNextStage(Stage.RESOURCE_CACHE);
case RESOURCE_CACHE:
return diskCacheStrategy.decodeCachedData()
? Stage.DATA_CACHE : getNextStage(Stage.DATA_CACHE);
case DATA_CACHE:
// Skip loading from source if the user opted to only retrieve the resource from cache.
return onlyRetrieveFromCache ? Stage.FINISHED : Stage.SOURCE;
case SOURCE:
case FINISHED:
return Stage.FINISHED;
default:
throw new IllegalArgumentException("Unrecognized stage: " + current);
}
}
runWrapped中主要是根据runReason获取一个Stage状态对象,这里传入的current是Stage.INITIALIZE,diskCacheStrategy这个值是由RequestOptions传入,默认是DiskCacheStrategy.AUTOMATIC。因此,此时diskCacheStrategy.decodeCachedResource()为true,成员变量stage赋值为Stage.RESOURCE_CACHE。接下来调用getNextGenerator创建一个DataFetcherGenerator对象。
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);
}
}
getNextGenerator方法的实现很简单,就是根据stage的信息,返回相应的对象,这里我们的stage为Stage.RESOURCE_CACHE,因此此时currentGenerator就是一个ResourceCacheGenerator对象。再接着,在runWrapped方法中,调用了runGenerators,继续运行。
4.DecodeJob#runGenerators
private void runGenerators() {
currentThread = Thread.currentThread();
startFetchTime = LogTime.getLogTime();
boolean isStarted = false;
while (!isCancelled && currentGenerator != null
&& !(isStarted = currentGenerator.startNext())) {
stage = getNextStage(stage);
currentGenerator = getNextGenerator();
if (stage == Stage.SOURCE) {
reschedule();
return;
}
}
// We've run out of stages and generators, give up.
if ((stage == Stage.FINISHED || isCancelled) && !isStarted) {
notifyFailed();
}
// Otherwise a generator started a new load and we expect to be called back in
// onDataFetcherReady.
}
在runGenerators方法while循环中,先是检查isCancelled状态,一旦isCancelled为true或者isStarted为true,表明任务已经启动,整个循环就会结束。在接下来的判断中,stage状态为完成或者被取消并且任务没有启动,则直接notifyFailed,此次请求就已经失败。下面还是分析while条件,考虑未被取消的情况,DataFetcherGenerator#startNext表示是否成功启动了DataFetcher。
第一次循环currentGenerator为ResourceCacheGenerator,我们假设没有成功启动。再次进入getNextStage,这里传入的stage为Stage.RESOURCE_CACHE,因此返回下一个状态为Stage.DATA_CACHE,再看getNextGenerator,此时会根据stage返回DataCacheGenerator对象,循环继续。
第二次循环继续,currentGenerator为DataCacheGenerator,我们假设没有成功启动。再次进入getNextStage,这里传入的stage为Stage.DATA_CACHE,onlyRetrieveFromCache此时是false,因此返回下一个状态为Stage.SOURCE,再看getNextGenerator,此时会根据stage返回SourceGenerator对象,此时发现stage已经是Stage.SOURCE,内部循环被return,请求reschedule方法重新调度。
public void reschedule() {
runReason = RunReason.SWITCH_TO_SOURCE_SERVICE;
callback.reschedule(this);
}
这里将runReason置为RunReason.SWITCH_TO_SOURCE_SERVICE,回调至EngineJob的reschedule中。它的实现如下:
public void reschedule(DecodeJob<?> job) {
// Even if the job is cancelled here, it still needs to be scheduled so that it can clean itself
// up.
getActiveSourceExecutor().execute(job);
}
它的实现比较简单,就是请求source相关的线程池,继续执行这个job。显然DecodeJob的run方法又会再次被触发执行,runReason为RunReason.SWITCH_TO_SOURCE_SERVICE,stage为Stage.SOURCE。再次分析runWrapped中,此时会调用runGenerators继续执行逻辑。此时currentGenerator为SourceGenerator,进入while循环,我们假设调用startNext依然返回false,此时进入循环代码块,getNextStage会返回Stage.FINISHED,stage被置为Stage.FINISHED状态,获取下一个DataFetcherGenerator时会返回null,此时currentGenerator为null,因此while循环结束,加载也就结束。
整的来说,DecodeJob的run方法,会依次从ResourceCacheGenerator->DataCacheGenerator->SourceGenerator这样一个链执行,只要其中一个的startNext方法返回为
true,则不再寻找下一个Generator。现在我们来分析我们此时的具体情况。回到runGenerators第一次while循环的执行时机去。
5. ResourceCacheGenerator#startNext
@Override
public boolean startNext() {
List<Key> sourceIds = helper.getCacheKeys();
if (sourceIds.isEmpty()) {
return false;
}
List<Class<?>> resourceClasses = helper.getRegisteredResourceClasses();
if (resourceClasses.isEmpty()) {
if (File.class.equals(helper.getTranscodeClass())) {
return false;
}
// TODO(b/73882030): This case gets triggered when it shouldn't. With this assertion it causes
// all loads to fail. Without this assertion it causes loads to miss the disk cache
// unnecessarily
// throw new IllegalStateException(
// "Failed to find any load path from " + helper.getModelClass() + " to "
// + helper.getTranscodeClass());
}
while (modelLoaders == null || !hasNextModelLoader()) {
resourceClassIndex++;
if (resourceClassIndex >= resourceClasses.size()) {
sourceIdIndex++;
if (sourceIdIndex >= sourceIds.size()) {
return false;
}
resourceClassIndex = 0;
}
Key sourceId = sourceIds.get(sourceIdIndex);
Class<?> resourceClass = resourceClasses.get(resourceClassIndex);
Transformation<?> transformation = helper.getTransformation(resourceClass);
// PMD.AvoidInstantiatingObjectsInLoops Each iteration is comparatively expensive anyway,
// we only run until the first one succeeds, the loop runs for only a limited
// number of iterations on the order of 10-20 in the worst case.
currentKey =
new ResourceCacheKey(// NOPMD AvoidInstantiatingObjectsInLoops
helper.getArrayPool(),
sourceId,
helper.getSignature(),
helper.getWidth(),
helper.getHeight(),
transformation,
resourceClass,
helper.getOptions());
cacheFile = helper.getDiskCache().get(currentKey);
if (cacheFile != null) {
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;
}
这里,参考DecodeHelper类相关方法分析,此时通过decodeHelper拿到的sourceIds就是[GlideUrl,ObjectKey],如果通过注册的信息找不到此时的key,表明glide本身还不支持这种方式,因此调用结束。显然此时是支持的,接下来是通过helper的getRegisteredResourceClasses获取resourceClass信息,这里大致是glide所支持的资源类信息,也就是能够进行decode的。这里它存放的是[GifDrawable,Bitmap,BitmapDrawable]。因此接下来进入第一个的while循环:
- 由resourceClasses和sourceIds组成的一个正交关系,迭代每一组。
- 迭代开始前,若modelLoaders为空或者size为0,则继续迭代进入步骤3,否则循环结束。
- 循环中,检测是否已经全部迭代完成,如果还有,则进入步骤4,否则循环结束。
- 对每一组,获取相应的缓存Key对象,根据缓存key去diskcache中查找缓存文件,查找成功,则通过getModelLoaders获取当前的modelLoaders信息,继续执行循环,进入步骤2。
从这里我们可以看出这个while循环的作用就是找到modelLoaders信息,如果没找到有效的,则循环结束,方法块正交组迭代完成之后,startNext方法结束,方法返回false,交给下一个Generator去处理。如果能够找到,则执行下一个while循环。这个循环相对简单一些,就是根据上一个while循环查找到的modelLoaders,进行遍历,只要有一个对应的fetcher能够处理,则startNext返回true,表明此时这个generator已经能够处理本次请求,所以也不会再交给其他的generator对应的fetcher去处理了。
在我们此时的情景中,ResourceCacheGenerator是无法处理本次请求的,所以,交给下一个Generator去处理,也就是DataCacheGenerator的startNext。
6. DataCacheGenerator#startNext
@Override
public boolean startNext() {
while (modelLoaders == null || !hasNextModelLoader()) {
sourceIdIndex++;
if (sourceIdIndex >= cacheKeys.size()) {
return false;
}
Key sourceId = cacheKeys.get(sourceIdIndex);
// PMD.AvoidInstantiatingObjectsInLoops The loop iterates a limited number of times
// and the actions it performs are much more expensive than a single allocation.
@SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")
Key originalKey = new DataCacheKey(sourceId, helper.getSignature());
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;
}
看过了ResourceCacheGenerator的startNext方法之后,这个方法也就很好理解了,唯独区别是这里构造的是DataCacheKey,其实也是它们的区别:
- ResourceCacheGenerator
DataFetcherGenerator实现类,从包含缩减采样/转换资源数据的缓存文件生成DataFetchers{@link com.bumptech.glide.load.data.DataFetcher}。 - DataCacheGenerator
DataFetcherGenerator实现类,从包含原始未修改源数据的缓存文件生成DataFetchers{@link com.bumptech.glide.load.data.DataFetcher}。
当第一次从网络加载图片时,缓存文件肯定是不存在的,所以,此时的startNext仍然返回false。因此交给下一个generator去处理,也就是SourceGenerator的startNext,而且我们也会看到,SourceGenerator加载成功之后,是会更新缓存信息的,带着这个问题继续分析。
7. SourceGenerator#startNext
@Override
public boolean startNext() {
if (dataToCache != null) {
Object data = dataToCache;
dataToCache = null;
cacheData(data);
}
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为空,因此跳过缓存,直接过渡到while循环中,循环负责取当前model相关(这里是一个http url)的所有支持的modelLoaders,这里helper.getLoadData()的内容如下,在DecodeHelper中有过相关的分析,这里直接给出结果。
LoadData -> MultFetcher[HttpUrlFetcher, HttpUrlFecter]
LoadData -> AssetFileDescriptorLocalUriFetcher
遍历LoadData,这里getDiskCacheStrategy默认返回的DiskCacheStrategy.AUTOMATIC,fetcher.getDataSource的实现如下:
在MultFetcher的实现
@Override
public DataSource getDataSource() {
return fetchers.get(0).getDataSource();
}
在HttpUrlFetcher中的实现
@Override
public DataSource getDataSource() {
return DataSource.REMOTE;
}
在AssetFileDescriptorLocalUriFetcher中的实现
@Override
public DataSource getDataSource() {
return DataSource.LOCAL;
}
DiskCacheStrategy.AUTOMATIC的isDataCacheable实现
@Override
public boolean isDataCacheable(DataSource dataSource) {
return dataSource == DataSource.REMOTE;
}
因此,在这里循环遍历中只有第一个LoadData MultFetcher[HttpUrlFetcher, HttpUrlFecter]是能够满足条件的,这个时候,调用MultFetcher的loadData方法去请求数据,在MultFetcher中,包含了多个fetchers,它们会一个个的一次去请求,一个顺序的队列,只要有一个成功了,则不会执行下一个fetcher。此时请求被触发,最后请求成功或失败会在DataFetcher.DataCallback的回调中得到响应。失败了很简单,一步步告知上层,也就结束了,我们看看成功的情况。即SourceGenerator#onDataReady
8. SourceGenerator#onDataReady
@Override
public void onDataReady(Object data) {
DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
dataToCache = data;
// We might be being called back on someone else's thread. Before doing anything, we should
// reschedule to get back onto Glide's thread.
cb.reschedule();
} else {
cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
loadData.fetcher.getDataSource(), originalKey);
}
}
在这个方法中,先是判断数据是否能够被缓存,如果能,则为成员变量dataToCache赋值,前面已经提到,SourceGenerator的startNext分为两部分,此时的dataToCache便是用于去缓存数据了,反之如果不能被缓存,则直接将结果继续抛给上层调用者去处理即可。这里,我们的loadData.fetcher是MultFetcher[HttpUrlFetcher, HttpUrlFecter],因此if语句条件成立,此时会进行缓存的操作,这个时候会请求DecodeJob Callback的reschedule重新调度,和前面所讲的在DecodeJob的reschedule一致,因此,DecodeJob会被再次调度,run方法也会再次执行,此时只会触发SourceGenerator#startNext再次执行,也就是第一部分缓存逻辑会得到执行,因此此时dataToCache是有数据的。再次回到SourceGenerator#startNext
9. SourceGenerator#startNext
@Override
public boolean startNext() {
if (dataToCache != null) {
Object data = dataToCache;
dataToCache = null;
cacheData(data);
}
if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {
return true;
}
sourceCacheGenerator = null;
....
}
此时dataToCache非空,进入if语句最后执行cacheData去做缓存数据的操作,同时将dataToCache置空,因为在一次请求过程中,SourceGenerator是复用的,比如熄屏等请求可能被打断,所以是需要维护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());
originalKey = new DataCacheKey(loadData.sourceKey, helper.getSignature());
helper.getDiskCache().put(originalKey, writer);
if (Log.isLoggable(TAG, Log.VERBOSE)) {
Log.v(TAG, "Finished encoding source to cache"
+ ", key: " + originalKey
+ ", data: " + dataToCache
+ ", encoder: " + encoder
+ ", duration: " + LogTime.getElapsedMillis(startTime));
}
} finally {
loadData.fetcher.cleanup();
}
sourceCacheGenerator =
new DataCacheGenerator(Collections.singletonList(loadData.sourceKey), helper, this);
}
cacheData中主要是两件事情,一是缓存当前的数据,用DataCacheKey的缓存key形式缓存了当前加载的数据,这里的我们可以看到,originalKey是和url相关的。然后是实例化sourceCacheGenerator,这里着重注意下,此时的DataCacheGenerator的FetcherReadyCallback传入的是当前this对象,这里也就是SourceGenerator。之前我一直不明白为什么SourceGenerator也实现了FetcherReadyCallback接口,除此之外DecodeJob也实现了此接口,看到这里,一下就明朗了,它是给这里的sourceCacheGenerator的回调使用的。代码继续分析,将数据缓存至磁盘之后,接下来sourceCacheGenerator非空,因此调用其startNext方法。再次回到DataCacheGenerator的startNext此时由于已经存在缓存,最终能够取到相关数据。最后由它的FetcherReadyCallback回调至SourceGenerator中的onDataFetcherReady方法。其实现如下:
@Override
public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,
DataSource dataSource, Key attemptedKey) {
// This data fetcher will be loading from a File and provide the wrong data source, so override
// with the data source of the original fetcher
cb.onDataFetcherReady(sourceKey, data, fetcher, loadData.fetcher.getDataSource(), sourceKey);
}
它里面的实现也很简单,就是将结果继续往上层抛,这里的FetcherReadyCallback cb正是由DecodeJob实现的。因此,最后的结果被回调至DecodeJob中进行处理。此时,代码分析部分差不多也就结束了,后面的都是层层回调,由DecodeJon->EngineJob->Target中,最后由Target操作ImageView,将资源渲染到View上面。
总结
总的来说,glide加载过程就是由EngineJob触发DecodeJob,DecodeJob中会有ResourceCacheGenerator->DataCacheGenerator->SourceGenerator对应的ModelLoaders与ModelFetchers依次处理,如果是SourceGenerator则还会更新缓存,这三个不是说一定都会有的,如果有缓存存在且能命中,则不会经历SourceGenerator阶段。在DecodeJob中获取到数据之后,则会层层上报,由Fetcher->Generator->DecodeJob->EngineJob->SingleRequest->Target这样一个序列回调,我们知道Android只有主线程才能操作ui,这里线程切换部分是在EngineJob中进行完成的。至此,宏观和微观上我们理清了加载的一个过程,后面我们会分析有关磁盘缓存的和对图片结果处理的一些小的细节。