Директорія кешу застосунку — що це, призначення та як очищати в мобільній розробці

Що таке директорія кешу застосунку?

Директорія кешу — це спеціальна директорія у внутрішній (або зовнішній) пам'яті застосунку, призначена для тимчасових файлів. Основна відмінність від 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. Заголовки відповіді Cache-Control та ETag керують політикою кешування: сервер вказує, скільки часу відповідь вважається актуальною. При правильному налаштуванні кеш мережевих запитів може скоротити час завантаження даних на 60–80% при повторних візитах та забезпечити базову функціональність застосунку без інтернет-з'єднання. Розмір кешу мережевих запитів рідко перевищує 10–20 МБ, але при активному використанні застосунку може досягати 50 МБ. Налаштовуйте максимальний розмір кешу через конструктор OkHttpClient.Builder та перевіряйте актуальність кешованих даних при кожному запуску застосунку.

Кеш баз даних та попередньо скомпільованих даних

Бази даних SQLite можуть генерувати тимчасові файли в процесі роботи: WAL-файли (Write-Ahead Log), журнали відкату та індексні сторінки. Ці файли зберігаються поруч з основною базою даних, але для тимчасових БД (наприклад, повнотекстового пошуку або аналітики) можна вказати розміщення в кеш-директорії. Попередньо скомпільовані шейдерні програми 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% користувачів видалили хоча б один застосунок через неконтрольоване зростання кешу та займаного місця.