Android Glide 缓存机制及源码全解

目录

Glide里的缓存

什么是三级缓存？

缓存机制

为何设计出活动缓存

加载流程

Glide源码

加载流程

LRU是什么

内存缓存的LRU

LruCache

往期回顾 

RecyclerView 绘制流程及Recycler缓存

Glide使用详解

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方法

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

  1. public  LoadStatus load(...) {
  2.     long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;
  3.  
  4.     EngineKey key =
  5.         keyFactory.buildKey(
  6.             model,
  7.             signature,
  8.             width,
  9.             height,
  10.             transformations,
  11.             resourceClass,
  12.             transcodeClass,
  13.             options);
  14.  
  15.     EngineResource memoryResource;
  16.     synchronized (this) {
  17.       memoryResource = loadFromMemory(key, isMemoryCacheable, startTime);
  18.  
  19.       if (memoryResource == null) {
  20.         return waitForExistingOrStartNewJob(...);
  21.       }
  22.     }
  23.  
  24.     // Avoid calling back while holding the engine lock, doing so makes it easier for callers to
  25.     // deadlock.
  26.     cb.onResourceReady(
  27.         memoryResource, DataSource.MEMORY_CACHE, /* isLoadedFromAlternateCacheKey= */ false);
  28.     return null;
  29.   }

        3.EngineKey

        An in memory only cache key used to multiplex loads.

        用于多路传输加载的仅内存缓存密钥.

  1.  EngineKey key =
  2.         keyFactory.buildKey(
  3.             ...);

        4.loadFromMemory

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

        5.loadFromActiveResources

        6.loadFromCache

        7.getEngineResourceFromCache

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

        8.waitForExistingOrStartNewJob

        咱弄个简化版

  1. private  LoadStatus waitForExistingOrStartNewJob(...) {
  2.     //通过添加和删除加载的回调并通知来管理加载的类
  3.     //加载完成时回调。
  4.     //咱都没数据肯定没加载完成，这个不管。急着往下看
  5.     EngineJob current = jobs.get(key, onlyRetrieveFromCache);
  6.     if (current != null) {
  7.       current.addCallback(cb, callbackExecutor);
  8.       if (VERBOSE_IS_LOGGABLE) {
  9.         logWithTimeAndKey("Added to existing load", startTime, key);
  10.       }
  11.       return new LoadStatus(cb, current);
  12.     }
  13.     //同上，接着向下看
  14.     EngineJob engineJob =
  15.         engineJobFactory.build(
  16.             key,
  17.             isMemoryCacheable,
  18.             useUnlimitedSourceExecutorPool,
  19.             useAnimationPool,
  20.             onlyRetrieveFromCache);
  21.     //负责从缓存数据或原始源解码资源的类，看着像，咱看看DecodeJob
  22.     //应用转换和代码转换。
  23.     DecodeJob decodeJob =
  24.         decodeJobFactory.build(
  25.             ...
  26.             engineJob);
  27.  
  28.     jobs.put(key, engineJob);
  29.  
  30.     engineJob.addCallback(cb, callbackExecutor);
  31.     engineJob.start(decodeJob);
  32.  
  33.     if (VERBOSE_IS_LOGGABLE) {
  34.       logWithTimeAndKey("Started new load", startTime, key);
  35.     }
  36.     return new LoadStatus(cb, engineJob);
  37.   }

        9.DecodeJob

  1. class DecodeJob
  2.     implements DataFetcherGenerator.FetcherReadyCallback,
  3.         Runnable,
  4.         Comparable>,
  5.         Poolable {
  6.   }
  7.   ...
  8.   //构造方法有个DiskCacheProvider看着跟磁盘缓存有关咱进去瞅瞅
  9.   DecodeJob(DiskCacheProvider diskCacheProvider, Pools.Pool> pool) {
  10.     this.diskCacheProvider = diskCacheProvider;
  11.     this.pool = pool;
  12.   }
  13.   ...

        10.DiskCacheProvider

        磁盘缓存实现的入口。

        在指定的内存中创建基于{@link com.bumptech.glide.disklrucache.disklrucache}的磁盘缓存。

        磁盘缓存目录。

  1. public class DiskLruCacheFactory implements DiskCache.Factory {
  2.   private final long diskCacheSize;
  3.   private final CacheDirectoryGetter cacheDirectoryGetter;
  4.  
  5.   /** 在UI线程外调用接口以获取缓存文件夹。 */
  6.   public interface CacheDirectoryGetter {
  7.     File getCacheDirectory();
  8.   }
  9.  
  10.   public DiskLruCacheFactory(final String diskCacheFolder, long diskCacheSize) {
  11.     this(
  12.         new CacheDirectoryGetter() {
  13.           @Override
  14.           public File getCacheDirectory() {
  15.             return new File(diskCacheFolder);
  16.           }
  17.         },
  18.         diskCacheSize);
  19.   }
  20.  
  21.   public DiskLruCacheFactory(
  22.       final String diskCacheFolder, final String diskCacheName, long diskCacheSize) {
  23.     this(
  24.         new CacheDirectoryGetter() {
  25.           @Override
  26.           public File getCacheDirectory() {
  27.             return new File(diskCacheFolder, diskCacheName);
  28.           }
  29.         },
  30.         diskCacheSize);
  31.   }
  32.  
  33. /**
  34. *使用此构造函数时，将调用{@link CacheDirectoryGetter#getCacheDirectory()}
  35. *UI线程，允许在不影响性能的情况下进行I/O访问。
  36. *在UI线程外调用@param cacheDirectoryGetter接口以获取缓存文件夹。
  37. *@param diskCacheSize LRU磁盘缓存所需的最大字节大小。
  38. */
  39.   // Public API.
  40.   @SuppressWarnings("WeakerAccess")
  41.   public DiskLruCacheFactory(CacheDirectoryGetter cacheDirectoryGetter, long diskCacheSize) {
  42.     this.diskCacheSize = diskCacheSize;
  43.     this.cacheDirectoryGetter = cacheDirectoryGetter;
  44.   }
  45.  
  46.   @Override
  47.   public DiskCache build() {
  48.     File cacheDir = cacheDirectoryGetter.getCacheDirectory();
  49.  
  50.     if (cacheDir == null) {
  51.       return null;
  52.     }
  53.  
  54.     if (cacheDir.isDirectory() || cacheDir.mkdirs()) {
  55.       return DiskLruCacheWrapper.create(cacheDir, diskCacheSize);
  56.     }
  57.  
  58.     return null;
  59.   }
  60. }

        11.DiskCache.Factory

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

  1. /** 用于向磁盘缓存写入数据和从磁盘缓存读取数据的接口 */
  2. public interface DiskCache {
  3.  
  4.   /** 用于创建磁盘缓存的接口 */
  5.   interface Factory {
  6.     /** 250 MB of cache. */
  7.     int DEFAULT_DISK_CACHE_SIZE = 250 * 1024 * 1024;
  8.  
  9.     String DEFAULT_DISK_CACHE_DIR = "image_manager_disk_cache";
  10.  
  11.     /** 返回新的磁盘缓存，如果无法创建磁盘缓存，则返回{@code null}*/
  12.     @Nullable
  13.     DiskCache build();
  14.   }
  15.  
  16.   /** 向磁盘缓存中的密钥实际写入数据的接口 */
  17.   interface Writer {
  18.   /**
  19.   *将数据写入文件
  20.   *如果写入操作应中止，则返回false。
  21.   *@param file写入程序应写入的文件。
  22.   */
  23.     boolean write(@NonNull File file);
  24.   }
  25.  
  26.   /**
  27.    *获取给定键处的值的缓存。
  28.    */
  29.   @Nullable
  30.   File get(Key key);
  31.  
  32.   /**
  33.   *@param key要写入的密钥。
  34.   *@param writer一个接口，该接口将在给定密钥输出流的情况下写入数据。
  35.    */
  36.   void put(Key key, Writer writer);
  37.   /**
  38.    * 从缓存中删除键和值。.
  39.    */
  40.   @SuppressWarnings("unused")
  41.   void delete(Key key);
  42.   /** Clear the cache. */
  43.   void clear();
  44. }

        磁盘缓存写入和读取的接口有了，那其他相关联的源码找到试着理解也是没问题的，再多找就乱了。

LRU是什么

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

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

内存缓存的LRU

  1. /** An LRU in memory cache for {@link com.bumptech.glide.load.engine.Resource}s. */
  2. public class LruResourceCache extends LruCache> implements MemoryCache {
  3.   private ResourceRemovedListener listener;
  4.   /**
  5.   *LruResourceCache的构造函数。
  6.   *@param size内存缓存可以使用的最大字节大小。
  7.   */
  8.   public LruResourceCache(long size) {
  9.     super(size);
  10.   }
  11.  
  12.   @Override
  13.   public void setResourceRemovedListener(@NonNull ResourceRemovedListener listener) {
  14.     this.listener = listener;
  15.   }
  16.  
  17.   @Override
  18.   protected void onItemEvicted(@NonNull Key key, @Nullable Resource item) {
  19.     if (listener != null && item != null) {
  20.       listener.onResourceRemoved(item);
  21.     }
  22.   }
  23.  
  24.   @Override
  25.   protected int getSize(@Nullable Resource item) {
  26.     if (item == null) {
  27.       return super.getSize(null);
  28.     } else {
  29.       return item.getSize();
  30.     }
  31.   }
  32.  
  33.   @SuppressLint("InlinedApi")
  34.   @Override
  35.   public void trimMemory(int level) {
  36.     if (level >= android.content.ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
  37.      //正在输入缓存的后台应用程序列表
  38.     //退出我们的整个Bitmap缓存
  39.       clearMemory();
  40.     } else if (level >= android.content.ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN
  41.         || level == android.content.ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL) {
  42.       // The app's UI is no longer visible, or app is in the foreground but system is running
  43.       // critically low on memory
  44.       // Evict oldest half of our bitmap cache
  45.       trimToSize(getMaxSize() / 2);
  46.     }
  47.   }
  48. }

LruCache

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

Map cache = new LinkedHashMap<>(100,0.75f, true):

  • 其中第二个参数0.75f表示加载因子，即容量达到75%的时候会把内存临时增加一倍。

  • 最后这个参数也至关重要，表示访问元素的排序方式，true表示按照访问顺序排序，false表示按败插入的顺序排序。

LruCache实现原理

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

往期回顾 

RecyclerView 绘制流程及Recycler缓存

Glide使用详解

注：本文转载自blog.csdn.net的帅次的文章"https://shuaici.blog.csdn.net/article/details/120015782"。版权归原作者所有，此博客不拥有其著作权，亦不承担相应法律责任。如有侵权，请联系我们删除。
复制链接
相关推荐
发表评论

评论记录：

未查询到任何数据！