Applikationens cachekatalog — vad det är, syfte och hur man rensar det i mobilutveckling

Vad är applikationens cachekatalog?

Cachekatalogen är en speciell katalog i applikationens interna (eller externa) lagring, avsedd för temporära filer. Huvudskillnaden från Internal Storage: systemet har rätt att ta bort filer från cache utan föregående meddelande om enheten har ont om ledigt utrymme. Därför bör applikationen aldrig lagra den enda kopian av viktiga användardata i cachen. Cache är optimal för nedladdade bilder, serversvar, förkompilerade resurser och alla andra data som kan återställas på distans eller återskapas programmatiskt.

På Android finns cachekatalogen på sökvägen /data/data/<package>/cache/ och är tillgänglig via context.cacheDir. Cachestorleken är inte explicit begränsad, men Google Play rekommenderar att inte överskrida 100 MB, eftersom applikationer med stor cache får negativa användarrecensioner. På iOS finns cachekatalogen inuti Sandbox-behållaren på sökvägen Library/Caches/ och är tillgänglig via NSCachesDirectory. iOS kan ta bort filer från Caches vid återställning av enheten från en säkerhetskopia eller vid kritisk brist på utrymme — detta måste meddelas användarna i applikationens dokumentation.

Att förstå vilka data som säkert kan placeras i cache och vilka som bör lagras i Internal Storage eller Documents är en nyckelkunskap för utvecklare. Felaktig användning av cache leder till två motsatta problem: antingen tar applikationen för mycket plats (om utvecklaren lagrar data som borde vara i Documents i cachen) eller förlorar användaren data (om utvecklaren lagrar data som borde sparas permanent i cachen). Följ den enkla regeln: om data kan återställas — cache, om återställning inte är möjlig — Internal Storage eller Documents.

Syfte och typer av cachad data

Olika datatyper har olika återskapningshastighet och kapacitetskrav. Att förstå dessa egenskaper hjälper utvecklaren att korrekt välja vilka filer som ska placeras i cache och vilka i permanent lagring.

Cache för bilder och mediafiler

Den vanligaste typen av cachad data är bilder som laddats från nätverket. Bibliotek som Glide, Picasso och Coil sparar automatiskt nedladdade bilder i applikationens cachekatalog. Typisk cachestorlek för bilder i sociala applikationer är mellan 50 och 200 MB. Cachestorleken beror på enhetens skärmupplösning och mängden innehåll som visas. Glide använder två nivåers cachning: först kontrolleras L1-cache i RAM (LRU-algoritm), sedan L2-cache på disk. Detta säkerställer snabb inläsning av återkommande bilder utan ytterligare nätverksförfrågningar. Genom att ställa in maximal diskcachestorlek via DiskCacheStrategy kan man kontrollera utrymmesanvändningen: när gränsen överskrids tar biblioteket automatiskt bort de minst använda filerna.

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 ->
        // skriv data till cache
    }
}

Cache för nätverksförfrågningar

Svar från API-förfrågningar kan cachas för offlineåtkomst och minskad serverbelastning. OkHttp har inbyggt cache-stöd via klassen Cache. Cache-Control- och ETag-svarshuvuden styr cache-policyn: servern anger hur länge svaret anses vara giltigt. Vid korrekt konfiguration kan cache för nätverksförfrågningar minska dataladdningstiden med 60–80% vid återkommande besök och ge grundläggande funktionalitet utan internetanslutning. Cachestorleken för nätverksförfrågningar överstiger sällan 10–20 MB men kan nå 50 MB vid aktiv användning. Konfigurera maximal cachestorlek via OkHttpClient.Builder-konstruktorn och kontrollera cachade datas giltighet vid varje start av applikationen.

Cache för databaser och förkompilerad data

SQLite-databaser kan generera temporära filer under drift: WAL-filer (Write-Ahead Log), återrullningsloggar och indexsidor. Dessa filer lagras bredvid huvuddatabasen, men för temporära databaser (t.ex. fulltextsökning eller analys) kan man ange placering i cachekatalogen. Förkompilerade shader-program för OpenGL och Vulkan cachas också i denna katalog, vilket påskyndar första inläsningen av grafikscener. På iOS rekommenderas NSCachesDirectory för lagring av förkompilerad Core Data-data och temporära filer för bildbehandling.

Hur cache-rensning fungerar på Android och iOS

Cache-rensning kan ske automatiskt (av systemet) eller manuellt (av användaren eller applikationen). Att förstå systemets beteende i olika scenarier är nödvändigt för att förhindra dataförlust.

Automatisk rensning av systemet

På Android startar systemet en cache-rensningsprocess när ledigt utrymme på /data-partitionen sjunker under en kritisk tröskel (vanligtvis 500 MB). Processen cacheflush analyserar cachestorleken för alla installerade applikationer och tar bort de minst använda filerna, med början från de äldsta. Användaren kan också manuellt rensa cache för alla applikationer via systeminställningarna: “Inställningar → Lagring → Cache → Rensa cache”. På iOS sker automatisk cache-rensning vid återställning av enheten från en säkerhetskopia — iOS återställer inte innehållet i Library/Caches/. Dessutom kan iOS selektivt ta bort filer från Caches när ledigt utrymme på enheten tar slut, med hjälp av rensningsbar lagringsmekanism för isolerade data.

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

Programmatisk cache-rensning av applikationen

Utvecklaren kan implementera programmatisk cache-rensning på användarens begäran eller enligt schema. På Android räcker det att ta bort alla filer i context.cacheDir och context.externalCacheDir för att rensa sin egen cache. På iOS kan man rensa innehållet i Library/Caches/, men ta inte bort själva katalogen — bara dess innehåll. Det rekommenderas att visa användaren den aktuella cachestorleken i applikationsinställningarna och en knapp “Rensa cache” med bekräftelse. Enligt Google Play Console får applikationer med cache-rensningsknapp 22% färre klagomål om utrymmesbrist jämfört med applikationer utan denna funktion. Cache-rensning bör vara säker: applikationen måste korrekt hantera situationen när cachade filer har tagits bort och transparent ladda om dem vid nästa användning.

Skillnader mellan cacheDir på Android och iOS

Trots samma syfte har implementeringen av cachekataloger på Android och iOS betydande skillnader. Utvecklaren måste ta hänsyn till dem för att applikationen ska fungera korrekt på båda plattformarna.

Android tillhandahåller en separat extern cachekatalog via context.externalCacheDir — den finns på SD-kortet (om installerat) och tas inte bort vid avinstallation av applikationen. Detta är praktiskt för stora mediafiler men skapar risk för att skräp blir kvar på minneskortet. iOS har inte konceptet extern cache: alla temporära filer lagras inuti Sandbox-behållaren och tas garanterat bort vid avinstallation. På Android är cache synlig för användaren i applikationsinställningarna, och användaren kan rensa den manuellt. På iOS visar systeminställningarna inte cachestorleken för enskilda applikationer — användaren kan bara rensa cache genom att ta bort och installera om applikationen, om utvecklaren inte har lagt till en rensningsknapp i gränssnittet.

En viktig skillnad är beteendet vid återställning. På iOS återställs inte Caches-katalogen vid återställning från iTunes- eller iCloud-säkerhetskopia, eftersom iOS anser att cachad data kommer att återskapas vid första starten. På Android vid återställning från Google Drive säkerhetskopieras endast Internal Storage — cache förblir tom efter återställning. I båda fallen måste applikationen fungera korrekt med tom cache, utan att visa fel för användaren och utan att förlora funktionalitet.

Rekommendationer för cachehantering

God cachehantering är en av faktorerna som påverkar användarupplevelsen och applikationens betyg. Följande rekommendationer hjälper till att undvika typiska problem och öka användarnöjdheten.

• Sätt en storleksgräns för cache. Använd DiskLruCache eller liknande bibliotek med angivelse av maximal volym i megabyte. När gränsen överskrids tar biblioteket automatiskt bort de minst använda filerna
• Implementera en rensningsknapp i applikationsinställningarna. Visa aktuell cachestorlek (i formatet “12,5 MB”) och begär bekräftelse före rensning. Uppdatera den visade storleken efter rensning
• Förvara inte filer i cache som inte kan återställas. Om data är kritiska för applikationens funktion, lagra dem i Internal Storage (Android) eller Documents (iOS), och placera endast en kopia för snabb åtkomst i cache
• Kontrollera tillgängligheten av extern cache före skrivning. På Android kan context.externalCacheDir returnera null om SD-kortet inte är installerat eller inte tillgängligt. Ange alltid en reservplan med intern cache
• Använd en föråldringspolicy (TTL) för cachad data. Förvara inte filer längre än nödvändigt: för bilder — 24–48 timmar, för API-svar — från 5 minuter till 1 timme beroende på datauppdateringsfrekvens

Övervaka regelbundet cachestorleken i applikationsanalys. Integrera sändning av cachestorleksmetrik till Firebase Analytics eller liknande system. Om den genomsnittliga cachestorleken överstiger 100 MB, optimera cachningsstrategin: minska TTL för sällan använda data, inför bildkomprimering före cachning (WebP istället för PNG, sänk JPEG-kvalitet till 85%), använd paginering för inladdning av innehåll från servern. Kom ihåg att användare med enheter på 16–32 GB är särskilt känsliga för applikationens storlek: när cachen når 200 MB börjar många användare leta efter ett sätt att rensa eller helt enkelt ta bort applikationen. Enligt en Google-undersökning har 38% av användarna tagit bort minst en applikation på grund av okontrollerad cachetillväxt och utrymmesanvändning.