Disk Cache: какво е, дисков кеш в iOS и принципи на работа

Какво е Disk Cache в iOS?

Disk Cache — технология за временно съхранение на данни на постоянното хранилище на устройството (флаш памет) с цел ускоряване на последващи заявки към същите данни. За разлика от RAM кеша, Disk Cache запазва данните след рестартиране на приложението и дори на устройството.

iOS предоставя две основни нива на кеширане: оперативно (NSCache, памет) и дисково (URLCache, файлова система). Дисковият кеш е 10–100 пъти по-бавен от оперативния, но значително по-бърз от мрежова заявка — разликата може да бъде от 2 до 3 порядъка. Оптималната стратегия използва двустепенен кеш: памет за горещи данни и диск за студени данни.

Според Apple Performance Optimization Guide, 2023, правилно конфигурираният Disk Cache намалява времето за зареждане на съдържание с 60–80% за повторни прегледи и намалява консумацията на трафик с 40–70%. За приложения с медийно съдържание (изображения, видео, аудио) кеширането е критичен фактор за UX.

URLCache: вграден механизъм за кеширане

URLCache — вграден клас на Foundation, който имплементира комбиниран кеш за заявки на URLSession. Той автоматично записва отговорите на сървъра на диска и в паметта, управлявайки размера на кеша и политиките за инвалидация въз основа на HTTP заглавките Cache-Control, Expires и ETag.

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)

Политики за кеширане на URLCache определят кога да се използват кеширани данни и кога да се изпълни нова заявка. Основни политики: useProtocolCachePolicy (по заглавки на сървъра), reloadIgnoringLocalCacheData (винаги от сървъра), returnCacheDataElseLoad (първо кеш), returnCacheDataDontLoad (само кеш — офлайн режим).

Cache-Control — HTTP заглавка, която сървърът изпраща заедно с отговора, указвайки max-age (време на живот в секунди), must-revalidate (проверка на актуалност), no-cache (не използвай без проверка) и no-store (не кеширай). iOS стриктно спазва тези заглавки автоматично при използване на URLCache с политика useProtocolCachePolicy.

Персонализирани стратегии за кеширане и инвалидация

Персонализиран кеш е необходим, когато вграденият URLCache не е достатъчен: за съхранение на обработени изображения, сериализирани модели данни или резултати от изчисления. В такива случаи разработчикът създава собствена система за кеширане, базирана на директорията Caches в Sandbox на приложението.

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

Стратегии за инвалидация на кеша определят кога съхранените данни се считат за остарели: TTL (Time-To-Live) — данните живеят фиксирано време след запис; event-driven — инвалидация при настъпване на събитие (напр. обновяване на данни на сървъра); version-based — инвалидация при промяна на версията на API или формата на данните; LRU (Least Recently Used) — автоматично премахване на най-рядко използваните записи при превишаване на лимита на размера.

Практическо правило: TTL е подходящ за новини и съдържание, което остарява предвидимо. Event-driven — за данни, управлявани от сървъра чрез push известия. Version-based — за конфигурации и кеш на модели данни. LRU — универсален избор за медийни файлове с ограничено дисково пространство.

Производителност и ограничения на кеша

Производителността на Disk Cache се измерва чрез hit ratio — процент на заявките, обслужени от кеша без обръщение към мрежата. Типичен hit ratio за добре конфигуриран кеш на изображения е 70–90%, за API отговори — 40–60%, за стрийминг видео — 30–50%.

Ограничения на Disk Cache в iOS: системата може да изтрие съдържанието на директорията Caches по всяко време при недостиг на място на диска. Това поведение не може да се конфигурира — iOS сама решава кога и кои кеширани файлове да изтрие. Затова кешът не трябва да съдържа данни, които не могат да бъдат възстановени от мрежата или други източници.

Влияние върху флаш паметта: честото записване в Disk Cache ускорява износването на флаш паметта. iOS използва TRIM и wear leveling за минимизиране на износването, но на разработчиците се препоръчва да избягват прекомерно записване: да не обновяват кеша по-често от веднъж на 5 минути за един и същ файл; да групират малки записи в един; да използват NSCache за временни данни, които не е необходимо да се съхраняват на диска.

Най-добри практики за кеширане в iOS

Двустепенен кеш — стандартна архитектура за iOS приложения: памет (NSCache) за данни, до които се осъществява чест достъп, и диск (URLCache или персонализиран) за данни, които трябва да се запазят между сесиите. Време на живот в паметта — минути, на диска — часове или дни.

Кеширане на изображения: използвайте специализирани библиотеки (Kingfisher, SDWebImage, Nuke), които имплементират двустепенен кеш с автоматична инвалидация, управление на паметта и асинхронен запис на диска. Самостоятелната имплементация на кеш за изображения изисква отчитане на декодирането, цветовото пространство и мащабирането.

Кеш и сигурност: не кеширайте поверителни данни (пароли, токени, лични данни) на диска без криптиране. URLCache по подразбиране не криптира данни — използвайте NSFileProtection или криптиране на ниво приложение за чувствително съдържание. За мрежови заявки с оторизация използвайте политика .reloadIgnoringLocalCacheData.

Мониторинг на кеша: следете hit ratio, текущия размер на кеша и броя записи на минута. Ако hit ratio падне под 30% — кешът е неефективен и изисква преразглеждане на стратегията или увеличаване на размера. Според Point-Free (2024), мониторингът на кеша е една от най-подценяваните практики за оптимизация на производителността на iOS приложения.