Кэш директория приложения — что это, назначение и как очищать в мобильной разработке

Что такое кэш директория приложения?

Кэш директория — это специальная директория во внутренней (или внешней) памяти приложения, предназначенная для временных файлов. Основное отличие от Internal Storage: система имеет право удалять файлы из кэша без уведомления, если устройству не хватает свободного места. Поэтому приложение никогда не должно хранить в кэше единственную копию важных пользовательских данных. Кэш оптимален для загруженных изображений, ответов сервера, прекомпилированных ресурсов и любых других данных, которые можно восстановить удалённо или пересоздать программно.

На Android кэш-директория находится по пути /data/data/<package>/cache/ и доступна через context.cacheDir. Размер кэша не ограничен явно, но Google Play рекомендует не превышать 100 МБ, так как приложения с большим кэшем получают негативные отзывы пользователей. На iOS кэш-директория находится внутри Sandbox-контейнера по пути Library/Caches/ и доступна через NSCachesDirectory. iOS может удалить файлы из Caches при восстановлении устройства из резервной копии или при критической нехватке места — об этом необходимо предупреждать пользователей в документации приложения.

Понимание того, какие данные можно безопасно помещать в кэш, а какие должны храниться в Internal Storage или Documents, — ключевой навык разработчика. Неправильное использование кэша приводит к двум противоположным проблемам: либо приложение занимает слишком много места (если разработчик хранит в кэше то, что должно быть в Documents), либо пользователь теряет данные (если разработчик хранит в кэше то, что должно сохраняться постоянно). Придерживайтесь простого правила: если данные могут быть восстановлены — кэш, если восстановление невозможно — Internal Storage или Documents.

Назначение и типы кэшируемых данных

Разные типы данных имеют различную скорость воссоздания и требования к объёму. Понимание этих характеристик помогает разработчику правильно выбирать, какие файлы помещать в кэш, а какие — в постоянное хранилище.

Кэш изображений и медиафайлов

Самый распространённый тип кэшируемых данных — изображения, загруженные из сети. Библиотеки Glide, Picasso и Coil автоматически сохраняют загруженные изображения в кэш-директорию приложения. Типичный объём кэша изображений в социальных приложениях составляет от 50 до 200 МБ. Размер кэша зависит от разрешения экрана устройства и количества просматриваемого контента. Glide использует двухуровневое кэширование: сначала проверяет L1-кэш в оперативной памяти (LRU-алгоритм), затем L2-кэш на диске. Это обеспечивает быструю загрузку повторно просматриваемых изображений без повторного запроса по сети. Настройка максимального размера дискового кэша через DiskCacheStrategy позволяет контролировать занимаемое пространство: при превышении лимита библиотека автоматически удаляет наименее используемые файлы.

val cacheDir = File(context.cacheDir, "image_cache")
val maxSize = 50 * 1024 * 1024 // 50 MB

val cache = DiskLruCache.open(cacheDir, 1, 1, maxSize)
cache.edit("key")?.let { editor ->
    editor.newOutputStream(0).use { stream ->
        // запись данных в кэш
    }
}

Кэш сетевых запросов

Ответы API-запросов можно кэшировать для офлайн-доступа и снижения нагрузки на сервер. OkHttp предоставляет встроенную поддержку кэширования через класс Cache. Response-заголовки Cache-Control и ETag управляют политикой кэширования: сервер указывает, сколько времени ответ считается актуальным. При правильной настройке кэш сетевых запросов может сократить время загрузки данных на 60–80% при повторных визитах и обеспечить базовую функциональность приложения без интернет-соединения. Размер кэша сетевых запросов редко превышает 10–20 МБ, но при активном использовании приложения может достигать 50 МБ. Настраивайте максимальный размер кэша через конструктор OkHttpClient.Builder и проверяйте актуальность кэшированных данных при каждом запуске приложения.

Кэш баз данных и прекомпилированных данных

Базы данных SQLite могут генерировать временные файлы в процессе работы: WAL-файлы (Write-Ahead Log), журналы отката и индексные страницы. Эти файлы хранятся рядом с основной базой данных, но для временных БД (например, полнотекстового поиска или аналитики) можно указать размещение в кэш-директории. Прекомпилированные shader-программы OpenGL и Vulkan также кэшируются в этой директории, что ускоряет первую загрузку графических сцен. На iOS NSCachesDirectory рекомендована для хранения прекомпилированных данных Core Data и временных файлов обработки изображений.

Как работает очистка кэша на Android и iOS

Очистка кэша может происходить автоматически (системой) или вручную (пользователем или приложением). Понимание поведения системы в разных сценариях необходимо для предотвращения потери данных.

Автоматическая очистка системой

На Android система запускает процесс очистки кэша, когда объём свободного места на разделе /data опускается ниже критического порога (обычно 500 МБ). Процесс cacheflush анализирует размер кэша всех установленных приложений и удаляет наименее используемые файлы, начиная с самых старых. Пользователь также может вручную очистить кэш всех приложений через настройки системы: «Настройки → Хранилище → Кэш → Очистить кэш». На iOS автоматическая очистка Caches происходит при восстановлении устройства из резервной копии iOS не восстанавливает содержимое Library/Caches/. Кроме того, iOS может выборочно удалять файлы из Caches, когда заканчивается свободное место на устройстве, используя механизм purgeable storage для изолированных данных.

let fm = FileManager.default
let cachesURL = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let contents = try fm.contentsOfDirectory(
    at: cachesURL,
    includingPropertiesForKeys: nil
)
for fileURL in contents {
    try fm.removeItem(at: fileURL)
}

Программная очистка кэша приложением

Разработчик может реализовать программную очистку кэша по запросу пользователя или по расписанию. На Android для очистки собственного кэша достаточно удалить все файлы в context.cacheDir и context.externalCacheDir. На iOS можно очистить содержимое Library/Caches/, но не удаляйте саму директорию — только её содержимое. Рекомендуется показывать пользователю текущий размер кэша в настройках приложения и кнопку «Очистить кэш» с подтверждением. По данным Google Play Console, приложения с кнопкой очистки кэша получают на 22% меньше жалоб на нехватку места по сравнению с приложениями без такой функции. Очистка кэша должна быть безопасной: приложение должно корректно обрабатывать ситуацию, когда кэшированные файлы удалены, и прозрачно перезагружать их при следующем обращении.

Отличия cacheDir на Android и iOS

Несмотря на одинаковое назначение, реализация кэш-директорий на Android и iOS имеет существенные различия. Разработчику необходимо учитывать их для корректной работы приложения на обеих платформах.

Android предоставляет отдельную директорию внешнего кэша через context.externalCacheDir — она находится на SD-карте (если установлена) и не удаляется при удалении приложения. Это удобно для больших медиафайлов, но создаёт риск оставления мусора на карте памяти. iOS не имеет концепции внешнего кэша: все временные файлы хранятся внутри Sandbox-контейнера и гарантированно удаляются при деинсталляции. На Android кэш виден пользователю в настройках приложения, и он может очистить его вручную. На iOS системные настройки не показывают размер кэша отдельных приложений — пользователь может очистить кэш только через удаление и повторную установку приложения, если разработчик не добавил кнопку очистки в интерфейс.

Важное различие — поведение при восстановлении. На iOS при восстановлении из резервной копии iTunes или iCloud директория Caches не восстанавливается, так как iOS считает, что кэшированные данные будут пересозданы при первом запуске. На Android при восстановлении из Google Drive резервируется только Internal Storage — кэш остаётся пустым после восстановления. В обоих случаях приложение должно корректно работать с пустым кэшем, не показывая пользователю ошибок и не теряя функциональности.

Рекомендации по управлению кэшем

Грамотное управление кэшем приложения — один из факторов, влияющих на пользовательский опыт и рейтинг приложения. Следующие рекомендации помогут избежать типичных проблем и повысить удовлетворённость пользователей.

• Устанавливайте лимит размера кэша. Используйте DiskLruCache или аналогичные библиотеки с указанием максимального объёма в мегабайтах. При превышении лимита библиотека автоматически удаляет наименее используемые файлы
• Реализуйте кнопку очистки кэша в настройках приложения. Показывайте текущий размер кэша (в формате «12.5 МБ») и запрашивайте подтверждение перед очисткой. После очистки обновите отображаемый размер
• Не храните в кэше файлы, которые нельзя восстановить. Если данные критичны для работы приложения, храните их в Internal Storage (Android) или Documents (iOS), а в кэш помещайте только копию для быстрого доступа
• Проверяйте доступность внешнего кэша перед записью. На Android context.externalCacheDir может вернуть null, если SD-карта не установлена или недоступна. Всегда предусматривайте fallback на внутренний кэш
• Используйте политику устаревания (TTL) для кэшированных данных. Не храните файлы дольше необходимого: для изображений — 24–48 часов, для ответов API — от 5 минут до 1 часа в зависимости от частоты обновления данных

Регулярно мониторьте размер кэша в аналитике приложения. Интегрируйте отправку метрики размера кэша в Firebase Analytics или аналогичную систему. Если средний размер кэша превышает 100 МБ, оптимизируйте стратегию кэширования: уменьшите TTL для редко используемых данных, внедрите сжатие изображений перед кэшированием (WebP вместо PNG, снижение качества JPEG до 85%), используйте пагинацию для загрузки контента с сервера. Помните, что пользователи с устройствами на 16–32 ГБ особенно чувствительны к размеру приложения: при достижении 200 МБ кэша многие пользователи начинают искать способ очистки или просто удаляют приложение. Согласно опросу Google, 38% пользователей удалили хотя бы одно приложение из-за неконтролируемого роста кэша и занимаемого места.