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

磁盤快取實作的入口，

在指定的記憶體中創建基于{@link com.bumptech.glide.disklrucache.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);
  }

/**
*使用此建構式時，將呼叫{@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中放在前面的元素，

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的軟參考，弱參考以及虛參考

轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/296637.html

標籤：其他

上一篇：阿里面試，三面都過了，卻被無理由掛了，快來一起吃瓜

下一篇：Android：“金九銀十”戰役打響還沒看到跟BAT大佬的差距就危險了！來看看如何在大廠面試一擊而中

Glide 快取機制及原始碼(二)

Glide里的快取

什么是三級快取？

快取機制

為何設計出活動快取

加載流程

Glide原始碼

加載流程

LRU是什么

記憶體快取的LRU

LruCache

Java的四種參考方式

1.強參考(StrongReference)

2.軟參考(SoftReference)

3.弱參考(WeakReference)

4.虛參考(PhantomReference)

參考佇列(ReferenceQueue)