Многоуровневое кэширование в мобильных приложениях

Представьте: пользователь открывает мобильное приложение в метро, где сигнал пропадает каждые 30 секунд. Без кэширования каждый экран превращается в бесконечный spinner, а при ошибке — пустота. Офлайн-первый подход решает это: данные загружаются один раз при соединении и остаются доступными локально. Но кэш — не волшебная палочка: неверная стратегия инвалидации приводит к показу устаревших данных, а переполнение диска — к падению приложения. Мы проектируем многоуровневые кэши уже много лет, запустили более 50 проектов с offline-first архитектурой и знаем, какие грабли встречаются на пути. Наша цель — чтобы пользователь видел данные мгновенно, а разработчик не гадал, почему кэш не обновляется.

Как спроектировать многоуровневый кэш?

Хорошая архитектура кэша — это несколько уровней:

Мы применяем стратегию stale-while-revalidate (cache-first, refresh-in-background): сначала моментально показываем кэш, параллельно обновляем данные в фоне. Если данные изменились, UI перерисовывается. Это даёт пользователю ощущение мгновенной работы.

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

На одном из проектов (приложение для розничной сети) мы реализовали трёхуровневый кэш: заголовки списков хранили в LruCache (Android), детали — в Room с TTL 15 минут, изображения — в Coil с дисковым кэшем 100 МБ. Результат: среднее время загрузки экрана снизилось с 3 секунд до 200 мс, а серверная нагрузка упала на 65%. Обратитесь за консультацией, чтобы подобрать оптимальные 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.
• iOS: Kingfisher или SDWebImage — async загрузка, NSCache + disk, прогрессивный JPEG.
• 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

Наша команда разработала более 50 мобильных приложений с offline-first архитектурой. Мы гарантируем стабильную работу кэша в условиях нестабильной сети. Все решения проходят код-ревью и нагрузочное тестирование. Свяжитесь с нами для оценки вашего проекта — предложим оптимальную схему кэширования под ваши данные. Получите консультацию, чтобы ваше приложение работало мгновенно даже в офлайн.