Android Glide 缓存机制及源码

简介: Glide的简单使用Glide里的缓存什么是三级缓存?缓存机制为何设计出活动缓存加载流程Glide源码加载流程1.Engine类2.load方法3.EngineKey4.loadFromMemory5.loadFromActiveResources6.loadFromCache7.getEngineResourceFromCache8.waitForExistingOrStartNewJob9.DecodeJob10.DiskCacheProvider11.DiskCache.FactoryLRU是什么内存缓存的LRULruCacheLruCache

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算法可能会删除你正在使用的第一张照片。这样的后果就是你正在使用的照片找不到,后果就是程序崩溃。


加载流程


微信图片_20220522151934.png

微信图片_20220522152000.png


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


Glide源码


加载流程


1.Engine类


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


微信图片_20220522152042.png


  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.

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


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


4.loadFromMemory


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


微信图片_20220522153123.png


5.loadFromActiveResources


微信图片_20220522153204.png

微信图片_20220522153208.png


微信图片_20220522153212.png


微信图片_20220522153215.png


 6.loadFromCache

微信图片_20220522153406.png

7.getEngineResourceFromCache


微信图片_20220522153412.png


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


微信图片_20220522153417.png


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


       磁盘缓存实现的入口。

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

       磁盘缓存目录。


1.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);
  }
/**
*使用此构造函数时,将调用{@link CacheDirectoryGetter#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();
}


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


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中放在前面的元素。


往期回顾  


RecyclerView 绘制流程及Recycler缓存


Java的四种引用方式


Glide 的简单使用


相关文章
|
1月前
|
算法 Linux 调度
深入探索安卓系统的多任务处理机制
【10月更文挑战第21天】 本文旨在为读者提供一个关于Android系统多任务处理机制的全面解析。我们将从Android操作系统的核心架构出发,探讨其如何管理多个应用程序的同时运行,包括进程调度、内存管理和电量优化等方面。通过深入分析,本文揭示了Android在处理多任务时所面临的挑战以及它如何通过创新的解决方案来提高用户体验和设备性能。
44 1
|
1月前
|
存储 安全 Android开发
探索Android与iOS的隐私保护机制
在数字化时代,移动设备已成为我们生活的一部分,而隐私安全是用户最为关注的问题之一。本文将深入探讨Android和iOS两大主流操作系统在隐私保护方面的策略和实现方式,分析它们各自的优势和不足,以及如何更好地保护用户的隐私。
|
3月前
|
缓存 Java 数据库连接
mybatis复习05,mybatis的缓存机制(一级缓存和二级缓存及第三方缓存)
文章介绍了MyBatis的缓存机制,包括一级缓存和二级缓存的配置和使用,以及如何整合第三方缓存EHCache。详细解释了一级缓存的生命周期、二级缓存的开启条件和配置属性,以及如何通过ehcache.xml配置文件和logback.xml日志配置文件来实现EHCache的整合。
mybatis复习05,mybatis的缓存机制(一级缓存和二级缓存及第三方缓存)
|
2月前
|
消息中间件 存储 Java
Android消息处理机制(Handler+Looper+Message+MessageQueue)
Android消息处理机制(Handler+Looper+Message+MessageQueue)
44 2
|
24天前
|
存储 缓存 监控
后端开发中的缓存机制:深度解析与最佳实践####
本文深入探讨了后端开发中不可或缺的一环——缓存机制,旨在为读者提供一份详尽的指南,涵盖缓存的基本原理、常见类型(如内存缓存、磁盘缓存、分布式缓存等)、主流技术选型(Redis、Memcached、Ehcache等),以及在实际项目中如何根据业务需求设计并实施高效的缓存策略。不同于常规摘要的概述性质,本摘要直接点明文章将围绕“深度解析”与“最佳实践”两大核心展开,既适合初学者构建基础认知框架,也为有经验的开发者提供优化建议与实战技巧。 ####
|
20天前
|
缓存 Java 数据库连接
MyBatis缓存机制
MyBatis提供两级缓存机制:一级缓存(Local Cache)默认开启,作用范围为SqlSession,重复查询时直接从缓存读取;二级缓存(Second Level Cache)需手动开启,作用于Mapper级别,支持跨SqlSession共享数据,减少数据库访问,提升性能。
27 1
|
2月前
|
缓存 Java Shell
Android 系统缓存扫描与清理方法分析
Android 系统缓存从原理探索到实现。
80 15
Android 系统缓存扫描与清理方法分析
|
23天前
|
缓存 Java 数据库连接
深入探讨:Spring与MyBatis中的连接池与缓存机制
Spring 与 MyBatis 提供了强大的连接池和缓存机制,通过合理配置和使用这些机制,可以显著提升应用的性能和可扩展性。连接池通过复用数据库连接减少了连接创建和销毁的开销,而 MyBatis 的一级缓存和二级缓存则通过缓存查询结果减少了数据库访问次数。在实际应用中,结合具体的业务需求和系统架构,优化连接池和缓存的配置,是提升系统性能的重要手段。
37 4
|
1月前
|
Linux Android开发 iOS开发
深入探索Android与iOS的多任务处理机制
在移动操作系统领域,Android和iOS各有千秋,尤其在多任务处理上展现出不同的设计理念和技术实现。本文将深入剖析两大平台在后台管理、资源分配及用户体验方面的策略差异,揭示它们如何平衡性能与电池寿命,为用户带来流畅而高效的操作体验。通过对比分析,我们不仅能够更好地理解各自系统的工作机制,还能为开发者优化应用提供参考。
|
2月前
|
消息中间件 存储 Java
Android面试高频知识点(2) 详解Android消息处理机制(Handler)
Android面试高频知识点(2) 详解Android消息处理机制(Handler)