App-Cache-Verzeichnis — Was es ist, Zweck und wie man es in der mobilen Entwicklung leert

Was ist ein App-Cache-Verzeichnis?

Das Cache-Verzeichnis ist ein spezielles Verzeichnis im internen (oder externen) Speicher der Anwendung, das für temporäre Dateien vorgesehen ist. Der Hauptunterschied zum Internal Storage: Das System hat das Recht, Dateien aus dem Cache ohne Benachrichtigung zu löschen, wenn das Gerät wenig freien Speicherplatz hat. Daher sollte die Anwendung niemals die einzige Kopie wichtiger Benutzerdaten im Cache speichern. Der Cache ist optimal für heruntergeladene Bilder, Serverantworten, vorcompilierte Ressourcen und alle anderen Daten, die remote wiederhergestellt oder programmatisch neu erstellt werden können.

Unter Android befindet sich das Cache-Verzeichnis unter /data/data/<package>/cache/ und ist über context.cacheDir zugänglich. Die Cache-Größe ist nicht explizit begrenzt, aber Google Play empfiehlt, 100 MB nicht zu überschreiten, da Apps mit großem Cache negative Bewertungen erhalten. Unter iOS befindet sich das Cache-Verzeichnis innerhalb des Sandbox-Containers unter Library/Caches/ und ist über NSCachesDirectory zugänglich. iOS kann Dateien aus Caches löschen, wenn das Gerät aus einem Backup wiederhergestellt wird oder bei kritischem Speichermangel — darüber sollten Benutzer in der App-Dokumentation informiert werden.

Zu verstehen, welche Daten sicher im Cache abgelegt werden können und welche im Internal Storage oder in Documents gespeichert werden müssen, ist eine Schlüsselkompetenz für Entwickler. Die falsche Verwendung des Caches führt zu zwei gegensätzlichen Problemen: Entweder belegt die App zu viel Speicherplatz (wenn der Entwickler im Cache speichert, was in Documents sein sollte) oder der Benutzer verliert Daten (wenn der Entwickler im Cache speichert, was dauerhaft erhalten bleiben sollte). Befolgen Sie eine einfache Regel: Wenn Daten wiederhergestellt werden können — Cache, wenn eine Wiederherstellung unmöglich ist — Internal Storage oder Documents.

Zweck und Arten von zwischengespeicherten Daten

Verschiedene Datentypen haben unterschiedliche Wiederherstellungsgeschwindigkeiten und Speicheranforderungen. Das Verständnis dieser Eigenschaften hilft dem Entwickler, richtig zu wählen, welche Dateien in den Cache und welche in den dauerhaften Speicher gelegt werden.

Cache für Bilder und Mediendateien

Die häufigste Art von zwischengespeicherten Daten sind Bilder, die aus dem Netzwerk heruntergeladen wurden. Bibliotheken wie Glide, Picasso und Coil speichern heruntergeladene Bilder automatisch im Cache-Verzeichnis der App. Die typische Größe des Bildcaches in sozialen Apps liegt zwischen 50 und 200 MB. Die Cache-Größe hängt von der Bildschirmauflösung des Geräts und der Menge des angezeigten Inhalts ab. Glide verwendet zweistufiges Caching: Es überprüft zuerst den L1-Cache im RAM (LRU-Algorithmus), dann den L2-Cache auf der Festplatte. Dies gewährleistet schnelles Laden von wiederholt angezeigten Bildern ohne zusätzliche Netzwerkanfrage. Die Konfiguration der maximalen Festplatten-Cache-Größe über DiskCacheStrategy ermöglicht die Kontrolle über den belegten Speicherplatz: Bei Überschreitung des Limits entfernt die Bibliothek automatisch die am wenigsten verwendeten Dateien.

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 ->
        // Daten in den Cache schreiben
    }
}

Cache für Netzwerkanfragen

Antworten von API-Anfragen können für den Offline-Zugriff und zur Reduzierung der Serverlast zwischengespeichert werden. OkHttp bietet integrierte Cache-Unterstützung über die Cache-Klasse. Die Antwort-Header Cache-Control und ETag verwalten die Caching-Richtlinie: Der Server gibt an, wie lange eine Antwort als aktuell gilt. Bei richtiger Konfiguration kann der Netzwerkanfragen-Cache die Datenladezeit bei wiederholten Besuchen um 60–80% reduzieren und grundlegende App-Funktionalität ohne Internetverbindung bereitstellen. Die Größe des Netzwerkanfragen-Caches überschreitet selten 10–20 MB, kann aber bei intensiver Nutzung 50 MB erreichen. Konfigurieren Sie die maximale Cache-Größe über den OkHttpClient.Builder-Konstruktor und überprüfen Sie die Aktualität der zwischengespeicherten Daten bei jedem App-Start.

Cache für Datenbanken und vorcompilierte Daten

SQLite-Datenbanken können während des Betriebs temporäre Dateien erzeugen: WAL-Dateien (Write-Ahead Log), Rollback-Journale und Indexseiten. Diese Dateien werden neben der Hauptdatenbank gespeichert, aber für temporäre Datenbanken (z. B. Volltextsuche oder Analytik) kann die Platzierung im Cache-Verzeichnis angegeben werden. Vorcompilierte OpenGL- und Vulkan-Shader-Programme werden ebenfalls in diesem Verzeichnis zwischengespeichert, was das erste Laden von Grafikszene beschleunigt. Unter iOS wird NSCachesDirectory für die Speicherung vorcompilierter Core-Data-Daten und temporärer Bildverarbeitungsdateien empfohlen.

Wie das Cache-Leeren auf Android und iOS funktioniert

Das Leeren des Caches kann automatisch (durch das System) oder manuell (durch den Benutzer oder die App) erfolgen. Das Verständnis des Systemverhaltens in verschiedenen Szenarien ist notwendig, um Datenverlust zu verhindern.

Automatisches Leeren durch das System

Unter Android startet das System den Cache-Leerungsprozess, wenn der freie Speicherplatz auf der /data-Partition unter einen kritischen Schwellenwert (normalerweise 500 MB) fällt. Der Prozess cacheflush analysiert die Cache-Größe aller installierten Apps und entfernt die am wenigsten verwendeten Dateien, beginnend mit den ältesten. Der Benutzer kann auch manuell den Cache aller Apps über die Systemeinstellungen leeren: „Einstellungen → Speicher → Cache → Cache leeren.“ Unter iOS erfolgt das automatische Leeren von Caches bei der Wiederherstellung des Geräts aus einem Backup — iOS stellt den Inhalt von Library/Caches/ nicht wieder her. Darüber hinaus kann iOS bei Speichermangel selektiv Dateien aus Caches löschen, indem es den Mechanismus des löschbaren Speichers für isolierte Daten verwendet.

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)
}

Programmatisches Cache-Leeren durch die App

Der Entwickler kann das programmatische Cache-Leeren auf Benutzeranfrage oder nach einem Zeitplan implementieren. Unter Android genügt es, alle Dateien in context.cacheDir und context.externalCacheDir zu löschen, um den eigenen Cache zu leeren. Unter iOS leeren Sie den Inhalt von Library/Caches/, löschen Sie jedoch nicht das Verzeichnis selbst — nur seinen Inhalt. Es wird empfohlen, dem Benutzer die aktuelle Cache-Größe in den App-Einstellungen zusammen mit einer Schaltfläche „Cache leeren“ mit Bestätigung anzuzeigen. Laut Google Play Console erhalten Apps mit einer Cache-Leeren-Schaltfläche 22% weniger Beschwerden über Speichermangel im Vergleich zu Apps ohne diese Funktion. Das Cache-Leeren sollte sicher sein: Die App muss die Situation, in der zwischengespeicherte Dateien gelöscht wurden, korrekt behandeln und diese beim nächsten Zugriff transparent neu laden.

Unterschiede zwischen cacheDir auf Android und iOS

Trotz des gleichen Zwecks weist die Implementierung von Cache-Verzeichnissen auf Android und iOS erhebliche Unterschiede auf. Der Entwickler muss diese für den korrekten Betrieb der App auf beiden Plattformen berücksichtigen.

Android bietet ein separates externes Cache-Verzeichnis über context.externalCacheDir — es befindet sich auf der SD-Karte (falls installiert) und wird bei der Deinstallation der App nicht gelöscht. Dies ist praktisch für große Mediendateien, birgt jedoch das Risiko, Müll auf der Speicherkarte zu hinterlassen. iOS hat kein Konzept eines externen Caches: Alle temporären Dateien werden innerhalb des Sandbox-Containers gespeichert und bei der Deinstallation garantiert gelöscht. Unter Android ist der Cache für den Benutzer in den App-Einstellungen sichtbar, und er kann ihn manuell leeren. Unter iOS zeigen die Systemeinstellungen die Cache-Größe einzelner Apps nicht an — der Benutzer kann den Cache nur durch Löschen und Neuinstallieren der App leeren, es sei denn, der Entwickler hat eine Lösch-Schaltfläche in die Oberfläche eingebaut.

Ein wichtiger Unterschied ist das Verhalten bei der Wiederherstellung. Unter iOS wird bei der Wiederherstellung aus einem iTunes- oder iCloud-Backup das Caches-Verzeichnis nicht wiederhergestellt, da iOS davon ausgeht, dass die zwischengespeicherten Daten beim ersten Start neu erstellt werden. Unter Android wird bei der Wiederherstellung aus Google Drive nur der Internal Storage gesichert — der Cache bleibt nach der Wiederherstellung leer. In beiden Fällen muss die App mit einem leeren Cache korrekt funktionieren, ohne Fehler anzuzeigen oder Funktionalität zu verlieren.

Empfehlungen zur Cache-Verwaltung

Die richtige Cache-Verwaltung ist einer der Faktoren, die die Benutzererfahrung und die App-Bewertung beeinflussen. Die folgenden Empfehlungen helfen, typische Probleme zu vermeiden und die Benutzerzufriedenheit zu erhöhen.

• Legen Sie ein Größenlimit für den Cache fest. Verwenden Sie DiskLruCache oder ähnliche Bibliotheken mit Angabe des maximalen Volumens in Megabyte. Bei Überschreitung des Limits entfernt die Bibliothek automatisch die am wenigsten verwendeten Dateien
• Implementieren Sie eine Cache-Leeren-Schaltfläche in den App-Einstellungen. Zeigen Sie die aktuelle Cache-Größe an (im Format „12,5 MB“) und fordern Sie vor dem Leeren eine Bestätigung an. Aktualisieren Sie nach dem Leeren die angezeigte Größe
• Speichern Sie keine nicht wiederherstellbaren Dateien im Cache. Wenn Daten für den Betrieb der App kritisch sind, speichern Sie sie im Internal Storage (Android) oder in Documents (iOS) und legen Sie nur eine Kopie für den schnellen Zugriff in den Cache
• Überprüfen Sie die Verfügbarkeit des externen Caches vor dem Schreiben. Unter Android kann context.externalCacheDir null zurückgeben, wenn die SD-Karte nicht installiert oder nicht verfügbar ist. Sehen Sie immer einen Fallback auf den internen Cache vor
• Verwenden Sie eine TTL-Richtlinie für zwischengespeicherte Daten. Speichern Sie Dateien nicht länger als nötig: für Bilder — 24–48 Stunden, für API-Antworten — je nach Aktualisierungshäufigkeit 5 Minuten bis 1 Stunde

Überwachen Sie regelmäßig die Cache-Größe in der App-Analytik. Integrieren Sie das Melden der Cache-Größenmetrik in Firebase Analytics oder ein ähnliches System. Wenn die durchschnittliche Cache-Größe 100 MB überschreitet, optimieren Sie die Caching-Strategie: Reduzieren Sie die TTL für selten genutzte Daten, implementieren Sie Bildkompression vor dem Caching (WebP statt PNG, reduzieren Sie die JPEG-Qualität auf 85%), verwenden Sie Paginierung für das Laden von Inhalten vom Server. Denken Sie daran, dass Benutzer mit 16–32 GB Geräten besonders empfindlich auf die App-Größe reagieren: Wenn der Cache 200 MB erreicht, suchen viele Benutzer nach einer Möglichkeit, ihn zu leeren, oder löschen einfach die App. Laut einer Google-Umfrage haben 38% der Benutzer mindestens eine App aufgrund unkontrollierten Cache-Wachstums und Speicherverbrauchs gelöscht.