Glide源码分析（六），缓存架构、存取命中分析

分析Glide缓存策略，我们还得从之前分析的Engine#load方法入手，这个方法中，展示了缓存读取的一些策略，我们继续贴上这块代码。

Engine#load

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) {
    Util.assertMainThread();
    long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;

    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);
      if (VERBOSE_IS_LOGGABLE) {
        logWithTimeAndKey("Loaded resource from active resources", startTime, key);
      }
      return null;
    }

    EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
    if (cached != null) {
      cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
      if (VERBOSE_IS_LOGGABLE) {
        logWithTimeAndKey("Loaded resource from cache", startTime, key);
      }
      return null;
    }

    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      current.addCallback(cb);
      if (VERBOSE_IS_LOGGABLE) {
        logWithTimeAndKey("Added to existing load", startTime, key);
      }
      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);

    jobs.put(key, engineJob);

    engineJob.addCallback(cb);
    engineJob.start(decodeJob);

    if (VERBOSE_IS_LOGGABLE) {
      logWithTimeAndKey("Started new load", startTime, key);
    }
    return new LoadStatus(cb, engineJob);
  }

涉及到的缓存类型如下：

内存和磁盘各自的两种缓存

ActiveResources缓存和MemoryCache，MemoryCache我们很好理解，就是Resouce在内存中的缓存，ActiveResources是什么意思呢，其实我们可以这样理解，类似多级缓存的概念，当然这里不是特别的适合，ActiveResources缓存和MemoryCache是同时存在的。ActiveResources缓存存放的是所有未被clear的Request请求到的Resource，这部分Resource会存放至ActiveResources缓存中，当Request被clear的时候，会把这部分在ActiveResources缓存中的Resource移动至MemoryCache中去，只有MemoryCache中能够命中，则这部分resource又会从MemoryCache移至ActiveResources缓存中去，到这里，相信大家能够明白ActiveResources了，其实相当于是对内存缓存再次做了一层，能够有效的提高访问速度，避免过多的操作MemoryCache，因为我们知道，MemoryCache中存放的缓存可能很多，这样的话，直接在上面做一层ActiveResources缓存显得就很有必要了。
DiskCache，磁盘缓存比较简单，其中也分为ResourceCacheKey与DataCacheKey，一个是已经decode过的可以之间供Target给到View去渲染的，另一个是还未decode过的，缓存的是源数据。磁盘缓存的保存是在第一次请求网络成功时候，会刷新磁盘缓存，此时处理的是源数据，至于是否会缓存decode过后的数据，取决于DiskCacheStrategy的策略。

结合前面所有文章，这里我再次简要梳理下资源加载的过程。

简要资源加载全过程

检查ActiveResources缓存中能否命中，若命中，则请求完成，通知Target渲染对应的View。若未命中，则进入Step2。
检查MemoryCache缓存能否命中，若命中，则请求完成，通知Target渲染对应的View。若未命中，则进入Step３。
构造或复用已有的EngineJob与DecodeJob，开始资源的加载，加载过程是ResourceCacheGenerator -> DataCacheGenerator -> SourceGenerator优先级顺序，不管哪种方式取到了数据，最终都会回调至DecodeJob中处理，区别在于SourceGenerator会更新磁盘缓存，此时的是DataCacheKey类型的缓存。进入步骤４。
４. DecodeJob回调中，一方面通过decodeFromData从DataFetcher中decode取到的原数据，转换为View能够展示的Resource，比如Drawable或Bitmap等，同时根据缓存策略，取决是否会构建ResourceCacheKey类型的缓存。decode这一步就已经结束，接下来会进行线程切换，最终切换到EngineJob的handleResultOnMainThread方法中，在这个方法中，会根据resource资源，构建一个非常重要的角色EngineResource，它是用来存放至ActiveResources缓存和MemoryCache中的，这里往ActiveResources缓存中put资源就是在此时回调至Engine的onEngineJobComplete中完成的。接下来就是回调至SingleRequest中的onResourceReady中去更新Target中View的渲染资源了。至此，全过程就已经结束。

内存缓存的要点

相信到这里，有同学已经意识到，这里并没有更新MemoryCache呢，难道此时不正是应该更新到内存缓存中去吗？这里什么时候一个资源才会put至MemoryCache呢，回到ActiveResources缓存中存放的EngineResource，它内部维护了一个计数，当计数减为0的时候，会触发一个callback，它里面的实现就是将EngineResource从ActiveResources缓存移动至MemoryCache，也就是put到MemoryCache的时机，为什么是这样呢？通过我仔细的细节分析，每一个加载的SingleRequest中有一个对应的EngineResource的引用，SingleRequest是与生命周期绑定的，当所属的请求上下文被onDestroy是，会通过其对应的RequestManager取消其所有的Request对象，而在Request的clear中则会调用Resource的recycle方法。此时就是EngineResource的recycle方法，因此，当生命周期onDestory被触发时，对应EngineResource计数会减为0，也就触发将EngineResource从ActiveResources缓存移动至MemoryCache。此时ActiveResources缓存会失效，同时我们可以看到MemoryCache命中时，恰恰会进行一个反向的操作，将EngineResource从MemoryCache重新移动至ActiveResources缓存。这里相信大家更明白了，为什么这里做了一个类似内存的二级缓存，也是Glide处于一种优化的考虑吧。下面我们再来分析下磁盘缓存DataCacheKey命中的情况。

磁盘缓存的命中

在Glide源码分析（五），EngineJob与DecodeJob代码详细加载过程一文中，我们看到资源加载成功缓存到磁盘上是在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);
}

这段代码逻辑相关比较好理解，根据loadData中的sourceKey以及签名信息，构造一个DataChcheKey类型的对象，而后将其put至磁盘缓存中，其中sourceKey就是我们加载资源的GlideUrl对象(https://p.upyun.com/docs/cloud/demo.jpg)。
磁盘缓存的具体实现我们已经了解，默认是由DiskLruCacheWrapper实现，具体功能就是将数据写入预先设置的缓存目录的文件下，以文件的方式存放。在分析D加载资源的详细过程中，我们知道Engine#load会先在内存中查找是否有缓存命中，否则会启动DecodeJob，在它中总共有三个DataFetchGenerator，这里和磁盘缓存相关的就是DataCacheGenerator，具体逻辑是在其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;
  }

我们假定内存缓存以及在激活的资源池中均没有命中，则此时会根据GlideUrl[https://p.upyun.com/docs/cloud/demo.jpg] 以它和签名组成的DataCacheKey，从DiskCache中去寻找这个缓存文件，DiskLruCacheWrapper#get方法实现如下：

@Override
 public File get(Key key) {
   String safeKey = safeKeyGenerator.getSafeKey(key);
   if (Log.isLoggable(TAG, Log.VERBOSE)) {
     Log.v(TAG, "Get: Obtained: " + safeKey + " for for Key: " + key);
   }
   File result = null;
   try {
     // It is possible that the there will be a put in between these two gets. If so that shouldn't
     // be a problem because we will always put the same value at the same key so our input streams
     // will still represent the same data.
     final DiskLruCache.Value value = getDiskCache().get(safeKey);
     if (value != null) {
       result = value.getFile(0);
     }
   } catch (IOException e) {
     if (Log.isLoggable(TAG, Log.WARN)) {
       Log.w(TAG, "Unable to get from disk cache", e);
     }
   }
   return result;
 }

可以看到，真正去根据key获取文件信息实际上是由getDiskCache().get方法去实现的，这里我们需要分析getDiskCache()的实现，也就是操作磁盘文件的类了。

private synchronized DiskLruCache getDiskCache() throws IOException {
   if (diskLruCache == null) {
     diskLruCache = DiskLruCache.open(directory, APP_VERSION, VALUE_COUNT, maxSize);
   }
   return diskLruCache;
 }

getDiskCache的实现也很明确，就是调用DiskLruCache的静态open方法，创建一个diskLruCache单例对象，方法入参directory表示缓存目录，maxSize缓存最大大小。open的实现如下：

public static DiskLruCache open(File directory, int appVersion, int valueCount, long maxSize)
      throws IOException {
    ...
    // Prefer to pick up where we left off.
    DiskLruCache cache = new DiskLruCache(directory, appVersion, valueCount, maxSize);
    if (cache.journalFile.exists()) {
      try {
        cache.readJournal();
        cache.processJournal();
        return cache;
      } catch (IOException journalIsCorrupt) {
        System.out
            .println("DiskLruCache "
                + directory
                + " is corrupt: "
                + journalIsCorrupt.getMessage()
                + ", removing");
        cache.delete();
      }
    }

    // Create a new empty cache.
    directory.mkdirs();
    cache = new DiskLruCache(directory, appVersion, valueCount, maxSize);
    cache.rebuildJournal();
    return cache;
  }

我们分析最简单的情况，如果在磁盘中有缓存文件了，显然此时if语句journalFile文件是存在的，因此，接下来调用readJournal根据缓存key将索引信息读入lruEntries中，每一个缓存key对应有一个Entry信息。Entry中保存缓存文件索引的是cleanFiles，cleanFiles虽然是一个File数组，但是目前glide对于这个数据的size是恒为１的，也就是缓存key,Entry,文件是一个一一对应的关系，这里glide用数组提供了将来一种可扩展性的预留实现。这样磁盘缓存索引也就建立完成。下面继续看DiskLruCache#get的实现

public synchronized Value get(String key) throws IOException {
   checkNotClosed();
   Entry entry = lruEntries.get(key);
   if (entry == null) {
     return null;
   }

   if (!entry.readable) {
     return null;
   }

   ...
   return new Value(key, entry.sequenceNumber, entry.cleanFiles, entry.lengths);
 }

还是分析简单的情况，这里就是在Entry索引中根据key信息查找，而后将结果返个DiskLruCacheWrapper，这里我们看到有entry.cleanFiles，。
entry.cleanFiles也就是对应在DataCacheGenerator中cacheFile的实例。因此整个在磁盘cache中查找文件的过程也就比较清楚了。再次看DataCacheGenerator中的startNext，此时cacheFile能够命中，因此会触发对应的modelLoader去从缓存中加载数据。

总结

这里我们介绍了内存缓存，ActiveResources与MemoryCache的命中情况分析，以及DiskCache的DataCacheKey的命中分析，DiskCach还有一个关于ResourceCacheKey的情况，相应的代码在ResourceCacheGenerator中，我们这里不再研究，也是一样的思路。这里再强调几点，DataCacheKey中缓存的是DataFetcher拉取的源数据，也就是原始的数据，ResourceCacheKey则是基于原始数据，做的一层更精细的缓存，从它们的构造方法中我们可以看到。

key =
    new ResourceCacheKey(
        decodeHelper.getArrayPool(),
        currentSourceKey,
        signature,
        width,
        height,
        appliedTransformation,
        resourceSubClass,
        options);

// DataCacheKey
key = new DataCacheKey(currentSourceKey, signature);

正如我们简单的例子，这里DataCacheKey只有网络的url决定，也即是一个数据流对象，不同的decode可以来扩展它，ResourceCacheKey就是这样一种缓存。至此，对于Glide的缓存架构我们就分析完了，整个系列差不多也接近尾声了，后面文章中，我会整理一些大纲的总线，供大家自己研读。

下一篇 Glide源码分析（七），总纲思路梳理