Міграція кешу при оновленні мобільного додатку

Реалізація міграції кешу при оновленні мобільного додатку

Уявіть: ви випустили оновлення, а користувачі масово скаржаться на вильоти та старі дані. Причина — неінвалідований кеш. Старі зображення завантажені під старими ключами, JSON-відповіді серіалізовані в застарілий формат, HTTP-кеш містить заголовки з битими URL. Якщо не очистити кеш при оновленні — користувач бачить перемішані дані з різних версій, або додаток падає на десеріалізації. Розглянемо на прикладі реального проекту: додаток для доставки, де після оновлення користувачі бачили ціни зі старої відповіді API, що призводило до збитків. Правильна інвалідація кешу вирішила проблему за один день. Міграція кешу — обов'язковий етап будь-якого оновлення. Ми, розробники з 10-річним досвідом, зібрали перевірені методи для iOS та Android.

Чому кеш стає невалідним після оновлення?

Причина — несумісність форматів даних між версіями. Припустимо, у версії 1.0 API повертав об'єкт { "name": "foo" }, а в 2.0 — { "full_name": "foo bar" }. Якщо додаток закешував старий JSON і намагається десеріалізувати його в нову модель — крах. Аналогічно із зображеннями: змінилися шляхи, розміри або хеші. Згідно з документацією Apple URLCache, HTTP-кеш також може містити застарілі заголовки, що призводить до помилок завантаження.

Версіонування ключів кешу

Найпростіший і найнадійніший підхід: прив'язати ключі кешу до версії додатку або до версії API.

// Android — простір імен кешу за версією
object CacheKeyBuilder {
    private val appVersion = BuildConfig.VERSION_CODE

    fun forImage(imageId: String) = "img_v${appVersion}_$imageId"

    fun forApiResponse(endpoint: String) = "api_v${appVersion}_$endpoint"
}

// iOS — ключ з номером білда
struct CacheKeyBuilder {
    static let appVersion = Bundle.main.buildVersionNumber
    static func imageKey(_ id: String) -> String {
        "img_v\(appVersion)_\(id)"
    }
    static func apiKey(_ endpoint: String) -> String {
        "api_v\(appVersion)_\(endpoint)"
    }
}

При оновленні VERSION_CODE або buildVersionNumber всі ключі змінюються — старий кеш перестає використовуватися. Але при цьому старі файли залишаються на диску і потрібне явне очищення.

Очищення застарілого кешу при старті

// iOS class CacheManager {
    private let defaults = UserDefaults.standard
    private let lastVersionKey = "lastCachedVersion"
    
    func cleanupIfNeeded() {
        let current = Bundle.main.buildVersionNumber
        let last = defaults.string(forKey: lastVersionKey) ?? ""
        guard current != last else { return }
        clearDiskCache()
        clearURLCache()
        defaults.set(current, forKey: lastVersionKey)
    }
    
    private func clearDiskCache() {
        let cacheDir = FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask).first!
        try? FileManager.default.removeItem(at: cacheDir.appendingPathComponent("ImageCache"))
    }
    
    private func clearURLCache() {
        URLCache.shared.removeAllCachedResponses()
    }
}

Викликаємо в application(_:didFinishLaunchingWithOptions:) до ініціалізації UI.

// Android — очищення при старті
class CacheCleaner(private val context: Context) {
    fun cleanIfNeeded() {
        val prefs = context.getSharedPreferences("cache", Context.MODE_PRIVATE)
        val lastVersion = prefs.getInt("lastVersion", 0)
        val currentVersion = BuildConfig.VERSION_CODE
        if (lastVersion == currentVersion) return
        Glide.get(context).clearDiskCache()
        val cacheDir = File(context.cacheDir, "http-cache")
        cacheDir.deleteRecursively()
        prefs.edit().putInt("lastVersion", currentVersion).apply()
    }
}

Виклик з Application.onCreate() у фоновому потоці.

Kingfisher (iOS) та Glide (Android)

Обидві бібліотеки використовують власні дискові кеші. Kingfisher зберігає кеш у Library/Caches/com.onevcat.Kingfisher.ImageCache. Очищення:

KingfisherManager.shared.cache.clearDiskCache() KingfisherManager.shared.cache.clearMemoryCache() 

Glide: Glide.get(context).clearDiskCache() — тільки з фонового потоку. Офіційні репозиторії: Kingfisher, Glide.

Порівняння підходів

Як обрати стратегію міграції кешу?

Для невеликих проєктів достатньо повного очищення при кожному оновленні — це швидко реалізувати і легко перевірити. Якщо важливі швидкість запуску та користувацький досвід, обирайте версіонування ключів з фоновим очищенням. Для фінансових або медичних додатків, де кожен запис критичний, використовуйте інкрементальну міграцію з точковою інвалідацією.

Що входить у роботу

Процес роботи

1. Аудит кешування — 0.5 дня.
2. Проектування стратегії — 0.5 дня.
3. Реалізація на iOS та Android — 1-2 дні.
4. Тестування на реальних оновленнях — 0.5 дня.
5. Деплой та моніторинг — 0.5 дня.

Терміни

Базова інвалідація кешу при оновленні: від 0,5 дня. З версіонованими ключами, збереженням важливого кешу та фоновим очищенням: від 1 дня. Для складних проектів з кількома джерелами кешу: від 2 до 3 днів.

Чек-лист міграції кешу