Android Glide 缓存机制及源码

3,068 阅读10分钟

Glide里的缓存

默认情况下,Glide 会在开始一个新的图片请求之前检查以下多级的缓存:

  • 活动资源 (Active Resources) - 现在是否有另一个 View 正在展示这张图片?
  • 内存缓存 (Memory cache) - 该图片是否最近被加载过并仍存在于内存中?
  • 资源类型(Resource) - 该图片是否之前曾被解码、转换并写入过磁盘缓存?
  • 数据来源 (Data) - 构建这个图片的资源是否之前曾被写入过文件缓存?

前两步检查图片是否在内存中,如果是则直接返回图片。后两步则检查图片是否在磁盘上,以便快速但异步地返回图片。

如果四个步骤都未能找到图片,则Glide会返回到原始资源以取回数据(原始文件,Uri, Url等)。

什么是三级缓存?

  • 内存缓存:优先加载,速度最快
  • 本地缓存:其次加载,速度快
  • 网络缓存:最后加载,速度慢,浪费流量

缓存机制

Glide使用了ActiveResources(活动缓存弱引用)+MemoryCache(内存缓存Lru算法)+DiskCache(磁盘缓存Lru算法)。

  • ActiveResources:存储当前界面使用到的图片。界面不展示后,该Bitmap又被缓存至MemoryCache中,并从ActiveResources中删除。

  • Memory Cache:存储当前没有使用到的Bitmap,当MemoryCache中得到Bitmap后,该Bitmap又被缓存至ActiveResources中,并从MemoryCache中删除。

  • Disk Cache:持久缓存。例如图片加圆角,处理后图片会被缓存到文件中,应用被再次打开时可以加载缓存直接使用。

注意: ActiveResources + MemoryCache是内存缓存,都属于运行时缓存且互斥(同一张图片不会同时缓存在ActiveResources+MemoryCache),应用被杀死后将不存在。

Glide 内部是使用 LruCache、弱引用和硬盘缓存实现的。 Glide 主要将缓存分为两块内存缓存和硬盘缓存,两种缓存的结合,构成了 Glide 缓存机制的核心。

为何设计出活动缓存

因为内存缓存使用LRU算法,当你使用Gilde加载并显示第一张图片时,后面又加载了很多图片,同时你的第一张图片还在用。这个时候内存缓存根据LRU算法可能会删除你正在使用的第一张照片。这样的后果就是你正在使用的照片找不到,后果就是程序崩溃。

加载流程

流程就是这么个流程下面咱们通过源码加深一下。

Glide源码

加载流程

1.Engine类

负责启动加载并管理活动资源和缓存资源,它里面有个load方法。没错就是提供路径加载图片的方法。

2.load方法

这个方法里面满满的干货。

public <R> LoadStatus load(...) {
    long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;

    EngineKey key =
        keyFactory.buildKey(
            model,
            signature,
            width,
            height,
            transformations,
            resourceClass,
            transcodeClass,
            options);

    EngineResource<?> memoryResource;
    synchronized (this) {
      memoryResource = loadFromMemory(key, isMemoryCacheable, startTime);

      if (memoryResource == null) {
        return waitForExistingOrStartNewJob(...);
      }
    }

    // Avoid calling back while holding the engine lock, doing so makes it easier for callers to
    // deadlock.
    cb.onResourceReady(
        memoryResource, DataSource.MEMORY_CACHE, /* isLoadedFromAlternateCacheKey= */ false);
    return null;
  }

3.EngineKey

An in memory only cache key used to multiplex loads.(用于多路传输加载的仅内存缓存密钥)

 EngineKey key =
        keyFactory.buildKey(
            ...);

4.loadFromMemory

根据上面load方法提供咱们来看看loadFromMemory()这个是重点;

5.loadFromActiveResources

6.loadFromCache

7.getEngineResourceFromCache

到这里如有还未找到,那就说明该图片未保存至内存缓存中来。咱继续往下走,顺着源码跑。

8.waitForExistingOrStartNewJob

咱弄个简化版

private <R> LoadStatus waitForExistingOrStartNewJob(...) {
    //通过添加和删除加载的回调并通知来管理加载的类
    //加载完成时回调。
    //咱都没数据肯定没加载完成,这个不管。急着往下看
    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
    if (current != null) {
      current.addCallback(cb, callbackExecutor);
      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
    //应用转换和代码转换。
    DecodeJob<R> decodeJob =
        decodeJobFactory.build(
            ...
            engineJob);

    jobs.put(key, engineJob);

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

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

9.DecodeJob

class DecodeJob<R>
    implements DataFetcherGenerator.FetcherReadyCallback,
        Runnable,
        Comparable<DecodeJob<?>>,
        Poolable {
  }
  ...
  //构造方法有个DiskCacheProvider看着跟磁盘缓存有关咱进去瞅瞅
  DecodeJob(DiskCacheProvider diskCacheProvider, Pools.Pool<DecodeJob<?>> pool) {
    this.diskCacheProvider = diskCacheProvider;
    this.pool = pool;
  }
  ...

10.DiskCacheProvider

磁盘缓存实现的入口。

在指定的内存中创建基于 disklrucache 的磁盘缓存。

磁盘缓存目录。

public class DiskLruCacheFactory implements DiskCache.Factory {
  private final long diskCacheSize;
  private final CacheDirectoryGetter cacheDirectoryGetter;

  /** 在UI线程外调用接口以获取缓存文件夹。 */
  public interface CacheDirectoryGetter {
    File getCacheDirectory();
  }

  public DiskLruCacheFactory(final String diskCacheFolder, long diskCacheSize) {
    this(
        new CacheDirectoryGetter() {
          @Override
          public File getCacheDirectory() {
            return new File(diskCacheFolder);
          }
        },
        diskCacheSize);
  }

  public DiskLruCacheFactory(
      final String diskCacheFolder, final String diskCacheName, long diskCacheSize) {
    this(
        new CacheDirectoryGetter() {
          @Override
          public File getCacheDirectory() {
            return new File(diskCacheFolder, diskCacheName);
          }
        },
        diskCacheSize);
  }

/**
*使用此构造函数时,将调用getCacheDirectory
*UI线程,允许在不影响性能的情况下进行I/O访问。
*在UI线程外调用@param cacheDirectoryGetter接口以获取缓存文件夹。
*@param diskCacheSize LRU磁盘缓存所需的最大字节大小。
*/
  // Public API.
  @SuppressWarnings("WeakerAccess")
  public DiskLruCacheFactory(CacheDirectoryGetter cacheDirectoryGetter, long diskCacheSize) {
    this.diskCacheSize = diskCacheSize;
    this.cacheDirectoryGetter = cacheDirectoryGetter;
  }

  @Override
  public DiskCache build() {
    File cacheDir = cacheDirectoryGetter.getCacheDirectory();

    if (cacheDir == null) {
      return null;
    }

    if (cacheDir.isDirectory() || cacheDir.mkdirs()) {
      return DiskLruCacheWrapper.create(cacheDir, diskCacheSize);
    }

    return null;
  }
}

11.DiskCache.Factory###

DiskLruCacheFactory实现的接口是什么,咱看看

/** 用于向磁盘缓存写入数据和从磁盘缓存读取数据的接口 */
public interface DiskCache {

  /** 用于创建磁盘缓存的接口 */
  interface Factory {
    /** 250 MB of cache. */
    int DEFAULT_DISK_CACHE_SIZE = 250 * 1024 * 1024;

    String DEFAULT_DISK_CACHE_DIR = "image_manager_disk_cache";

    /** 返回新的磁盘缓存,如果无法创建磁盘缓存,则返回{@code null}*/
    @Nullable
    DiskCache build();
  }

  /** 向磁盘缓存中的密钥实际写入数据的接口 */
  interface Writer {
  /**
  *将数据写入文件
  *如果写入操作应中止,则返回false。
  *@param file写入程序应写入的文件。
  */
    boolean write(@NonNull File file);
  }

  /**
   *获取给定键处的值的缓存。
   */
  @Nullable
  File get(Key key);

  /**
  *@param key要写入的密钥。
  *@param writer一个接口,该接口将在给定密钥输出流的情况下写入数据。
   */
  void put(Key key, Writer writer);
  /**
   * 从缓存中删除键和值。.
   */
  @SuppressWarnings("unused")
  void delete(Key key);
  /** Clear the cache. */
  void clear();
}

磁盘缓存写入和读取的接口有了,那么你可以使用Generated API进行磁盘缓存设置你定义的缓存。这里把磁盘缓存介绍完了。

12.engineJob.start()

DecodeJob 构建的磁盘缓存搞定了,咱们急着看看。

  //8.waitForExistingOrStartNewJob
  engineJob.start(decodeJob);

  public synchronized void start(DecodeJob<R> decodeJob) {
    this.decodeJob = decodeJob;
    GlideExecutor executor =
        decodeJob.willDecodeFromCache() ? diskCacheExecutor : getActiveSourceExecutor();
    executor.execute(decodeJob);
  }

DecodeJob是一个运行在子线程的Runnable。所以接着调用engineJob.start方法运行decodeJob的run方法。

13.DecodeJob

  • 在DecodeJob的run方法中调用了runWrapped方法。
  • 然后得到了SourceGenerator。
  • 接着调用了getNextGenerator和runGenerators方法。
  • 在runGenerators方法中调用currentGenerator.startNext方法。
  @Override
  public void run() {
    try {
      ...
      runWrapped();
    } ...
  }
  //在init方法中:
  //this.runReason = RunReason.INITIALIZE;
  private void runWrapped() {
    switch (runReason) {
      case INITIALIZE:
        stage = getNextStage(Stage.INITIALIZE);
        currentGenerator = getNextGenerator();
        runGenerators();
        break;
      ...
    }
  }
  
  private void runGenerators() {
    while (!isCancelled
        && currentGenerator != null
        && !(isStarted = currentGenerator.startNext())) {
      ...
    }
   ...
  }

跟踪DataFetcherGenerator接口的实现类SourceGenerator。

14.SourceGenerator.startNext()

private volatile ModelLoader.LoadData<?> loadData;
  public boolean startNext() {
    ...
    loadData = null;
    boolean started = false;
    while (!started && hasNextModelLoader()) {
      //注释一:获取loadData
      loadData = helper.getLoadData().get(loadDataListIndex++);
      if (loadData != null
          && (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
              || helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
        started = true;
        //注释二:启动资源的加载
        startNextLoad(loadData);
      }
    }
    return started;
  }

15.DecodeHelper.getLoadData()

  List<LoadData<?>> getLoadData() {
    if (!isLoadDataSet) {
      isLoadDataSet = true;
      loadData.clear();
      List<ModelLoader<Object, ?>> modelLoaders = glideContext.getRegistry().getModelLoaders(model);
      for (int i = 0, size = modelLoaders.size(); i < size; i++) {
        ModelLoader<Object, ?> modelLoader = modelLoaders.get(i);
        LoadData<?> current = modelLoader.buildLoadData(model, width, height, options);
        if (current != null) {
          loadData.add(current);
        }
      }
    }
    return loadData;
  }

从这里看出loadData是个List,而且DecodeHelper内部做了缓存。它的加载逻辑是先用model(我们load传入的url)从glideContext查询ModelLoader列表,然后遍历它去buildLoadData添加loadData。

Registry.getModelLoaders

  @NonNull
  public <Model> List<ModelLoader<Model, ?>> getModelLoaders(@NonNull Model model) {
    return modelLoaderRegistry.getModelLoaders(model);
  }

modelLoaderRegistry会根据model的class查询modelLoaders列表,然后遍历它去使用ModelLoader.handles方法判断这个ModelLoader是否支持这个model,如果是的再放到filteredLoaders里面一起返回。

ModelLoaderRegistry.getModelLoaders

  public <A> List<ModelLoader<A, ?>> getModelLoaders(@NonNull A model) {
    List<ModelLoader<A, ?>> modelLoaders = getModelLoadersForClass(getClass(model));
    ...
    int size = modelLoaders.size();
    boolean isEmpty = true;
    List<ModelLoader<A, ?>> filteredLoaders = Collections.emptyList();
    for (int i = 0; i < size; i++) {
      ModelLoader<A, ?> loader = modelLoaders.get(i);
      if (loader.handles(model)) {
        if (isEmpty) {
          filteredLoaders = new ArrayList<>(size - i);
          isEmpty = false;
        }
        filteredLoaders.add(loader);
      }
    }
    if (filteredLoaders.isEmpty()) {
      throw new NoModelLoaderAvailableException(model, modelLoaders);
    }
    return filteredLoaders;
  }

得到的ModelLoader回到到DecodeHelper.getLoadData去buildLoadData创建LoadData,就得到了一个LoadData列表。

16.SourceGenerator.startNextLoad()

SourceGenerator.startNext里面就会遍历这个列表去找到一个能加载资源的LoadData,其中主要干活的是DataFetcher。

public final DataFetcher<Data> fetcher;
    
  private void startNextLoad(final LoadData<?> toStart) {
    loadData.fetcher.loadData(
        helper.getPriority(),
        new DataCallback<Object>() {
          @Override
          public void onDataReady(@Nullable Object data) {
            if (isCurrentRequest(toStart)) {
              onDataReadyInternal(toStart, data);
            }
          }

          @Override
          public void onLoadFailed(@NonNull Exception e) {
            if (isCurrentRequest(toStart)) {
              onLoadFailedInternal(toStart, e);
            }
          }
        });
  }

通过DataCallback接口找到其实现类 HttpUrlFetcher。

17.HttpUrlFetcher.loadData()

  @Override
  public void loadData(
      @NonNull Priority priority, @NonNull DataCallback<? super InputStream> callback) {
    long startTime = LogTime.getLogTime();
    try {
      InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
      //回调SourceGenerator.startNextLoad里面的onDataReady
      callback.onDataReady(result);
    } 
  }
  
  
  private InputStream loadDataWithRedirects(
      URL url, int redirects, URL lastUrl, Map<String, String> headers) throws HttpException {
        urlConnection = buildAndConfigureConnection(url, headers);
    try {
      stream = urlConnection.getInputStream();
    } catch (IOException e) {
    }

    if (isCancelled) {
      return null;
    }

    final int statusCode = getHttpStatusCodeOrInvalid(urlConnection);
    if (isHttpOk(statusCode)) {
      return getStreamForSuccessfulRequest(urlConnection);
    ...
  }
  
  
  private InputStream getStreamForSuccessfulRequest(HttpURLConnection urlConnection)
      throws HttpException {
      ...
      if (TextUtils.isEmpty(urlConnection.getContentEncoding())) {
        int contentLength = urlConnection.getContentLength();
        stream = ContentLengthInputStream.obtain(urlConnection.getInputStream(), contentLength);
      } else {
        stream = urlConnection.getInputStream();
      }
      ...
    return stream;
  }

HttpUrlFetcher.loadData()加载完成并不是把图片文件下载完成,只是打开了文件流而已,通过回调将文件流传递给SourceGenerator.startNextLoad()。

18.SourceGenerator.onDataReadyInternal()

  void onDataReadyInternal(LoadData<?> loadData, Object data) {
    DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
    if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
      dataToCache = data;
      cb.reschedule();
    } else {
      cb.onDataFetcherReady(
          loadData.sourceKey,
          data,
          loadData.fetcher,
          loadData.fetcher.getDataSource(),
          originalKey);
    }
  }

调用DecodeJob.onDataFetcherReady回到DecodeJob,然后通过decodeFromFetcher方法获取LoadPath实例对象进行解码。

19.LoadPath

  public Resource<Transcode> load(
      DataRewinder<Data> rewinder,
      @NonNull Options options,
      int width,
      int height,
      DecodePath.DecodeCallback<ResourceType> decodeCallback)
      throws GlideException {
    List<Throwable> throwables = Preconditions.checkNotNull(listPool.acquire());
    try {
      return loadWithExceptionList(rewinder, options, width, height, decodeCallback, throwables);
    } finally {
      listPool.release(throwables);
    }
  }
  
    private Resource<Transcode> loadWithExceptionList(
      DataRewinder<Data> rewinder,
      @NonNull Options options,
      int width,
      int height,
      DecodePath.DecodeCallback<ResourceType> decodeCallback,
      List<Throwable> exceptions)
      throws GlideException {
    Resource<Transcode> result = null;
    for (int i = 0, size = decodePaths.size(); i < size; i++) {
      DecodePath<Data, ResourceType, Transcode> path = decodePaths.get(i);
      try {
        result = path.decode(rewinder, width, height, options, decodeCallback);
      } catch (GlideException e) {
        exceptions.add(e);
      }
    }
    return result;
  }

LRU是什么

LRU是近期最少使用的算法(缓存淘汰算法),它的核心思想是当缓存满时,会优先淘汰那些近期最少使用的缓存对象。采用LRU算法的缓存有两种:LrhCache和DisLruCache,分别用于实现内存缓存和硬盘缓存,其核心思想都是LRU缓存算法。

LruCache的核心思想很好理解,就是要维护一个缓存对象列表,其中对象列表的排列方式是按照访问顺序实现的,即一直没访问的对象,将放在队尾,即将被淘汰。而最近访问的对象将放在队头,最后被淘汰。

内存缓存的LRU

/** An LRU in memory cache for {@link com.bumptech.glide.load.engine.Resource}s. */
public class LruResourceCache extends LruCache<Key, Resource<?>> implements MemoryCache {
  private ResourceRemovedListener listener;
  /**
  *LruResourceCache的构造函数。
  *@param size内存缓存可以使用的最大字节大小。
  */
  public LruResourceCache(long size) {
    super(size);
  }

  @Override
  public void setResourceRemovedListener(@NonNull ResourceRemovedListener listener) {
    this.listener = listener;
  }

  @Override
  protected void onItemEvicted(@NonNull Key key, @Nullable Resource<?> item) {
    if (listener != null && item != null) {
      listener.onResourceRemoved(item);
    }
  }

  @Override
  protected int getSize(@Nullable Resource<?> item) {
    if (item == null) {
      return super.getSize(null);
    } else {
      return item.getSize();
    }
  }

  @SuppressLint("InlinedApi")
  @Override
  public void trimMemory(int level) {
    if (level >= android.content.ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
     //正在输入缓存的后台应用程序列表
    //退出我们的整个Bitmap缓存
      clearMemory();
    } else if (level >= android.content.ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN
        || level == android.content.ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL) {
      // The app's UI is no longer visible, or app is in the foreground but system is running
      // critically low on memory
      // Evict oldest half of our bitmap cache
      trimToSize(getMaxSize() / 2);
    }
  }
}

LruCache

存在一个LinkedHashMap存放数据,并且实现了LRU(最少使用算法)缓存策略。

Map<T,Y> cache = new LinkedHashMap<>(100,0.75f, true):
  • 其中第二个参数0.75f表示加载因子,即容量达到75%的时候会把内存临时增加一倍。
  • 最后这个参数也至关重要,表示访问元素的排序方式,true表示按照访问顺序排序,false表示按败插入的顺序排序。

LruCache实现原理

利用了LinkedHashMap排序方式的特性:由于使用访问顺序排序,进行了get/put操作的元素会放在Map最后面。所以当最后一个元素插入进来时,如果当前的缓存数据大小超过了最大限制,那么会删除Map中放在前面的元素。

Java的四种引用方式

1.强引用(StrongReference)

  • 使用最普遍的引用
  • 只要引用链没有断开,强引用就不会断开。- 当内存空间不足,抛出OutOfMemoryError终止程序也不会回收具有强引用的对象。
  • 通过将对象设置为null来弱化引用,使其被回收
Object object = new Object();
String str = "scc";
//都是强引用

2.软引用(SoftReference)

  • 对象处在有用但非必须的状态
  • 只有当内存空间不足时, GC会回收该引用的对象的内存。
  • 可以用来实现高速缓存(作用)--比如网页缓存、图片缓存
// 注意:wrf这个引用也是强引用,它是指向SoftReference这个对象的,
// 这里的软引用指的是指向new String("str")的引用,也就是SoftReference类中T
SoftReference<String> wrf = new SoftReference<String>(new String("str"));

3.弱引用(WeakReference)

弱引用就是只要JVM垃圾回收器发现了它,就会将之回收。

  • 非必须的对象,比软引用更弱一-些
  • GC时会被回
  • 被回收的概率也不大,因为GC线程优先级比较低
  • 适用于引用偶尔被使用且不影响垃圾收集的对象 使用:
Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>();
//ResourceWeakReference弱引用

4.虚引用(PhantomReference)

  • 不会决定对象的生命周期
  • 任何时候都可能被垃圾收集器回收
  • 跟踪对象被垃圾收集器回收的活动,起哨兵作用
  • 必须和引用队列ReferenceQueue联合使用

当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会把这个虚引用加入到与之 关联的引用队列中。

程序可以通过判断引用队列中是否已经加入了虚引用,来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列,那么就可以在所引用的对象的内存被回收之前采取必要的行动。

Object obj = new Object();
ReferenceQueue queue = new ReferenceQueue();
PhantomReference reference = new PhantomReference(obj, queue);
//强引用对象滞空,保留软引用
obj = null;

引用队列(ReferenceQueue)

  • 无实际存储结构,存储逻辑依赖于内部节点之间的关系来表达
  • 存储关联的且被GC的软引用,弱引用以及虚引用

image.png

往期回顾

一文轻松搞定Glide使用

架构MVC MVP MVVM

uses-permission和permission