[JAVA] About Disk Cache of Glide 4 series

Log when investigating Glide's Disk Cache with a desire to improve giga eating

TL;DL --Saved in / data / data / app_dir / image_manager_disk_cache --The cache algorithm is LRU (Least Recently Used) --Cache capacity is 250MB (250 * 1024 * 1024) by default

About cache storage location and capacity

The default is to save up to 250MB in the internal image_manager_disc_cache directory

These can be changed by defining GlideModule

example.java

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    builder.setDiskCache(new ExternalCacheDiskCacheFactory(context));
  }
}

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    int diskCacheSizeBytes = 1024 * 1024 * 100; // 100 MB
    builder.setDiskCache(new InternalCacheDiskCacheFactory(context, diskCacheSizeBytes));
  }
}

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    int diskCacheSizeBytes = 1024 * 1024 * 100; // 100 MB
    builder.setDiskCache(
        new InternalCacheDiskCacheFactory(context, "cacheFolderName", diskCacheSizeBytes));
  }
}

refs https://github.com/bumptech/glide/blob/master/library/src/main/java/com/bumptech/glide/load/engine/cache/DiskCache.java

About cache strategies and algorithms

AUTOMATIC by default

Remote data is cached as it is without any special processing. If necessary, local data is cached after undergoing processing such as resizing.

Implementation

image_manager_disc_cache has a .0 extension file and jornal These can also be confirmed with Device File Explorer

The contents of jornal are as follows

libcore.io.DiskLruCache
1
100
2

CLEAN  832 21054
DIRTY 335c4c6028171cfddfbaae1a9c313c52
CLEAN 335c4c6028171cfddfbaae1a9c313c52 3934 2342
REMOVE 335c4c6028171cfddfbaae1a9c313c52
DIRTY 1ab96a171faeeee38496d8b330771a7a
CLEAN 1ab96a171faeeee38496d8b330771a7a 1600 234
READ 335c4c6028171cfddfbaae1a9c313c52
READ 3400330d1dfc7f3f7f4b8d4d803dfcf6

3400330d1dfc7f3f7f4b8d4d803dfcf6 → Hash value generated from the image url 3934 2342 → Metadata and actual response size

DIRTY → in cache CLEAN → cached READ → Accessing by app REMOVE → Delete target

Read these statuses one by one and manage the cache

algorithm

LRU(Least Recently Used) Updates run in the above implementation are stacked in the back row

Journal rebuild

When the cache size reaches the upper limit or redundantOpCount (REMOVE) is 2000 or more and the size is halve, rebuild the journal and delete the cache (as mentioned in the comment, but it seems to be inconsistent with the implementation. I feel like it, so please tell me a detailed person.)

DiskLruCahe.java

 /**
   * We only rebuild the journal when it will halve the size of the journal
   * and eliminate at least 2000 ops.
   */
  private boolean journalRebuildRequired() {
    final int redundantOpCompactThreshold = 2000;
    return redundantOpCount >= redundantOpCompactThreshold //
        && redundantOpCount >= lruEntries.size();
  }

DiskLruCahe.java

 private void trimToSize() throws IOException {
    while (size > maxSize) {
      Map.Entry<String, Entry> toEvict = lruEntries.entrySet().iterator().next();
      remove(toEvict.getKey());
    }
  }

 /** This cache uses a single background thread to evict entries. */
  final ThreadPoolExecutor executorService =
      new ThreadPoolExecutor(0, 1, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(),
          new DiskLruCacheThreadFactory());
  private final Callable<Void> cleanupCallable = new Callable<Void>() {
    public Void call() throws Exception {
      synchronized (DiskLruCache.this) {
        if (journalWriter == null) {
          return null; // Closed.
        }
        trimToSize();
        if (journalRebuildRequired()) {
          rebuildJournal();
          redundantOpCount = 0;
        }
      }
      return null;
    }
  };

refs https://github.com/bumptech/glide/blob/master/library/src/main/java/com/bumptech/glide/load/engine/DiskCacheStrategy.java https://futurestud.io/tutorials/retrofit-2-analyze-cache-files

apendix The relationships between the major classes are as follows DiskLruCache.java | DiskLruCacheWrapper.java | DiskLruCacheFactory.java | InternalCacheDiskCacheFactory.java / InternalCacheDiskCacheFactory.java | GlideBuilder.java