原文: https://blog.csdn.net/nbsp22/article/details/80666341

在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循环:

1. 由resourceClasses和sourceIds组成的一个正交关系，迭代每一组。
2. 迭代开始前，若modelLoaders为空或者size为0，则继续迭代进入步骤3，否则循环结束。
3. 循环中，检测是否已经全部迭代完成，如果还有，则进入步骤4，否则循环结束。
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中进行完成的。至此，宏观和微观上我们理清了加载的一个过程，后面我们会分析有关磁盘缓存的和对图片结果处理的一些小的细节。