Répertoire de Cache de l'App — Qu'est-ce que c'est, Objectif et Comment le Vider dans le Développement Mobile

Qu'est-ce que le Répertoire de Cache d'une Application ?

Le répertoire de cache est un répertoire spécial dans la mémoire interne (ou externe) de l'application conçu pour les fichiers temporaires. La principale différence avec Internal Storage : le système a le droit de supprimer des fichiers du cache sans préavis si l'appareil manque d'espace libre. Par conséquent, l'application ne doit jamais stocker la seule copie des données importantes de l'utilisateur dans le cache. Le cache est optimal pour les images téléchargées, les réponses serveur, les ressources précompilées et toutes autres données qui peuvent être restaurées à distance ou recréées par programmation.

Sous Android, le répertoire de cache se trouve à /data/data/<package>/cache/ et est accessible via context.cacheDir. La taille du cache n'est pas explicitement limitée, mais Google Play recommande de ne pas dépasser 100 Mo, car les applications avec un gros cache reçoivent des avis négatifs des utilisateurs. Sous iOS, le répertoire de cache se trouve à l'intérieur du conteneur Sandbox à Library/Caches/ et est accessible via NSCachesDirectory. iOS peut supprimer des fichiers de Caches lors de la restauration de l'appareil à partir d'une sauvegarde ou en cas de manque critique d'espace — les utilisateurs doivent en être informés dans la documentation de l'application.

Comprendre quelles données peuvent être placées en toute sécurité dans le cache et lesquelles doivent être stockées dans Internal Storage ou Documents est une compétence clé du développeur. Une mauvaise utilisation du cache entraîne deux problèmes opposés : soit l'application occupe trop d'espace (si le développeur stocke dans le cache ce qui devrait être dans Documents), soit l'utilisateur perd des données (si le développeur stocke dans le cache ce qui devrait être conservé de façon permanente). Suivez une règle simple : si les données peuvent être récupérées — cache, si la récupération est impossible — Internal Storage ou Documents.

Objectif et Types de Données Mises en Cache

Différents types de données ont une vitesse de recréation et des exigences d'espace différentes. Comprendre ces caractéristiques aide le développeur à choisir correctement quels fichiers placer dans le cache et lesquels dans le stockage permanent.

Cache d'Images et de Fichiers Média

Le type le plus courant de données mises en cache sont les images téléchargées depuis le réseau. Les bibliothèques Glide, Picasso et Coil enregistrent automatiquement les images téléchargées dans le répertoire de cache de l'application. La taille typique du cache d'images dans les applications sociales varie de 50 à 200 Mo. La taille du cache dépend de la résolution d'écran de l'appareil et de la quantité de contenu visualisé. Glide utilise une mise en cache à deux niveaux : il vérifie d'abord le cache L1 dans la RAM (algorithme LRU), puis le cache L2 sur le disque. Cela garantit un chargement rapide des images visualisées à plusieurs reprises sans requête réseau supplémentaire. La configuration de la taille maximale du cache disque via DiskCacheStrategy permet de contrôler l'espace occupé : lorsque la limite est dépassée, la bibliothèque supprime automatiquement les fichiers les moins utilisés.

val cacheDir = File(context.cacheDir, "image_cache")
val maxSize = 50 * 1024 * 1024 // 50 MB

val cache = DiskLruCache.open(cacheDir, 1, 1, maxSize)
cache.edit("key")?.let { editor ->
    editor.newOutputStream(0).use { stream ->
        // écrire des données dans le cache
    }
}

Cache de Requêtes Réseau

Les réponses aux requêtes API peuvent être mises en cache pour un accès hors ligne et pour réduire la charge du serveur. OkHttp fournit un support de mise en cache intégré via la classe Cache. Les en-têtes de réponse Cache-Control et ETag gèrent la politique de cache : le serveur spécifie pendant combien de temps la réponse est considérée comme valide. Avec une configuration appropriée, le cache de requêtes réseau peut réduire le temps de chargement des données de 60 à 80 % lors de visites répétées et fournir des fonctionnalités de base de l'application sans connexion Internet. La taille du cache de requêtes réseau dépasse rarement 10–20 Mo, mais avec une utilisation intensive de l'application, elle peut atteindre 50 Mo. Configurez la taille maximale du cache via le constructeur OkHttpClient.Builder et vérifiez la validité des données mises en cache à chaque démarrage de l'application.

Cache de Bases de Données et de Données Précompilées

Les bases de données SQLite peuvent générer des fichiers temporaires pendant leur fonctionnement : fichiers WAL (Write-Ahead Log), journaux de restauration et pages d'index. Ces fichiers sont stockés à côté de la base de données principale, mais pour les bases de données temporaires (par exemple, recherche en texte intégral ou analytics), l'emplacement dans le répertoire de cache peut être spécifié. Les programmes de shader précompilés OpenGL et Vulkan sont également mis en cache dans ce répertoire, ce qui accélère le premier chargement des scènes graphiques. Sous iOS, NSCachesDirectory est recommandé pour stocker les données précompilées de Core Data et les fichiers temporaires de traitement d'images.

Comment Fonctionne le Vidage du Cache sur Android et iOS

Le vidage du cache peut se produire automatiquement (par le système) ou manuellement (par l'utilisateur ou l'application). Comprendre le comportement du système dans différents scénarios est nécessaire pour prévenir la perte de données.

Vidage Automatique par le Système

Sous Android, le système lance le processus de vidage du cache lorsque l'espace libre sur la partition /data tombe en dessous d'un seuil critique (généralement 500 Mo). Le processus cacheflush analyse la taille du cache de toutes les applications installées et supprime les fichiers les moins utilisés, en commençant par les plus anciens. L'utilisateur peut également vider manuellement le cache de toutes les applications via les paramètres système : « Paramètres → Stockage → Cache → Vider le cache. » Sous iOS, le vidage automatique de Caches se produit lors de la restauration de l'appareil à partir d'une sauvegarde — iOS ne restaure pas le contenu de Library/Caches/. De plus, iOS peut supprimer sélectivement des fichiers de Caches lorsque l'espace libre vient à manquer, en utilisant le mécanisme de stockage purgeable pour les données isolées.

let fm = FileManager.default
let cachesURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let contents = try fm.contentsOfDirectory(
    at: cachesURL,
    includingPropertiesForKeys: nil
)
for fileURL in contents {
    try fm.removeItem(at: fileURL)
}

Vidage Programmatique du Cache par l'Application

Le développeur peut implémenter le vidage programmatique du cache à la demande de l'utilisateur ou selon un calendrier. Sous Android, pour vider le cache de l'application elle-même, supprimez tous les fichiers dans context.cacheDir et context.externalCacheDir. Sous iOS, videz le contenu de Library/Caches/ mais ne supprimez pas le répertoire lui-même — seulement son contenu. Il est recommandé d'afficher à l'utilisateur la taille actuelle du cache dans les paramètres de l'application avec un bouton « Vider le cache » avec confirmation. Selon Google Play Console, les applications avec un bouton de vidage du cache reçoivent 22 % de plaintes en moins concernant le manque d'espace par rapport aux applications sans cette fonctionnalité. Le vidage du cache doit être sûr : l'application doit gérer correctement la situation où les fichiers mis en cache sont supprimés et les recharger de manière transparente lors du prochain accès.

Différences Entre cacheDir sur Android et iOS

Malgré le même objectif, l'implémentation des répertoires de cache sur Android et iOS présente des différences significatives. Le développeur doit en tenir compte pour le bon fonctionnement de l'application sur les deux plateformes.

Android fournit un répertoire de cache externe séparé via context.externalCacheDir — il se trouve sur la carte SD (si installée) et n'est pas supprimé lors de la désinstallation de l'application. C'est pratique pour les gros fichiers média, mais cela crée un risque de laisser des résidus sur la carte mémoire. iOS n'a pas de concept de cache externe : tous les fichiers temporaires sont stockés à l'intérieur du conteneur Sandbox et sont garantis d'être supprimés lors de la désinstallation. Sous Android, le cache est visible pour l'utilisateur dans les paramètres de l'application et il peut le vider manuellement. Sous iOS, les paramètres système n'affichent pas la taille du cache des applications individuelles — l'utilisateur ne peut vider le cache qu'en supprimant et en réinstallant l'application, à moins que le développeur n'ait ajouté un bouton de vidage dans l'interface.

Une différence importante — le comportement lors de la restauration. Sous iOS, lors de la restauration à partir d'une sauvegarde iTunes ou iCloud, le répertoire Caches n'est pas restauré, car iOS suppose que les données mises en cache seront recréées au premier démarrage. Sous Android, lors de la restauration à partir de Google Drive, seul Internal Storage est sauvegardé — le cache reste vide après la restauration. Dans les deux cas, l'application doit fonctionner correctement avec un cache vide, sans afficher d'erreurs à l'utilisateur ni perdre de fonctionnalités.

Recommandations pour la Gestion du Cache

La gestion appropriée du cache de l'application est l'un des facteurs influençant l'expérience utilisateur et la notation de l'application. Les recommandations suivantes aideront à éviter les problèmes typiques et à améliorer la satisfaction des utilisateurs.

• Définissez une limite de taille pour le cache. Utilisez DiskLruCache ou des bibliothèques similaires en spécifiant le volume maximal en mégaoctets. Lorsque la limite est dépassée, la bibliothèque supprime automatiquement les fichiers les moins utilisés
• Implémentez un bouton de vidage du cache dans les paramètres de l'application. Affichez la taille actuelle du cache (au format « 12,5 Mo ») et demandez une confirmation avant de vider. Après le vidage, mettez à jour la taille affichée
• Ne stockez pas dans le cache les fichiers qui ne peuvent pas être récupérés. Si les données sont critiques pour le fonctionnement de l'application, stockez-les dans Internal Storage (Android) ou Documents (iOS), et placez seulement une copie dans le cache pour un accès rapide
• Vérifiez la disponibilité du cache externe avant d'écrire. Sous Android, context.externalCacheDir peut retourner null si la carte SD n'est pas installée ou indisponible. Prévoyez toujours un repli vers le cache interne
• Utilisez une politique d'expiration (TTL) pour les données mises en cache. Ne stockez pas les fichiers plus longtemps que nécessaire : pour les images — 24–48 heures, pour les réponses API — de 5 minutes à 1 heure selon la fréquence de mise à jour des données

Surveillez régulièrement la taille du cache dans les analytics de l'application. Intégrez l'envoi de la métrique de taille du cache dans Firebase Analytics ou un système similaire. Si la taille moyenne du cache dépasse 100 Mo, optimisez la stratégie de mise en cache : réduisez le TTL pour les données rarement utilisées, implémentez la compression des images avant la mise en cache (WebP au lieu de PNG, réduisez la qualité JPEG à 85 %), utilisez la pagination pour le chargement du contenu depuis le serveur. N'oubliez pas que les utilisateurs disposant d'appareils de 16–32 Go sont particulièrement sensibles à la taille de l'application : lorsque le cache atteint 200 Mo, de nombreux utilisateurs commencent à chercher un moyen de le vider ou suppriment simplement l'application. Selon une enquête de Google, 38 % des utilisateurs ont supprimé au moins une application en raison de la croissance incontrôlée du cache et de l'espace occupé.