Katalog pamięci podręcznej aplikacji — co to jest, przeznaczenie i jak czyścić w tworzeniu aplikacji mobilnych

Co to jest katalog pamięci podręcznej aplikacji?

Katalog pamięci podręcznej to specjalny katalog w pamięci wewnętrznej (lub zewnętrznej) aplikacji, przeznaczony do plików tymczasowych. Główna różnica w stosunku do Internal Storage: system ma prawo usuwać pliki z pamięci podręcznej bez powiadomienia, jeśli urządzeniu brakuje wolnego miejsca. Dlatego aplikacja nigdy nie powinna przechowywać w pamięci podręcznej jedynej kopii ważnych danych użytkownika. Pamięć podręczna jest optymalna dla pobranych obrazów, odpowiedzi serwera, prekompilowanych zasobów i wszelkich innych danych, które można przywrócić zdalnie lub odtworzyć programowo.

Na Android katalog pamięci podręcznej znajduje się pod ścieżką /data/data/<pakiet>/cache/ i jest dostępny przez context.cacheDir. Rozmiar pamięci podręcznej nie jest wyraźnie ograniczony, ale Google Play zaleca nieprzekraczanie 100 MB, ponieważ aplikacje z dużą pamięcią podręczną otrzymują negatywne opinie użytkowników. Na iOS katalog pamięci podręcznej znajduje się wewnątrz kontenera Sandbox pod ścieżką Library/Caches/ i jest dostępny przez NSCachesDirectory. iOS może usunąć pliki z Caches podczas przywracania urządzenia z kopii zapasowej lub przy krytycznym braku miejsca — należy ostrzegać o tym użytkowników w dokumentacji aplikacji.

Zrozumienie, które dane można bezpiecznie umieszczać w pamięci podręcznej, a które powinny być przechowywane w Internal Storage lub Documents, to kluczowa umiejętność programisty. Nieprawidłowe użycie pamięci podręcznej prowadzi do dwóch przeciwstawnych problemów: albo aplikacja zajmuje zbyt dużo miejsca (jeśli programista przechowuje w pamięci podręcznej to, co powinno być w Documents), albo użytkownik traci dane (jeśli programista przechowuje w pamięci podręcznej to, co powinno być przechowywane na stałe). Kieruj się prostą zasadą: jeśli dane mogą być przywrócone — pamięć podręczna, jeśli przywrócenie jest niemożliwe — Internal Storage lub Documents.

Przeznaczenie i typy przechowywanych danych w pamięci podręcznej

Różne typy danych mają różną prędkość odtwarzania i wymagania dotyczące objętości. Zrozumienie tych cech pomaga programiście prawidłowo wybierać, które pliki umieszczać w pamięci podręcznej, a które w stałym magazynie.

Pamięć podręczna obrazów i plików multimedialnych

Najczęstszy typ danych przechowywanych w pamięci podręcznej to obrazy pobrane z sieci. Biblioteki Glide, Picasso i Coil automatycznie zapisują pobrane obrazy w katalogu pamięci podręcznej aplikacji. Typowy rozmiar pamięci podręcznej obrazów w aplikacjach społecznościowych wynosi od 50 do 200 MB. Rozmiar pamięci podręcznej zależy od rozdzielczości ekranu urządzenia i ilości przeglądanych treści. Glide używa dwupoziomowego buforowania: najpierw sprawdza pamięć podręczną L1 w pamięci RAM (algorytm LRU), następnie pamięć podręczną L2 na dysku. Zapewnia to szybkie ładowanie ponownie przeglądanych obrazów bez ponownego żądania sieciowego. Ustawienie maksymalnego rozmiaru pamięci podręcznej dysku przez DiskCacheStrategy pozwala kontrolować zajmowaną przestrzeń: po przekroczeniu limitu biblioteka automatycznie usuwa najmniej używane pliki.

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 ->
        // zapis danych do pamięci podręcznej
    }
}

Pamięć podręczna zapytań sieciowych

Odpowiedzi zapytań API można buforować do dostępu offline i zmniejszenia obciążenia serwera. OkHttp zapewnia wbudowaną obsługę buforowania przez klasę Cache. Nagłówki odpowiedzi Cache-Control i ETag zarządzają polityką buforowania: serwer określa, jak długo odpowiedź jest uważana za aktualną. Przy prawidłowej konfiguracji pamięć podręczna zapytań sieciowych może skrócić czas ładowania danych o 60–80% przy ponownych wizytach i zapewnić podstawową funkcjonalność aplikacji bez połączenia z internetem. Rozmiar pamięci podręcznej zapytań sieciowych rzadko przekracza 10–20 MB, ale przy aktywnym używaniu aplikacji może osiągnąć 50 MB. Ustaw maksymalny rozmiar pamięci podręcznej przez konstruktor OkHttpClient.Builder i sprawdzaj aktualność buforowanych danych przy każdym uruchomieniu aplikacji.

Pamięć podręczna baz danych i danych prekompilowanych

Bazy danych SQLite mogą generować pliki tymczasowe podczas pracy: pliki WAL (Write-Ahead Log), dzienniki wycofania i strony indeksów. Te pliki są przechowywane obok głównej bazy danych, ale dla tymczasowych baz danych (np. wyszukiwania pełnotekstowego lub analityki) można określić umieszczenie w katalogu pamięci podręcznej. Prekompilowane programy shaderów OpenGL i Vulkan są również buforowane w tym katalogu, co przyspiesza pierwsze ładowanie scen graficznych. Na iOS NSCachesDirectory jest zalecany do przechowywania prekompilowanych danych Core Data i tymczasowych plików przetwarzania obrazów.

Jak działa czyszczenie pamięci podręcznej na Android i iOS

Czyszczenie pamięci podręcznej może odbywać się automatycznie (przez system) lub ręcznie (przez użytkownika lub aplikację). Zrozumienie zachowania systemu w różnych scenariuszach jest niezbędne do zapobiegania utracie danych.

Automatyczne czyszczenie przez system

Na Android system uruchamia proces czyszczenia pamięci podręcznej, gdy ilość wolnego miejsca na partycji /data spada poniżej krytycznego progu (zwykle 500 MB). Proces cacheflush analizuje rozmiar pamięci podręcznej wszystkich zainstalowanych aplikacji i usuwa najmniej używane pliki, zaczynając od najstarszych. Użytkownik może również ręcznie wyczyścić pamięć podręczną wszystkich aplikacji przez ustawienia systemu: „Ustawienia → Pamięć → Pamięć podręczna → Wyczyść pamięć podręczną”. Na iOS automatyczne czyszczenie Caches następuje podczas przywracania urządzenia z kopii zapasowej — iOS nie przywraca zawartości Library/Caches/. Ponadto iOS może selektywnie usuwać pliki z Caches, gdy kończy się wolne miejsce na urządzeniu, używając mechanizmu purgeable storage dla izolowanych danych.

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)
}

Programowe czyszczenie pamięci podręcznej przez aplikację

Programista może zaimplementować programowe czyszczenie pamięci podręcznej na żądanie użytkownika lub zgodnie z harmonogramem. Na Android do wyczyszczenia własnej pamięci podręcznej wystarczy usunąć wszystkie pliki w context.cacheDir i context.externalCacheDir. Na iOS można wyczyścić zawartość Library/Caches/, ale nie usuwaj samego katalogu — tylko jego zawartość. Zaleca się pokazywanie użytkownikowi bieżącego rozmiaru pamięci podręcznej w ustawieniach aplikacji i przycisku „Wyczyść pamięć podręczną” z potwierdzeniem. Według Google Play Console, aplikacje z przyciskiem czyszczenia pamięci podręcznej otrzymują o 22% mniej skarg na brak miejsca w porównaniu z aplikacjami bez takiej funkcji. Czyszczenie pamięci podręcznej powinno być bezpieczne: aplikacja musi poprawnie obsługiwać sytuację, gdy buforowane pliki zostały usunięte, i przezroczyście ponownie je ładować przy następnym odwołaniu.

Różnice między cacheDir na Android i iOS

Pomimo tego samego przeznaczenia, implementacja katalogów pamięci podręcznej na Android i iOS ma istotne różnice. Programista musi je uwzględnić do poprawnego działania aplikacji na obu platformach.

Android udostępnia osobny katalog zewnętrznej pamięci podręcznej przez context.externalCacheDir — znajduje się on na karcie SD (jeśli jest zainstalowana) i nie jest usuwany przy odinstalowaniu aplikacji. Jest to wygodne dla dużych plików multimedialnych, ale stwarza ryzyko pozostawienia niepotrzebnych plików na karcie pamięci. iOS nie ma koncepcji zewnętrznej pamięci podręcznej: wszystkie pliki tymczasowe są przechowywane wewnątrz kontenera Sandbox i gwarantowanie usuwane przy dezinstalacji. Na Android pamięć podręczna jest widoczna dla użytkownika w ustawieniach aplikacji i może on wyczyścić ją ręcznie. Na iOS ustawienia systemowe nie pokazują rozmiaru pamięci podręcznej poszczególnych aplikacji — użytkownik może wyczyścić pamięć podręczną tylko przez usunięcie i ponowną instalację aplikacji, jeśli programista nie dodał przycisku czyszczenia w interfejsie.

Ważna różnica — zachowanie przy przywracaniu. Na iOS podczas przywracania z kopii zapasowej iTunes lub iCloud katalog Caches nie jest przywracany, ponieważ iOS uważa, że buforowane dane zostaną odtworzone przy pierwszym uruchomieniu. Na Android podczas przywracania z Google Drive archiwizowany jest tylko Internal Storage — pamięć podręczna pozostaje pusta po przywróceniu. W obu przypadkach aplikacja musi poprawnie działać z pustą pamięcią podręczną, nie pokazując użytkownikowi błędów i nie tracąc funkcjonalności.

Zalecenia dotyczące zarządzania pamięcią podręczną

Umiejętne zarządzanie pamięcią podręczną aplikacji to jeden z czynników wpływających na doświadczenie użytkownika i ocenę aplikacji. Poniższe zalecenia pomogą uniknąć typowych problemów i zwiększyć satysfakcję użytkowników.

• Ustaw limit rozmiaru pamięci podręcznej. Użyj DiskLruCache lub podobnych bibliotek z określeniem maksymalnej objętości w megabajtach. Po przekroczeniu limitu biblioteka automatycznie usuwa najmniej używane pliki
• Zaimplementuj przycisk czyszczenia pamięci podręcznej w ustawieniach aplikacji. Pokaż bieżący rozmiar pamięci podręcznej (w formacie „12.5 MB”) i poproś o potwierdzenie przed czyszczeniem. Po czyszczeniu zaktualizuj wyświetlany rozmiar
• Nie przechowuj w pamięci podręcznej plików, których nie można przywrócić. Jeśli dane są krytyczne dla działania aplikacji, przechowuj je w Internal Storage (Android) lub Documents (iOS), a w pamięci podręcznej umieszczaj tylko kopię do szybkiego dostępu
• Sprawdzaj dostępność zewnętrznej pamięci podręcznej przed zapisem. Na Android context.externalCacheDir może zwrócić null, jeśli karta SD nie jest zainstalowana lub niedostępna. Zawsze przewiduj fallback na wewnętrzną pamięć podręczną
• Używaj polityki starzenia się (TTL) dla buforowanych danych. Nie przechowuj plików dłużej niż to konieczne: dla obrazów — 24–48 godzin, dla odpowiedzi API — od 5 minut do 1 godziny w zależności od częstotliwości aktualizacji danych

Regularnie monitoruj rozmiar pamięci podręcznej w analityce aplikacji. Zintegruj wysyłanie metryki rozmiaru pamięci podręcznej w Firebase Analytics lub podobnym systemie. Jeśli średni rozmiar pamięci podręcznej przekracza 100 MB, zoptymalizuj strategię buforowania: zmniejsz TTL dla rzadko używanych danych, wprowadź kompresję obrazów przed buforowaniem (WebP zamiast PNG, obniżenie jakości JPEG do 85%), używaj paginacji do ładowania treści z serwera. Pamiętaj, że użytkownicy z urządzeniami o pojemności 16–32 GB są szczególnie wrażliwy na rozmiar aplikacji: po osiągnięciu 200 MB pamięci podręcznej wielu użytkowników zaczyna szukać sposobu na czyszczenie lub po prostu usuwa aplikację. Według ankiety Google, 38% użytkowników usunęło co najmniej jedną aplikację z powodu niekontrolowanego wzrostu pamięci podręcznej i zajmowanego miejsca.