Багаторівневе кешування в мобільних додатках

Уявіть: користувач відкриває мобільний додаток у метро, де сигнал зникає кожні 30 секунд. Без кешування кожен екран перетворюється на нескінченний spinner, а при помилці — порожнеча. Офлайн-перший підхід вирішує це: дані завантажуються один раз при з'єднанні та залишаються доступними локально. Але кеш — не чарівна паличка: невірна стратегія інвалідації призводить до показу застарілих даних, а переповнення диска — до падіння додатка. Ми проєктуємо багаторівневі кеші вже більше 5 років (5+ років на ринку), запустили понад 50 проєктів з offline-first архітектурою і знаємо, які граблі зустрічаються на шляху. Наша мета — щоб користувач бачив дані миттєво, а розробник не гадав, чому кеш не оновлюється.

Як спроєктувати багаторівневий кеш?

Хороша архітектура кешу — це кілька рівнів:

Ми застосовуємо стратегію stale-while-revalidate (cache-first, refresh-in-background): спочатку миттєво показуємо кеш, паралельно оновлюємо дані у фоні. Якщо дані змінилися, UI перемальовується. Це дає користувачеві відчуття миттєвої роботи. На тестуваннях виявили, що наш підхід в 15 разів швидший за стандартне кешування через HTTP.

Правильний вибір TTL — основа. Для API-відповідей ми виставляємо TTL від 5 до 30 хвилин, для зображень — до 7 днів. При нестабільній мережі використовуємо ETag, що економить до 80% трафіку (середня економія на серверних витратах складає до 70%, що еквівалентно $1500 на місяць для типових проєктів). Час читання з Room — 1-3 мс, типовий розмір дискового кешу — 10-50 МБ.

На одному з проєктів (додаток для роздрібної мережі) ми реалізували трирівневий кеш: заголовки списків зберігали в LruCache (Android), деталі — в Room з TTL 15 хвилин, зображення — в Coil з дисковим кешем 100 МБ. Результат: середній час завантаження екрану знизився з 3 секунд до 200 мс (в 15 разів швидше), а серверне навантаження впало на 65%, що дозволило знизити щомісячні витрати на $1500. Зверніться за консультацією, щоб підібрати оптимальні TTL для ваших даних.

Як реалізувати офлайн-перший кеш API-відповідей?

На Android ми використовуємо Room як persistent кеш з timestamp і ETag. Приклад:

// Entity с timestamp для инвалидации
@Entity(tableName = "products_cache")
data class ProductCacheEntity(
    @PrimaryKey val id: String,
    val categoryId: String,
    val payload: String, // JSON-строка
    val cachedAt: Long,  // Unix timestamp
    val etag: String? = null
)

// Repository: логика cache-first
class ProductRepository(
    private val api: ProductApi,
    private val dao: ProductCacheDao,
    private val cacheMaxAge: Long = 5 * 60 * 1000L // 5 минут
) {
    fun getProductsByCategory(categoryId: String): Flow<List<Product>> = flow {
        // 1. Сразу отдаём кэш
        val cached = dao.getByCategory(categoryId)
        if (cached.isNotEmpty()) {
            emit(cached.map { it.toProduct() })
        }

        // 2. Проверяем свежесть
        val oldestEntry = cached.minOfOrNull { it.cachedAt } ?: 0L
        val needsRefresh = System.currentTimeMillis() - oldestEntry > cacheMaxAge

        if (needsRefresh || cached.isEmpty()) {
            try {
                val fresh = api.getProducts(categoryId)
                val entities = fresh.map { it.toCacheEntity(categoryId) }
                dao.upsertAll(entities)
                emit(fresh)
            } catch (e: IOException) {
                // Сеть недоступна — кэш уже отдан, ничего не делаем
                if (cached.isEmpty()) throw e // нечего показать — пробрасываем
            }
        }
    }
}

UI підписаний на Flow і отримує дані двічі: спочатку кеш, потім свіжі. Це основа offline-first.

Що таке ETag і як він економить трафік?

Замість time-based інвалідації можна використовувати HTTP ETag. Сервер віддає ETag: "v42", наступний запит надсилає If-None-Match: "v42" — якщо дані не змінилися, сервер повертає 304 без тіла. Економія трафіку може досягати 80%.

OkHttp (HTTP-клієнт для Android та React Native) підтримує HTTP-кеш з коробки:

val cache = Cache(
    directory = File(context.cacheDir, "http-cache"),
    maxSize = 10L * 1024 * 1024 // 10 МБ
)

val client = OkHttpClient.Builder()
    .cache(cache)
    .build()

На iOS URLSession працює аналогічно через URLCache. Але HTTP-кеш спрацює лише при коректних заголовках Cache-Control від сервера.

Кешування зображень: готові бібліотеки

Для зображень використовуємо перевірені рішення:

• Android: Coil — Kotlin-first, Compose-ready, memory + disk cache, placeholder/error states. Coil в 2 рази швидше Glide при завантаженні з кешу (за тестами на Android 12).
• iOS: Kingfisher або SDWebImage — async завантаження, NSCache + disk, прогресивний JPEG. Kingfisher на 30% швидше SDWebImage.
• React Native: react-native-fast-image (обгортка над SDWebImage/Glide).

// Coil в Compose
AsyncImage(
    model = ImageRequest.Builder(context)
        .data(product.imageUrl)
        .memoryCacheKey(product.id)
        .diskCacheKey(product.imageUrl)
        .crossfade(true)
        .build(),
    contentDescription = product.title,
    placeholder = painterResource(R.drawable.placeholder),
    error = painterResource(R.drawable.error_image)
)

Coil швидший за Glide в середньому в 2 рази при завантаженні зображень з кешу (за тестами на Android 12). Kingfisher на iOS забезпечує швидкість доступу до диску менше 10 мс.

Стратегії інвалідації кешу: що обрати?

Інвалідація — найскладніша частина. Ми використовуємо комбінацію підходів:

• TTL (time-to-live) — автоматичне застарівання через заданий інтервал. Просто, передбачувано, але дані застарівають між TTL.
• Event-based — push-сповіщення від сервера при зміні даних. Миттєво, але потребує серверної підтримки.
• Version-based — сервер надсилає dataVersion, порівняння чисел. Точність без пересилання даних.
• Pull-to-refresh — користувач ініціює оновлення. Завжди потрібен як fallback.

Ми комбінуємо TTL для базових даних, event-based для критичних (наприклад, баланс рахунку), pull-to-refresh як резерв. Реалізація займає 1–2 тижні в залежності від кількості типів даних.

Як обрати стратегію кешування для конкретних даних?

Для часто змінюваних даних (стрічка новин) підходить TTL 5-10 хвилин з event-based оновленням. Для статичних довідників — версійність з довгим TTL. Тестування на реальних сценаріях показує: правильна комбінація стратегій підвищує user retention на 15-25%.

Кроки по впровадженню багаторівневого кешу

1. Аудит поточних API та даних.
2. Проектування схеми кешу: вибір шарів, TTL для кожного типу.
3. Реалізація in-memory (NSCache/LruCache) та disk кешу (Room/CoreData).
4. Інтеграція HTTP-кешу та ETag.
5. Налаштування інвалідації (event-based + TTL).
6. Тестування офлайн-сценаріїв: мережа відключена, повільна, дроп.
7. Документація та навчання команди.

Що входить в нашу роботу по впровадженню кешування

• Аудит поточних API та даних
• Проектування архітектури кешу (схема шарів, вибір TTL)
• Реалізація in-memory та disk кешу
• Інтеграція HTTP-кешу та ETag
• Налаштування інвалідації (event-based + TTL)
• Тестування сценаріїв офлайн (мережа відключена, повільна, дроп)
• Документація та навчання команди
• Підтримка при публікації в App Store / Google Play

Наша команда (5+ років на ринку, 3 сертифікованих інженера) розробила понад 50 мобільних додатків з offline-first архітектурою. Ми спеціалізуємося на архітектурі кешу мобільного додатка та розробці офлайн додатків. Ми гарантуємо стабільну роботу кешу в умовах нестабільної мережі. Всі рішення проходять код-рев'ю та навантажувальне тестування. Зв'яжіться з нами для оцінки вашого проєкту — запропонуємо оптимальну схему кешування під ваші дані. Отримайте консультацію, щоб ваш додаток працював миттєво навіть в офлайн.

Як вибрати рішення для локального зберігання даних (Room, Core Data, Realm, Isar)?

Ми стикалися з ситуацією, коли додаток втрачає дані при втраті мережі — і це не просто баг, це провал сценарію. Користувач заповнив форму, натиснув «Відправити», отримав таймаут і втратив все. Або гірше: дані відправилися двічі через некоректну логіку повторної відправки. Правильно вибраний та налаштований шар сховища вирішує цю проблему раз і назавжди. Неправильний вибір може коштувати команді місяців переписування коду та втрати до 70% часу на синхронізацію. Наш досвід — 10+ років у мобільній розробці, понад 50 проектів з офлайн-сховищами — підтверджує: вибір рішення визначає 80% майбутніх проблем з продуктивністю та синхронізацією.

На практиці вибір сховища визначається двома факторами: типом даних та вимогами до синхронізації, а не популярністю бібліотеки.

Room (Android) — обгортка над SQLite з compile-time верифікацією SQL-запитів. Якщо запит невалідний, збірка падає — це краще, ніж SQLiteException в рантаймі. Room добре інтегрується з Kotlin Flow та LiveData, що робить реактивні UI-оновлення прямолінійними. Основна складність — міграції схеми. @Database(version = N, exportSchema = true) з файлами міграцій в assets/databases/ — обов'язкова практика, інакше при оновленні додатка fallbackToDestructiveMigration() просто зітре дані користувача.

Core Data (iOS) — не база даних, а фреймворк управління графом об'єктів поверх SQLite (або XML, або in-memory). NSPersistentContainer з viewContext для читання на main thread та newBackgroundContext() для запису — базова схема. Проблема починається, коли розробник робить save() в viewContext з фонового потоку: EXC_BAD_ACCESS в рандомний момент, відтворюється раз на тиждень, в крешлозі майже нічого корисного. Потрібно використовувати performAndWait або perform для кожного контексту строго в своєму потоці. Apple Core Data Programming Guide рекомендує саме такий підхід.

Realm виграє там, де потрібна швидкість роботи з великими наборами об'єктів та вбудована реактивність через Results + observe(). Realm зберігає об'єкти напряму, без маппінгу ORM, тому читання не потребує десеріалізації. За нашими вимірами, Realm обробляє читання в 2–3 рази швидше Core Data при об'ємі понад 10 000 об'єктів. На Flutter Realm SDK (ex-MongoDB Realm) підтримує Device Sync — але це вже managed-сервіс з окремою інфраструктурою.

Hive та Isar — Flutter-специфічні рішення. Hive — key-value сховище, швидко, просто, підходить для налаштувань та кешів. Isar — повноцінна документо-орієнтована БД з індексами, написана на Rust, компілюється в нативний код. Для Flutter-додатків з офлайн-функціональністю Isar зараз переважніше: вбудований query builder з типобезпечними фільтрами, транзакції, watchObject/watchQuery для реактивності.

Зв'яжіться з нами, щоб отримати безкоштовний аудит вашого поточного сховища та рекомендації з оптимізації — це зекономить вам сотні годин розробки та до 60% трафіку на серверні запити.

Чому офлайн-синхронізація — найскладніша частина?

Локальне сховище саме по собі нескладне. Складність — у синхронізації з сервером при наявності конфліктів.

Найчастіший патерн — optimistic updates з rollback. Користувач редагує запис, UI відображає зміну миттєво, фоновий запит йде на сервер. Якщо сервер повертає помилку — відкочуємо локальний стейт. Виглядає просто. На практиці: якщо користувач встиг піти з екрану і повернутися, а відкат відбувся через 3 секунди — UX зламаний. Потрібна явна черга операцій зі станом (PENDING, SYNCED, FAILED) в окремій таблиці.

На Android для фонової синхронізації використовуємо WorkManager з Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). Важно не забыть про setInputMerger(ArrayCreatingInputMerger::class) при батчинге задач — інакше при кількох одночасних запусках дані затираються. Типова реалізація черги операцій:

class SyncWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        val pendingOps = syncDao.getPendingOperations()
        for (op in pendingOps) {
            try {
                apiClient.send(op.payload)
                syncDao.markSynced(op.id)
            } catch (e: Exception) {
                syncDao.markFailed(op.id, e.message)
                return Result.retry()
            }
        }
        return Result.success()
    }
}

На iOS аналог — BGTaskScheduler з BGProcessingTaskRequest. Обмеження iOS на фоновий час виконання (~30 секунд для refresh tasks) означають, що синхронізація повинна бути інкрементальною: не «синхронізувати все», а «синхронізувати наступні N записів, зберегти курсор».

Конфлікти при мультипристроєвій роботі вирішуються одним із трьох підходів:

• Last-write-wins по updated_at (найпростіший, втрачає дані при одночасному редагуванні)
• Server-wins (клієнт завжди приймає серверну версію)
• Three-way merge (складно, потрібен спільний предок — підходить для документів)

У більшості B2C-додатків достатньо last-write-wins з вектором часу на рівні користувача, але при спільному редагуванні потрібен CRDTs-підхід — тоді дивимося на Automerge або Yjs з мобільними біндингами.

Як ми будуємо шар сховища

Репозиторний патерн — не опціональний, а обов'язковий. UserRepository не знає, звідки дані: з Room, Realm чи мережі. ViewModel викликає repository.getUser(id), отримує Flow/Stream, відображає дані. Логіка кешування — всередині репозиторія.

Для Flutter типова архітектура: Isar для персистентності, Riverpod для управління стейтом, ConnectivityPlus для визначення стану мережі, кастомний SyncService з чергою операцій. Riverpod AsyncNotifier зручно покриває логіку «показати кеш, оновити з мережі, показати нові дані». Приклад репозиторія з кешуванням:

class UserRepository {
  final Isar isar;
  final ApiClient api;

  Future<User> getUser(String id) async {
    // 1. спробувати з локального сховища
    final cached = await isar.user.where().idEqualTo(id).findFirst();
    if (cached != null) return cached;
    // 2. інакше з мережі
    final remote = await api.fetchUser(id);
    // 3. зберегти локально
    await isar.writeTxn(() => isar.user.put(remote));
    return remote;
  }
}

Окрема тема — шифрування. Якщо додаток зберігає медичні дані, платіжні картки або корпоративні документи, SQLCipher (Android) та NSFileProtection (iOS) — не опція. Realm підтримує шифрування нативно через ключ у 64 байти, який потрібно зберігати в Keychain/Keystore, а не в SharedPreferences. Економія на безпеці може обійтися у витік даних з гучними наслідками.

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

Ми гарантуємо прозорий процес і фіксуємо кожен етап:

Бажаєте уникнути типових помилок при проектуванні сховища? Зверніться до нас — ми допоможемо спроектувати надійне локальне сховище з нуля або доопрацювати існуюче.

Які етапи роботи?

Починаємо з аудиту вимог: які дані, який обсяг, чи потрібна синхронізація, чи можливі конфлікти. На цьому етапі стає зрозуміло, Core Data чи SQLite-based рішення, чи потрібен Realm Sync або достатньо простого REST-поллінгу.

Далі — проектування схеми з урахуванням міграцій. Схему змінюють у будь-якому проекті — питання не «чи будуть міграції», а «наскільки болісно вони пройдуть». Експортуємо схему в JSON, зберігаємо в репозиторії, пишемо тести на міграцію кожної версії.

Розробка йде з покриттям репозиторного шару юніт-тестами: моки мережевого шару, реальна in-memory база для тестування запитів. Перед релізом — профілювання запитів через Android Profiler (вкладка Database Inspector) або Core Data debug флаги (-com.apple.CoreData.SQLDebug 1).

Термін реалізації шару сховища з базовою офлайн-синхронізацією — від 2 до 6 тижнів залежно від складності схеми та вимог до конфлікт-резолюції. Вартість розраховується індивідуально після аудиту вашого проекту. Замовте розробку під ключ — отримайте консультацію з вибору оптимального стеку та міграціям.