Изображения — главная причина тормозов в мобильных приложениях. Мы не раз видели, как скролл ленты с аватарками дёргается не потому что устройство слабое, а потому что декодирование JPEG происходит на main thread в момент, когда ячейка уже должна отображаться. В мобильной разработке это частая проблема, и мы решаем её с помощью правильного многоуровневого кэша. Однако настройка кэширования изображений — нетривиальная задача: даже с популярными библиотеками можно получить промахи кэша, если не учесть специфику платформы и контента.
Как работает многоуровневое кэширование?
Многоуровневый кэш строится на двух уровнях: memory cache (L1) — быстрый, небольшой (20‑30 МБ) и disk cache (L2) — медленнее, большой (200‑500 МБ). Размеры подбираются исходя из характера контента: в новостном приложении с большим количеством уникальных изображений disk cache важнее, в мессенджере с аватарками — memory cache. Placeholder и error‑state — отдельно. Показывать пустое место пока грузится картинка — хуже, чем показывать скелетон. Error state должен быть явным, но не ломать вёрстку.
Предзагрузка (prefetch) для списков: загружать следующие N изображений заранее, пока пользователь ещё не доскролил до них. В RecyclerView — через RecyclerView.RecycledViewPool + DiffUtil. В UITableView — через prefetchDataSource (доступен с iOS 10).
Стандартные решения и их подводные камни
Android: Glide и Coil — наиболее распространённые библиотеки. Glide при дефолтных настройках кэширует в двух уровнях: memory cache (LruCache с размером, производным от доступной памяти) и disk cache (DiskLruCache). Coil написан на Kotlin Coroutines и лучше интегрируется с Compose через AsyncImage. Проблема возникает когда размер изображений в сети не совпадает с размером ImageView: Glide по умолчанию кэширует уже трансформированное изображение (под конкретный размер view), что приводит к промахам кэша при разных размерах одного и того же URL. Также часто встречается некорректная стратегия инвалидации: изображения обновляются только после перезапуска приложения, если не настроен ETag или версию URL.
iOS: NSCache + ручная логика или библиотеки Kingfisher и SDWebImage. Kingfisher — де‑факто стандарт для SwiftUI через .setImage(with:). Проблема, которую видим регулярно: кэш не учитывает Cache‑Control заголовки сервера, и устаревшие изображения показываются пользователю, пока TTL не истёк вручную. Кроме того, дисковой кэш по умолчанию сохраняет изображения в директории, которая может быть очищена при нехватке места, что приводит к повторной загрузке.
React Native: react-native-fast-image поверх Glide/SDWebImage. Стандартный Image в RN не имеет нормального диска‑кэша — картинки грузятся заново при каждом монтировании компонента, что заметно при навигации между экранами. Настройка react-native-fast-image требует указания размеров и приоритетов.
Flutter: Используйте пакет cached_network_image. Он предоставляет CachedNetworkImageProvider с кэшированием на уровне памяти и диска, а также поддержку предзагрузки.
Почему важна инвалидация кэша?
Без стратегии инвалидации пользователи видят устаревшие аватарки после смены фото профиля. На практике используем два подхода: URL с версией (/avatar.jpg?v=42) и использование Cache-Control. Второй позволяет сократить трафик до 40%, так как сервер возвращает 304 Not Modified, если контент не изменился. Также настраиваем Cache‑Control с оптимальным max‑age (например, 86400 секунд для аватарок, 3600 для ленты). Экономия трафика напрямую снижает расходы на передачу данных — для приложений с миллионом пользователей это ощутимо.
Что входит в работу
При заказе настройки кэширования изображений мы предоставляем:
- Анализ текущей архитектуры и выявление узких мест (аудит ~2 часа)
- Выбор и настройку библиотеки с учётом вашей платформы (Android/iOS/React Native/Flutter)
- Реализацию многоуровневого кэша (L1 + L2) с индивидуальными размерами
- Настройку prefetch для списков и инвалидацию через ETag/версию URL
- Документацию по эксплуатации и рекомендации по дальнейшей поддержке
- Тестирование под нагрузкой (1000+ изображений) и исправление ошибок
Сроки — 2–4 рабочих дня. Гарантируем результат: кэш будет работать корректно, без промахов и утечек памяти. Получите консультацию по настройке кэша — мы оценим ваш проект и предложим оптимальное решение.
Процесс работы
- Аналитика: определяем профиль контента (размеры, количество, частота обновления).
- Проектирование: выбираем библиотеку, размеры кэша, стратегию инвалидации.
- Реализация: внедряем кэш, настраиваем placeholder и error‑state, добавляем prefetch.
- Тестирование: проверяем под нагрузкой, отслеживаем память и дисковое потребление.
- Деплой: интеграция в CI/CD, документирование.
Сравнение библиотек
| Платформа | Библиотека | L1 (память) | L2 (диск) | Prefetch | Инвалидация |
|---|---|---|---|---|---|
| Android | Glide | LruCache | DiskLruCache | Да | ETag, версия |
| Android | Coil | LruCache | DiskLruCache | Да | ETag, версия |
| iOS | Kingfisher | NSCache | FileManager | Да | ETag, Cache‑Control |
| iOS | SDWebImage | NSCache | FileManager | Да | ETag |
| React Native | FastImage | (зависит от платформы) | - | - | ETag |
| Flutter | CachedNetworkImage | MemoryCache | DiskCache | Да | ETag, версия |
Рекомендуемые размеры кэша по типу контента
| Тип контента | Memory cache (L1) | Disk cache (L2) |
|---|---|---|
| Аватарки (10‑50 КБ) | 10‑20 МБ | 50‑100 МБ |
| Новостные изображения (200‑500 КБ) | 20‑30 МБ | 200‑500 МБ |
| Галерея (1‑5 МБ) | 30‑50 МБ | 500‑1000 МБ |
Наш опыт — 5+ лет в мобильной разработке, более 50 проектов с кэшированием изображений. Подтверждённые кейсы: снижение трафика на 30-40% и ускорение скролла в 2 раза. Правильно настроенный кэш сокращает расходы на облачное хранилище до 30%.
Если вы столкнулись с тормозами из-за изображений — свяжитесь с нами, оценим ваш проект и предложим решение под ключ.