Disk Cache : qu’est-ce que c’est, cache disque iOS et principes de fonctionnement

Qu’est-ce que Disk Cache dans iOS ?

Disk Cache est une technologie de stockage temporaire des données sur le stockage permanent de l’appareil (mémoire flash) afin d’accélérer les requêtes ultérieures aux mêmes données. Contrairement au cache RAM, Disk Cache conserve les données après un redémarrage de l’application et même de l’appareil.

iOS propose deux niveaux de cache principaux : volatil (NSCache, mémoire) et sur disque (URLCache, système de fichiers). Le cache disque est 10 à 100 fois plus lent que le cache volatil, mais significativement plus rapide qu’une requête réseau — la différence peut être de 2 à 3 ordres de grandeur. La stratégie optimale utilise un cache à deux niveaux : la mémoire pour les données chaudes et le disque pour les données froides.

Selon Apple Performance Optimization Guide, 2023, un Disk Cache correctement configuré réduit le temps de chargement du contenu de 60 à 80% pour les vues répétées et diminue la consommation de trafic de 40 à 70%. Pour les applications riches en médias (images, vidéo, audio), la mise en cache est un facteur UX critique.

URLCache : mécanisme de cache intégré

URLCache est une classe Foundation intégrée qui implémente un cache combiné pour les requêtes URLSession. Elle enregistre automatiquement les réponses du serveur sur le disque et en mémoire, en gérant la taille du cache et les politiques d’invalidation basées sur les en-têtes HTTP tels que Cache-Control, Expires et ETag.

import Foundation

let cache = URLCache(
    memoryCapacity: 50 * 1024 * 1024,
    diskCapacity: 200 * 1024 * 1024,
    diskPath: "network-cache"
)

URLCache.shared = cache

let config = URLSessionConfiguration.default
config.urlCache = cache
config.requestCachePolicy = .returnCacheDataElseLoad

let session = URLSession(configuration: config)

Politiques de cache URLCache déterminent quand utiliser les données en cache et quand effectuer une nouvelle requête. Les principales politiques incluent : useProtocolCachePolicy (basée sur les en-têtes du serveur), reloadIgnoringLocalCacheData (toujours depuis le serveur), returnCacheDataElseLoad (cache d’abord), returnCacheDataDontLoad (cache seulement — mode hors ligne).

Cache-Control est un en-tête HTTP que le serveur envoie avec la réponse, spécifiant max-age (durée de vie en secondes), must-revalidate (vérifier l’actualité), no-cache (ne pas utiliser sans vérification) et no-store (ne pas mettre en cache). iOS respecte strictement ces en-têtes automatiquement lors de l’utilisation d’URLCache avec la politique useProtocolCachePolicy.

Stratégies de cache personnalisées et invalidation

Cache personnalisé est nécessaire lorsque l’URLCache intégré est insuffisant — pour stocker des images traitées, des modèles de données sérialisés ou des résultats de calculs. Dans ces cas, les développeurs créent leur propre système de cache basé sur le répertoire Caches du Sandbox de l’application.

class DiskCache<T: Codable> {
    private let cacheDir: URL
    private let encoder = JSONEncoder()
    private let decoder = JSONDecoder()

    init() {
        let paths = FileManager.default
            .urls(for: .cachesDirectory,
                     in: .userDomainMask)
        cacheDir = paths[0].appendingPathComponent(
            "data-cache", isDirectory: true
        )
        try? FileManager.default
            .createDirectory(at: cacheDir,
                             withIntermediateDirectories: true)
    }

    func set(value: T, for key: String) {
        let url = cacheDir.appendingPathComponent(
            SHA256.hash(key)
        )
        if let data = try? encoder.encode(value) {
            try? data.write(to: url)
        }
    }

    func get(for key: String) -> T? {
        let url = cacheDir.appendingPathComponent(
            SHA256.hash(key)
        )
        guard let data = try? Data(contentsOf: url) else { return nil }
        return try? decoder.decode(T.self, from: data)
    }

    func clearAll() {
        try? FileManager.default
            .removeItem(at: cacheDir)
    }
}

Stratégies d’invalidation du cache déterminent quand les données stockées sont considérées comme obsolètes : TTL (Time-To-Live) — les données vivent un temps fixe après l’écriture ; piloté par événement — invalidation basée sur un événement (ex. mise à jour des données sur le serveur) ; basé sur la version — invalidation lors du changement de version de l’API ou du format de données ; LRU (Least Recently Used) — suppression automatique des entrées les moins utilisées lors du dépassement de la limite de taille.

Règle pratique : TTL convient aux actualités et aux contenus qui deviennent obsolètes de manière prévisible. Piloté par événement pour les données gérées par le serveur via des notifications push. Basé sur la version pour les configurations et les caches de modèles de données. LRU est un choix universel pour les fichiers médias avec un espace disque limité.

Performances et limites du cache

Les performances de Disk Cache sont mesurées par le taux de succès (hit ratio) — le pourcentage de requêtes satisfaites depuis le cache sans appel réseau. Un taux de succès typique pour un cache d’images bien configuré est de 70 à 90%, pour les réponses API — 40 à 60%, pour la vidéo en streaming — 30 à 50%.

Limitations de Disk Cache dans iOS : le système peut supprimer le contenu du répertoire Caches à tout moment en cas de manque d’espace disque. Ce comportement n’est pas configurable — iOS décide quand et quels fichiers en cache supprimer. Par conséquent, le cache ne doit pas contenir de données qui ne peuvent pas être récupérées depuis le réseau ou d’autres sources.

Impact sur la mémoire flash : les écritures fréquentes dans Disk Cache accélèrent l’usure du stockage flash. iOS utilise TRIM et l’usure uniformisée (wear leveling) pour minimiser l’usure, mais les développeurs sont invités à éviter les écritures excessives : ne pas mettre à jour le cache plus d’une fois toutes les 5 minutes pour le même fichier ; regrouper les petites écritures ; utiliser NSCache pour les données temporaires qui n’ont pas besoin d’être persistées sur le disque.

Meilleures pratiques de mise en cache dans iOS

Cache à deux niveaux est l’architecture standard pour les applications iOS : la mémoire (NSCache) pour les données fréquemment consultées, et le disque (URLCache ou personnalisé) pour les données qui doivent persister entre les sessions. Durée de vie en mémoire — minutes, sur disque — heures ou jours.

Mise en cache des images : utilisez des bibliothèques spécialisées (Kingfisher, SDWebImage, Nuke) qui implémentent un cache à deux niveaux avec invalidation automatique, gestion de la mémoire et écriture asynchrone sur disque. L’implémentation d’un cache d’images personnalisé nécessite de prendre en compte le décodage, l’espace colorimétrique et la mise à l’échelle.

Cache et sécurité : ne mettez pas en cache sur le disque des données sensibles (mots de passe, jetons, données personnelles) sans chiffrement. URLCache ne chiffre pas les données par défaut — utilisez NSFileProtection ou un chiffrement au niveau de l’application pour le contenu sensible. Pour les requêtes réseau autorisées, utilisez la politique .reloadIgnoringLocalCacheData.

Surveillance du cache : suivez le taux de succès, la taille actuelle du cache et les écritures par minute. Si le taux de succès tombe en dessous de 30%, le cache est inefficace et nécessite une révision de la stratégie ou une augmentation de taille. Selon Point-Free (2024), la surveillance du cache est l’une des pratiques d’optimisation des performances les plus sous-estimées pour les applications iOS.