[JAVA] À propos du cache disque de la série Glide 4

Connectez-vous lors de l'enquête sur le cache de disque de Glide avec le désir d'améliorer la consommation de giga

TL;DL

• Enregistré dans / data / data / app_dir / image_manager_disk_cache
• L'algorithme de cache est LRU (le moins récemment utilisé)
• La capacité du cache est de 250 Mo (250 * 1024 * 1024) par défaut

À propos de l'emplacement et de la capacité de stockage du cache

La valeur par défaut consiste à enregistrer jusqu'à 250 Mo dans le répertoire interne image_manager_disc_cache

Ceux-ci peuvent être modifiés en définissant 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

À propos des stratégies et algorithmes de cache

AUTOMATIQUE par défaut

Les données distantes sont mises en cache telles quelles sans aucun traitement spécial. Si nécessaire, les données locales sont mises en cache après un traitement tel que le redimensionnement.

la mise en oeuvre

image_manager_disc_cache a un fichier d'extension «.0» et «jornal» Ceux-ci peuvent également être confirmés avec Device File Explorer

Le contenu de jornal est le suivant

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 → Valeur de hachage générée à partir de l'url de l'image 3934 2342 → Métadonnées et taille réelle de la réponse

DIRTY → dans le cache CLEAN → mis en cache LIRE → Accès via l'application REMOVE → Supprimer la cible

Lisez ces états un par un et gérez le cache

algorithme

LRU(Least Recently Used) Les mises à jour exécutées dans l'implémentation ci-dessus sont empilées dans la rangée arrière

Reconstruction du journal

Si la taille du cache atteint la limite supérieure ou si redundantOpCount (REMOVE) est de 2000 ou plus et que la taille est divisée par deux, reconstruisez le journal et supprimez le cache (comme mentionné dans le commentaire, mais cela semble incompatible avec l'implémentation. J'en ai envie, alors s'il vous plaît dites-moi une personne détaillée.)

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 Les relations entre les principales classes sont les suivantes DiskLruCache.java | DiskLruCacheWrapper.java | DiskLruCacheFactory.java | InternalCacheDiskCacheFactory.java / InternalCacheDiskCacheFactory.java | GlideBuilder.java