[JAVA] Informationen zum Festplatten-Cache der Glide 4-Serie

Protokollieren Sie, wenn Sie den Disk Cache von Glide untersuchen, um das Essen von Giga zu verbessern

TL;DL

• Gespeichert in / data / data / app_dir / image_manager_disk_cache
• Der Cache-Algorithmus ist LRU (Least Recent Used).
• Die Cache-Kapazität beträgt standardmäßig 250 MB (250 * 1024 * 1024)

Informationen zum Speicherort und zur Kapazität des Cache

Standardmäßig werden bis zu 250 MB im internen Verzeichnis image_manager_disc_cache gespeichert

Diese können durch Definieren von GlideModule geändert werden

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

Informationen zu Cache-Strategien und -Algorithmen

Standardmäßig AUTOMATISCH

Remote-Daten werden ohne spezielle Verarbeitung zwischengespeichert. Falls erforderlich, werden lokale Daten nach einer Verarbeitung zwischengespeichert, z. B. nach einer Größenänderung.

Implementierung

image_manager_disc_cache hat die Erweiterungsdatei ".0" und "jornal" Diese können auch mit dem Device File Explorer bestätigt werden

Der Inhalt von Jornal ist wie folgt

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 → Aus der Bild-URL generierter Hash-Wert 3934 2342 → Metadaten und tatsächliche Antwortgröße

DIRTY → im Cache CLEAN → zwischengespeichert READ → Zugriff per App ENTFERNEN → Ziel löschen

Lesen Sie diese Status nacheinander und verwalten Sie den Cache

Algorithmus

LRU(Least Recently Used) Aktualisierungen, die in der obigen Implementierung ausgeführt werden, sind in der hinteren Zeile gestapelt

Journal neu erstellen

Erstellen Sie das Journal neu und löschen Sie den Cache, wenn die Cache-Größe die Obergrenze erreicht oder wenn "redundantOpCount" (REMOVE) 2000 oder mehr beträgt und die Größe halbiert wird. Ich habe Lust dazu, also sag mir bitte eine detaillierte 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 Die Beziehungen zwischen den Hauptklassen sind wie folgt DiskLruCache.java | DiskLruCacheWrapper.java | DiskLruCacheFactory.java | InternalCacheDiskCacheFactory.java / InternalCacheDiskCacheFactory.java | GlideBuilder.java