Disk Cache: mi ez, iOS lemezgyorsítótár és működési elvek

Mi az a Disk Cache iOS-ben?

Disk Cache — az adatok ideiglenes tárolásának technológiája az eszköz állandó tárolóján (flash memória) a későbbi, ugyanazon adatokra irányuló kérések felgyorsítása érdekében. A RAM gyorsítótárral ellentétben a Disk Cache megőrzi az adatokat az alkalmazás és akár az eszköz újraindítása után is.

Az iOS két fő gyorsítótárazási szintet kínál: operatív (NSCache, memória) és lemez (URLCache, fájlrendszer). A lemezgyorsítótár 10–100-szor lassabb, mint az operatív, de jelentősen gyorsabb, mint egy hálózati kérés — a különbség 2–3 nagyságrend lehet. Az optimális stratégia kétszintű gyorsítótárat használ: memóriát a forró adatokhoz és lemezt a hideg adatokhoz.

Az Apple Performance Optimization Guide, 2023 szerint a megfelelően konfigurált Disk Cache 60–80%-kal csökkenti a tartalom betöltési idejét ismételt megtekintéseknél és 40–70%-kal mérsékli a forgalomfogyasztást. Médiatartalommal rendelkező alkalmazásoknál (képek, videók, audió) a gyorsítótárazás kritikus UX-tényező.

URLCache: beépített gyorsítótárazási mechanizmus

URLCache — egy beépített Foundation osztály, amely kombinált gyorsítótárat valósít meg URLSession kérésekhez. Automatikusan menti a szerver válaszait a lemezre és a memóriába, kezelve a gyorsítótár méretét és az érvénytelenítési politikákat a Cache-Control, Expires és ETag HTTP fejlécek alapján.

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)

Gyorsítótárazási politikák Az URLCache meghatározza, mikor használja a gyorsítótárazott adatokat és mikor hajtson végre új kérést. Főbb politikák: useProtocolCachePolicy (a szerver fejlécei alapján), reloadIgnoringLocalCacheData (mindig a szerverről), returnCacheDataElseLoad (először a gyorsítótár), returnCacheDataDontLoad (csak gyorsítótár — offline mód).

Cache-Control — HTTP fejléc, amelyet a szerver a válasszal együtt küld, jelezve a max-age (élettartam másodpercben), must-revalidate (aktualitás ellenőrzése), no-cache (ne használd ellenőrzés nélkül) és no-store (ne tárold gyorsítótárban) paramétereket. Az iOS szigorúan betartja ezeket a fejléceket automatikusan, ha az URLCache-t használja a useProtocolCachePolicy politikával.

Egyedi gyorsítótárazási stratégiák és érvénytelenítés

Egyedi gyorsítótár akkor szükséges, ha a beépített URLCache nem elegendő: feldolgozott képek, szerializált adatmodellek vagy számítási eredmények tárolásához. Ilyen esetekben a fejlesztő saját gyorsítótárazási rendszert hoz létre az alkalmazás Sandbox-jában található Caches könyvtár alapján.

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

Gyorsítótár érvénytelenítési stratégiák határozzák meg, mikor tekintendők elavultnak a tárolt adatok: TTL (Time-To-Live) — az adatok rögzített ideig élnek az írás után; event-driven — érvénytelenítés esemény bekövetkeztekor (pl. adatok frissítése a szerveren); version-based — érvénytelenítés az API verziójának vagy az adatformátumnak a változásakor; LRU (Least Recently Used) — a legkevésbé használt bejegyzések automatikus eltávolítása a méretkorlát túllépésekor.

Gyakorlati szabály: A TTL a hírek és a kiszámíthatóan elavuló tartalmak számára alkalmas. Event-driven — a push értesítéseken keresztül a szerver által kezelt adatokhoz. Version-based — konfigurációkhoz és adatmodell-gyorsítótárakhoz. LRU — univerzális választás korlátozott lemezterülettel rendelkező médiafájlokhoz.

A gyorsítótár teljesítménye és korlátai

A Disk Cache teljesítményét a hit ratio méri — a gyorsítótárból, hálózati hozzáférés nélkül kiszolgált kérések százalékos aránya. A jól konfigurált képgyorsítótár tipikus hit ratio-ja 70–90%, API-válaszok esetén 40–60%, streaming videó esetén 30–50%.

A Disk Cache korlátai iOS-ben: a rendszer bármikor törölheti a Caches könyvtár tartalmát, ha kevés a lemezterület. Ez a viselkedés nem konfigurálható — az iOS maga dönti el, mikor és mely gyorsítótárazott fájlokat távolítsa el. Ezért a gyorsítótár nem tartalmazhat olyan adatokat, amelyek nem állíthatók helyre a hálózatból vagy más forrásokból.

Hatás a flash memóriára: a gyakori írás a Disk Cache-be felgyorsítja a flash memória kopását. Az iOS TRIM-et és wear levelinget használ a kopás minimalizálására, de a fejlesztőknek ajánlott kerülni a túlzott írást: ne frissítsék a gyorsítótárat gyakrabban, mint 5 percenként ugyanazon fájl esetében; csoportosítsák a kis írásokat egyetlenbe; használják az NSCache-t az ideiglenes adatokhoz, amelyeket nem kell lemezen tárolni.

Legjobb gyakorlatok a gyorsítótárazáshoz iOS-ben

Kétszintű gyorsítótár — szabványos architektúra iOS alkalmazásokhoz: memória (NSCache) a gyakran elért adatokhoz és lemez (URLCache vagy egyedi) a munkamenetek között megőrzendő adatokhoz. Élettartam a memóriában — percek, a lemezen — órák vagy napok.

Képek gyorsítótárazása: használjon specializált könyvtárakat (Kingfisher, SDWebImage, Nuke), amelyek automatikus érvénytelenítéssel, memóriakezeléssel és aszinkron lemezírásal rendelkező kétszintű gyorsítótárat valósítanak meg. A képgyorsítótár saját implementációja megköveteli a dekódolás, színtér és méretezés figyelembevételét.

Gyorsítótár és biztonság: ne tároljon bizalmas adatokat (jelszavak, tokenek, személyes adatok) titkosítás nélkül a lemezen. Az URLCache alapértelmezés szerint nem titkosítja az adatokat — használja az NSFileProtection-t vagy alkalmazásszintű titkosítást az érzékeny tartalomhoz. Hálózati kérésekhez engedélyezéssel használja a .reloadIgnoringLocalCacheData politikát.

Gyorsítótár figyelése: kövesse nyomon a hit ratio-t, a gyorsítótár aktuális méretét és az írások számát percenként. Ha a hit ratio 30% alá csökken — a gyorsítótár hatástalan, és felül kell vizsgálni a stratégiát vagy növelni a méretet. A Point-Free (2024) szerint a gyorsítótár figyelése az iOS alkalmazások teljesítményoptimalizálásának egyik leginkább alábecsült gyakorlata.