在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中进行完成的。至此，宏观和微观上我们理清了加载的一个过程，后面我们会分析有关磁盘缓存的和对图片结果处理的一些小的细节。
