De cachemap van de app — wat het is, doel en hoe te wissen in mobiele ontwikkeling

Wat is de cachemap van de app?

De cachemap is een speciale map in het interne (of externe) geheugen van de app, bedoeld voor tijdelijke bestanden. Het belangrijkste verschil met Internal Storage: het systeem heeft het recht om bestanden uit de cache te verwijderen zonder kennisgeving als het apparaat onvoldoende vrije ruimte heeft. Daarom mag de app nooit de enige kopie van belangrijke gebruikersgegevens in de cache bewaren. De cache is optimaal voor gedownloade afbeeldingen, serverantwoorden, voorgecompileerde bronnen en alle andere gegevens die op afstand kunnen worden hersteld of programmatisch opnieuw kunnen worden aangemaakt.

Op Android bevindt de cachemap zich op het pad /data/data/<pakket>/cache/ en is toegankelijk via context.cacheDir. De cachegrootte is niet expliciet beperkt, maar Google Play raadt aan om niet meer dan 100 MB te gebruiken, omdat apps met een grote cache negatieve beoordelingen krijgen. Op iOS bevindt de cachemap zich binnen de Sandbox-container op het pad Library/Caches/ en is toegankelijk via NSCachesDirectory. iOS kan bestanden uit Caches verwijderen bij het herstellen van het apparaat vanaf een back-up of bij kritiek ruimtegebrek \u2014 gebruikers moeten hiervoor worden gewaarschuwd in de app-documentatie.

Begrijpen welke gegevens veilig in de cache kunnen worden geplaatst en welke in Internal Storage of Documents moeten worden bewaard, is een essenti\u00eble vaardigheid van de ontwikkelaar. Onjuist gebruik van de cache leidt tot twee tegenovergestelde problemen: ofwel neemt de app te veel ruimte in (als de ontwikkelaar in de cache opslaat wat in Documents thuishoort), ofwel verliest de gebruiker gegevens (als de ontwikkelaar in de cache opslaat wat permanent bewaard moet worden). Volg een eenvoudige regel: als gegevens kunnen worden hersteld \u2014 cache, als herstel onmogelijk is \u2014 Internal Storage of Documents.

Doel en soorten cached gegevens

Verschillende gegevenstypen hebben een verschillende herstelsnelheid en volume-eisen. Inzicht in deze kenmerken helpt de ontwikkelaar correct te kiezen welke bestanden in de cache en welke in permanente opslag moeten worden geplaatst.

Cache voor afbeeldingen en mediabestanden

Het meest voorkomende type cached gegevens zijn afbeeldingen die uit het netwerk zijn gedownload. Bibliotheken zoals Glide, Picasso en Coil slaan gedownloade afbeeldingen automatisch op in de cachemap van de app. De typische omvang van de afbeeldingscache in sociale apps varieert van 50 tot 200 MB. De cachegrootte hangt af van de schermresolutie van het apparaat en de hoeveelheid bekeken inhoud. Glide gebruikt caching op twee niveaus: eerst controleert het de L1-cache in het RAM (LRU-algoritme), daarna de L2-cache op de schijf. Dit zorgt voor snel laden van opnieuw bekeken afbeeldingen zonder een nieuw netwerkverzoek. Het instellen van de maximale schijfcachegrootte via DiskCacheStrategy maakt het mogelijk de ingenomen ruimte te beheersen: bij overschrijding van de limiet verwijdert de bibliotheek automatisch de minst gebruikte bestanden.

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 ->
        // gegevens naar cache schrijven
    }
}

Cache voor netwerkverzoeken

Antwoorden van API-verzoeken kunnen worden cached voor offline toegang en vermindering van de serverbelasting. OkHttp biedt ingebouwde ondersteuning voor caching via de klasse Cache. De antwoordheaders Cache-Control en ETag beheren het cachebeleid: de server geeft aan hoe lang het antwoord als actueel wordt beschouwd. Bij correcte configuratie kan de cache van netwerkverzoeken de laadtijd van gegevens met 60\u201380% verkorten bij herhaalde bezoeken en de basisfunctionaliteit van de app zonder internetverbinding garanderen. De omvang van de cache voor netwerkverzoeken overschrijdt zelden 10\u201320 MB, maar bij actief gebruik van de app kan deze 50 MB bereiken. Stel de maximale cachegrootte in via de OkHttpClient.Builder-constructor en controleer de actualiteit van gecachede gegevens bij elke start van de app.

Cache voor databases en voorgecompileerde gegevens

SQLite-databases kunnen tijdens het werken tijdelijke bestanden genereren: WAL-bestanden (Write-Ahead Log), terugrollogboeken en indexpagina's. Deze bestanden worden naast de hoofddatabase opgeslagen, maar voor tijdelijke databases (bijv. volledige tekstzoekopdracht of analyse) kan plaatsing in de cachemap worden gespecificeerd. Voorgecompileerde shader-programma's van OpenGL en Vulkan worden ook in deze map gecached, wat het eerste laden van grafische sc\u00e8nes versnelt. Op iOS wordt NSCachesDirectory aanbevolen voor het opslaan van voorgecompileerde Core Data-gegevens en tijdelijke bestanden voor beeldverwerking.

Hoe werkt het wissen van de cache op Android en iOS

Het wissen van de cache kan automatisch (door het systeem) of handmatig (door de gebruiker of app) plaatsvinden. Inzicht in het gedrag van het systeem in verschillende scenario's is noodzakelijk om gegevensverlies te voorkomen.

Automatisch wissen door het systeem

Op Android start het systeem het cache-wisproces wanneer de hoeveelheid vrije ruimte op de /data-partitie onder de kritieke drempel zakt (meestal 500 MB). Het proces cacheflush analyseert de cachegrootte van alle ge\u00efnstalleerde apps en verwijdert de minst gebruikte bestanden, te beginnen met de oudste. De gebruiker kan ook handmatig de cache van alle apps wissen via de systeeminstellingen: \u201eInstellingen \u2192 Opslag \u2192 Cache \u2192 Cache wissen\u201d. Op iOS vindt automatisch wissen van Caches plaats bij het herstellen van het apparaat vanaf een back-up \u2014 iOS herstelt de inhoud van Library/Caches/ niet. Bovendien kan iOS selectief bestanden uit Caches verwijderen wanneer de vrije ruimte op het apparaat opraakt, met behulp van het purgeable storage-mechanisme voor ge\u00efsoleerde gegevens.

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

Programmatisch wissen van de cache door de app

De ontwikkelaar kan programmatisch wissen van de cache implementeren op verzoek van de gebruiker of volgens een schema. Op Android is het voldoende om alle bestanden in context.cacheDir en context.externalCacheDir te verwijderen om de eigen cache te wissen. Op iOS kan de inhoud van Library/Caches/ worden gewist, maar verwijder de map zelf niet \u2014 alleen de inhoud ervan. Het wordt aanbevolen om de gebruiker de huidige cachegrootte in de app-instellingen te tonen met een knop \u201eCache wissen\u201d met bevestiging. Volgens Google Play Console krijgen apps met een cache-wisknop 22% minder klachten over ruimtegebrek in vergelijking met apps zonder deze functie. Het wissen van de cache moet veilig zijn: de app moet de situatie waarin gecachede bestanden zijn verwijderd correct afhandelen en deze bij het volgende gebruik transparant opnieuw laden.

Verschillen tussen cacheDir op Android en iOS

Ondanks hetzelfde doel heeft de implementatie van cachemappen op Android en iOS aanzienlijke verschillen. De ontwikkelaar moet hiermee rekening houden voor een correcte werking van de app op beide platformen.

Android biedt een aparte externe cachemap via context.externalCacheDir \u2014 deze bevindt zich op de SD-kaart (indien ge\u00efnstalleerd) en wordt niet verwijderd bij het verwijderen van de app. Dit is handig voor grote mediabestanden, maar cre\u00ebert het risico van achtergelaten rommel op de geheugenkaart. iOS heeft geen concept van een externe cache: alle tijdelijke bestanden worden binnen de Sandbox-container opgeslagen en worden gegarandeerd verwijderd bij de\u00efnstallatie. Op Android is de cache zichtbaar voor de gebruiker in de app-instellingen en kan deze handmatig worden gewist. Op iOS tonen de systeeminstellingen de cachegrootte van individuele apps niet \u2014 de gebruiker kan de cache alleen wissen door de app te verwijderen en opnieuw te installeren, tenzij de ontwikkelaar een wisknop in de interface heeft toegevoegd.

Een belangrijk verschil \u2014 gedrag bij herstel. Op iOS wordt bij herstel van een iTunes- of iCloud-back-up de map Caches niet hersteld, omdat iOS ervan uitgaat dat gecachede gegevens bij de eerste start opnieuw worden aangemaakt. Op Android wordt bij herstel van Google Drive alleen Internal Storage gearchiveerd \u2014 de cache blijft leeg na herstel. In beide gevallen moet de app correct werken met een lege cache, zonder fouten aan de gebruiker te tonen en zonder functionaliteit te verliezen.

Aanbevelingen voor cachebeheer

Deskundig cachebeheer is een van de factoren die de gebruikerservaring en de beoordeling van de app be\u00efnvloeden. De volgende aanbevelingen helpen typische problemen te voorkomen en de gebruikerstevredenheid te verhogen.

• Stel een limiet in voor de cachegrootte. Gebruik DiskLruCache of vergelijkbare bibliotheken met opgave van het maximale volume in megabytes. Bij overschrijding van de limiet verwijdert de bibliotheek automatisch de minst gebruikte bestanden
• Implementeer een wisknop voor de cache in de app-instellingen. Toon de huidige cachegrootte (in het formaat \u201e12.5 MB\u201d) en vraag om bevestiging voor het wissen. Werk de weergegeven grootte bij na het wissen
• Bewaar geen bestanden in de cache die niet kunnen worden hersteld. Als gegevens kritiek zijn voor de werking van de app, bewaar ze dan in Internal Storage (Android) of Documents (iOS) en plaats in de cache alleen een kopie voor snelle toegang
• Controleer de beschikbaarheid van de externe cache voor het schrijven. Op Android kan context.externalCacheDir null retourneren als de SD-kaart niet is ge\u00efnstalleerd of niet beschikbaar is. Voorzie altijd een fallback naar de interne cache
• Gebruik een verouderingsbeleid (TTL) voor gecachede gegevens. Bewaar bestanden niet langer dan nodig: voor afbeeldingen \u2014 24\u201348 uur, voor API-antwoorden \u2014 van 5 minuten tot 1 uur, afhankelijk van de frequentie van gegevensupdates

Monitor regelmatig de cachegrootte in de app-analytics. Integreer het verzenden van de cachegrootte-metriek in Firebase Analytics of een vergelijkbaar systeem. Als de gemiddelde cachegrootte 100 MB overschrijdt, optimaliseer dan de cachingstrategie: verlaag de TTL voor zelden gebruikte gegevens, implementeer beeldcompressie voor het cachen (WebP in plaats van PNG, verlaging van JPEG-kwaliteit naar 85%), gebruik paginering voor het laden van inhoud van de server. Onthoud dat gebruikers met apparaten van 16\u201332 GB bijzonder gevoelig zijn voor de app-grootte: bij het bereiken van 200 MB cache beginnen veel gebruikers naar een manier te zoeken om te wissen of verwijderen ze gewoon de app. Volgens een Google-enqu\u00eate heeft 38% van de gebruikers ten minste \u00e9\u00e9n app verwijderd vanwege ongecontroleerde cachegroei en ingenomen ruimte.