Az alkalmazás gyorsítótár könyvtára — mi ez, rendeltetése és tisztítása a mobilfejlesztésben

Mi az alkalmazás gyorsítótár könyvtára?

A gyorsítótár könyvtár egy speciális könyvtár az alkalmazás belső (vagy külső) memóriájában, ideiglenes fájlok számára. A fő különbség az Internal Storage-tól: a rendszer jogosult fájlokat törölni a gyorsítótárból értesítés nélkül, ha az eszközön nincs elég szabad hely. Ezért az alkalmazás soha nem tárolhatja a felhasználói adatok egyetlen példányát a gyorsítótárban. A gyorsítótár optimális letöltött képekhez, szerverválaszokhoz, előre lefordított erőforrásokhoz és minden olyan adathoz, amely távolról visszaállítható vagy programozottan újrateremthető.

Androidon a gyorsítótár könyvtár a /data/data/<package>/cache/ elérési úton található, és a context.cacheDir-en keresztül érhető el. A gyorsítótár mérete nincs explicit korlátozva, de a Google Play azt javasolja, hogy ne haladja meg a 100 MB-ot, mivel a nagy gyorsítótárral rendelkező alkalmazások negatív felhasználói értékeléseket kapnak. iOS-en a gyorsítótár könyvtár a Sandbox-konténeren belül a Library/Caches/ elérési úton található, és a NSCachesDirectory-n keresztül érhető el. Az iOS törölheti a Caches fájljait az eszköz biztonsági másolatból történő visszaállításakor vagy kritikus helyhiány esetén — erről tájékoztatni kell a felhasználókat az alkalmazás dokumentációjában.

Annak megértése, hogy mely adatok helyezhetők biztonságosan a gyorsítótárba, és melyeket kell az Internal Storage-ban vagy Documents-ben tárolni, kulcsfontosságú fejlesztői készség. A gyorsítótár helytelen használata két ellentétes problémához vezet: vagy az alkalmazás túl sok helyet foglal (ha a fejlesztő a gyorsítótárban tárolja azt, amit a Documents-ben kellene), vagy a felhasználó adatokat veszít (ha a fejlesztő a gyorsítótárban tárolja azt, amit állandóan kellene megőrizni). Tartsa be az egyszerű szabályt: ha az adatok visszaállíthatók — gyorsítótár, ha a visszaállítás lehetetlen — Internal Storage vagy Documents.

Rendeltetés és a gyorsítótárazott adatok típusai

A különböző adattípusok eltérő újrateremtési sebességgel és helyigénnyel rendelkeznek. Ezen jellemzők megértése segít a fejlesztőnek helyesen kiválasztani, hogy mely fájlokat helyezze a gyorsítótárba és melyeket az állandó tárolóba.

Képek és médiafájlok gyorsítótárazása

A leggyakoribb gyorsítótárazott adattípus a hálózatról letöltött képek. A Glide, Picasso és Coil könyvtárak automatikusan elmentik a letöltött képeket az alkalmazás gyorsítótár könyvtárába. A képek gyorsítótárának tipikus mérete a közösségi alkalmazásokban 50 és 200 MB között van. A gyorsítótár mérete az eszköz képernyőfelbontásától és a megtekintett tartalom mennyiségétől függ. A Glide kétszintű gyorsítótárazást használ: először az L1-gyorsítótárat ellenőrzi a RAM-ban (LRU-algoritmus), majd az L2-gyorsítótárat a lemezen. Ez biztosítja a többször megtekintett képek gyors betöltését anélkül, hogy újra le kellene kérni azokat a hálózatról. A lemez gyorsítótár maximális méretének beállítása a DiskCacheStrategy-en keresztül lehetővé teszi a helyfoglalás szabályozását: a korlát túllépésekor a könyvtár automatikusan eltávolítja a legkevésbé használt fájlokat.

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 ->
        // adatok írása a gyorsítótárba
    }
}

Hálózati kérések gyorsítótárazása

Az API-kérések válaszai gyorsítótárazhatók offline hozzáféréshez és a szerver terhelésének csökkentéséhez. Az OkHttp beépített gyorsítótárazási támogatást nyújt a Cache osztályon keresztül. A Cache-Control és ETag válaszfejlécek szabályozzák a gyorsítótárazási politikát: a szerver határozza meg, mennyi ideig tekinthető érvényesnek a válasz. Megfelelő beállítással a hálózati kérések gyorsítótára 60-80%-kal csökkentheti az adatok betöltési idejét ismételt látogatásokkor, és alapvető funkcionalitást biztosíthat internetkapcsolat nélkül. A hálózati kérések gyorsítótárának mérete ritkán haladja meg a 10-20 MB-ot, de aktív használat mellett elérheti az 50 MB-ot. Állítsa be a gyorsítótár maximális méretét az OkHttpClient.Builder konstruktorán keresztül, és ellenőrizze a gyorsítótárazott adatok érvényességét az alkalmazás minden indításakor.

Adatbázisok és előre lefordított adatok gyorsítótárazása

Az SQLite adatbázisok ideiglenes fájlokat hozhatnak létre működés közben: WAL-fájlokat (Write-Ahead Log), visszaállítási naplókat és indexoldalakat. Ezek a fájlok a fő adatbázis mellett tárolódnak, de az ideiglenes adatbázisok (például teljes szöveges keresés vagy analitika) esetében megadható a gyorsítótár könyvtárba helyezés. Az előre lefordított OpenGL és Vulkan shader programok szintén ebben a könyvtárban kerülnek gyorsítótárazásra, ami felgyorsítja a grafikus jelenetek első betöltését. iOS-en az NSCachesDirectory ajánlott az előre lefordított Core Data adatok és a képfeldolgozás ideiglenes fájljainak tárolására.

Hogyan működik a gyorsítótár tisztítása Androidon és iOS-en

A gyorsítótár tisztítása történhet automatikusan (a rendszer által) vagy kézzel (a felhasználó vagy az alkalmazás által). A rendszer viselkedésének megértése különböző forgatókönyvekben elengedhetetlen az adatvesztés megelőzéséhez.

Automatikus tisztítás a rendszer által

Androidon a rendszer elindítja a gyorsítótár tisztítási folyamatát, amikor a /data partíción lévő szabad hely a kritikus küszöbérték (általában 500 MB) alá csökken. A cacheflush folyamat elemzi az összes telepített alkalmazás gyorsítótárának méretét, és eltávolítja a legkevésbé használt fájlokat, kezdve a legrégebbiekkel. A felhasználó manuálisan is törölheti az összes alkalmazás gyorsítótárát a rendszerbeállításokon keresztül: „Beállítások → Tárhely → Gyorsítótár → Gyorsítótár törlése”. iOS-en a Caches automatikus tisztítása az eszköz biztonsági másolatból történő visszaállításakor történik — az iOS nem állítja vissza a Library/Caches/ tartalmát. Ezenkívül az iOS szelektíven törölhet fájlokat a Caches-ből, amikor elfogy a szabad hely az eszközön, a purgeable storage mechanizmus segítségével az elkülönített adatokhoz.

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

Programozott gyorsítótár tisztítás az alkalmazás által

A fejlesztő programozott tisztítást valósíthat meg a gyorsítótárhoz a felhasználó kérésére vagy ütemezetten. Androidon a saját gyorsítótár tisztításához elegendő törölni az összes fájlt a context.cacheDir és context.externalCacheDir könyvtárakból. iOS-en törölhető a Library/Caches/ tartalma, de magát a könyvtárat ne törölje — csak a tartalmát. Javasolt megjeleníteni a gyorsítótár aktuális méretét az alkalmazás beállításaiban, valamint egy „Gyorsítótár törlése” gombot megerősítéssel. A Google Play Console adatai szerint a gyorsítótár törlése gombbal rendelkező alkalmazások 22%-kal kevesebb helyhiányra vonatkozó panaszt kapnak, mint az ilyen funkció nélküli alkalmazások. A gyorsítótár tisztításának biztonságosnak kell lennie: az alkalmazásnak helyesen kell kezelnie azt a helyzetet, amikor a gyorsítótárazott fájlok törlésre kerültek, és átláthatóan újra kell töltenie azokat a következő hozzáféréskor.

A cacheDir különbségei Android és iOS között

Az azonos rendeltetés ellenére a gyorsítótár könyvtárak megvalósítása Androidon és iOS-en jelentős eltéréseket mutat. A fejlesztőnek figyelembe kell vennie ezeket az alkalmazás helyes működéséhez mindkét platformon.

Android külön külső gyorsítótár könyvtárat biztosít a context.externalCacheDir-en keresztül — ez az SD-kártyán található (ha telepítve van), és az alkalmazás eltávolításakor nem törlődik. Ez kényelmes nagy médiafájlok számára, de kockázatot jelent a memóriakártyán maradó szemét tekintetében. Az iOS nem rendelkezik külső gyorsítótár koncepcióval: az összes ideiglenes fájl a Sandbox-konténeren belül tárolódik, és garantáltan törlődik az eltávolításkor. Androidon a gyorsítótár látható a felhasználó számára az alkalmazás beállításaiban, és kézzel törölheti azt. iOS-en a rendszerbeállítások nem mutatják az egyes alkalmazások gyorsítótárának méretét — a felhasználó csak az alkalmazás törlésével és újratelepítésével törölheti a gyorsítótárat, hacsak a fejlesztő nem adott hozzá tisztító gombot a felülethez.

Fontos különbség — viselkedés visszaállításkor. iOS-en az iTunes vagy iCloud biztonsági másolatból történő visszaállításkor a Caches könyvtár nem áll helyre, mivel az iOS szerint a gyorsítótárazott adatok újra létrejönnek az első indításkor. Androidon a Google Drive-ból történő visszaállításkor csak az Internal Storage kerül biztonsági mentésre — a gyorsítótár üres marad a visszaállítás után. Mindkét esetben az alkalmazásnak helyesen kell működnie üres gyorsítótárral anélkül, hogy hibákat mutatna a felhasználónak vagy elveszítené a funkcionalitást.

Gyorsítótár kezelési javaslatok

A gyorsítótár megfelelő kezelése az alkalmazásban az egyik tényező, amely befolyásolja a felhasználói élményt és az alkalmazás értékelését. Az alábbi javaslatok segítenek elkerülni a tipikus problémákat és növelni a felhasználói elégedettséget.

• Állítson be méretkorlátot a gyorsítótárhoz. Használja a DiskLruCache-t vagy hasonló könyvtárakat a maximális méret megadásával megabájtban. A korlát túllépésekor a könyvtár automatikusan eltávolítja a legkevésbé használt fájlokat
• Valósítson meg tisztító gombot a gyorsítótárhoz az alkalmazás beállításaiban. Jelenítse meg a gyorsítótár aktuális méretét („12,5 MB” formátumban), és kérjen megerősítést a tisztítás előtt. A tisztítás után frissítse a megjelenített méretet
• Ne tároljon a gyorsítótárban olyan fájlokat, amelyek nem állíthatók vissza. Ha az adatok kritikusak az alkalmazás működéséhez, tárolja azokat Internal Storage-ban (Android) vagy Documents-ben (iOS), a gyorsítótárba pedig csak egy másolatot tegyen a gyors hozzáféréshez
• Ellenőrizze a külső gyorsítótár elérhetőségét írás előtt. Androidon a context.externalCacheDir null értéket adhat vissza, ha az SD-kártya nincs telepítve vagy nem elérhető. Mindig gondoskodjon a belső gyorsítótárra történő visszaesésről
• Használjon elavulási politikát (TTL) a gyorsítótárazott adatokhoz. Ne tárolja a fájlokat a szükségesnél tovább: képek esetében — 24-48 óra, API-válaszok esetében — 5 perctől 1 óráig az adatok frissítési gyakoriságától függően

Rendszeresen figyelje a gyorsítótár méretét az alkalmazás analitikájában. Integrálja a gyorsítótár méretének metrikáját a Firebase Analytics vagy hasonló rendszerbe. Ha az átlagos gyorsítótár méret meghaladja a 100 MB-ot, optimalizálja a gyorsítótárazási stratégiát: csökkentse a TTL-t a ritkán használt adatoknál, vezesse be a képek tömörítését a gyorsítótárazás előtt (WebP PNG helyett, JPEG minőség csökkentése 85%-ra), használjon lapozást a tartalom szerverről történő betöltéséhez. Ne feledje, hogy a 16-32 GB kapacitású eszközökkel rendelkező felhasználók különösen érzékenyek az alkalmazás méretére: 200 MB gyorsítótár elérésekor sok felhasználó elkezdi keresni a tisztítási lehetőséget, vagy egyszerűen eltávolítja az alkalmazást. A Google felmérése szerint a felhasználók 38%-a távolított el legalább egy alkalmazást a gyorsítótár ellenőrizetlen növekedése és helyfoglalása miatt.