Caches Directory: co to jest, zarządzanie pamięcią podręczną i czyszczenie danych

Co to jest Caches Directory w iOS?

Caches Directory — to katalog wewnątrz piaskownicy aplikacji iOS, zoptymalizowany pod kątem przechowywania danych, które można w razie potrzeby przywrócić. W przeciwieństwie do Documents Directory, Caches nie jest przeznaczony dla danych użytkownika — to tymczasowe przechowywanie w celu przyspieszenia działania aplikacji.

iOS używa Caches Directory do umieszczania zbuforowanych odpowiedzi sieciowych, wstępnie załadowanych obrazów, serializowanych obiektów i danych, które aplikacja może przywrócić. Deweloper nie powinien polegać na długoterminowym przechowywaniu danych w tym katalogu.

Według danych Apple WWDC 2020, około 40% aplikacji iOS używa Caches Directory do przechowywania buforowanych obrazów i danych sieciowych, przy czym 25% deweloperów nieprawidłowo umieszcza w Caches dane, które powinny znajdować się w Documents lub Application Support, z powodu niezrozumienia różnic między tymi katalogami.

Krytyczna właściwość Caches: aplikacja musi poprawnie obsługiwać sytuację, gdy plik z pamięci podręcznej został usunięty przez system. Jeśli po usunięciu pamięci podręcznej funkcjonalność aplikacji jest zaburzona — oznacza to, że dane są przechowywane w niewłaściwym katalogu.

Jak uzyskać ścieżkę do Caches Directory

W Swift ścieżka do Caches Directory jest uzyskiwana standardową metodą FileManager z wskazaniem .cachesDirectory. To prosta czynność, używana praktycznie w każdej aplikacji iOS pracującej z danymi sieciowymi.

import Foundation

let fileManager = FileManager.default
guard let cachesURL = fileManager.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first else { return }

// Zapisz buforowany JSON
let cacheFile = cachesURL.appendingPathComponent("feed_cache.json")
let jsonData = try JSONSerialization.data(
    withJSONObject: response,
    options: [.prettyPrinted]
)
try jsonData.write(to: cacheFile)

Objective-C używa NSSearchPathForDirectoriesInDomains z NSCachesDirectory. Pomimo że Apple zaleca Swift API, kod Objective-C z Caches Directory pozostaje działający i wspierany.

@import Foundation;

NSArray *paths = NSSearchPathForDirectoriesInDomains(
    NSCachesDirectory,
    NSUserDomainMask,
    YES
);
NSString *cachesPath = paths.firstObject;
NSString *cacheFile = [cachesPath stringByAppendingPathComponent:@"feed_cache.plist"];

Projekty Swift powinny preferować URL-based API: jest bezpieczne typowo i lepiej integruje się z nowoczesnymi frameworkami takimi jak SwiftUI i Combine.

Jakie dane przechowywać w Caches

Caches Directory jest optymalny dla kilku kategorii danych, które aplikacja wykorzystuje do przyspieszenia działania, ale nie jest jedynym źródłem prawdy. Prawidłowy wybór danych do buforowania bezpośrednio wpływa na UX i wydajność aplikacji.

Zbuforowane odpowiedzi sieciowe

Odpowiedzi JSON z API, dane kanałów informacyjnych, listy obiektów — wszystko, co aplikacja może ponownie pobrać z serwera. Użyj URLCache do automatycznego buforowania odpowiedzi HTTP lub zapisuj ręcznie serializowane obiekty.

Obrazy i pliki multimedialne

Obrazy pobrane z sieci — najczęstszy przypadek użycia Caches Directory. Biblioteki takie jak SDWebImage i Kingfisher domyślnie zapisują buforowane obrazy właśnie w Caches.

Jeśli dane nie mogą być przywrócone — ich miejsce nie jest w Caches. To najprostsze kryterium: wyobraź sobie, że jutro system usunie wszystkie pliki z Caches. Jeśli aplikacja będzie nadal działać poprawnie — dane są przechowywane prawidłowo.

Jak system zarządza czyszczeniem pamięci podręcznej

iOS automatycznie zarządza czyszczeniem Caches Directory, ale dokładne wyzwalacze i algorytmy nie są udokumentowane przez Apple. Wiadomo, że system może usuwać pliki z Caches przy braku miejsca na dysku, a także podczas działania funkcji Offload Unused Apps.

Proces czyszczenia jest przezroczysty dla aplikacji: system usuwa pliki bez powiadomienia. Aplikacja musi sprawdzać obecność pliku przed odczytem i tworzyć go ponownie w przypadku braku. Niejednokrotne poleganie na długoterminowym przechowywaniu to kluczowy wymóg podczas pracy z Caches.

Według artykułu Apple "File System Basics" (2024), aplikacja nie powinna liczyć na to, że pliki w Caches Directory będą dostępne między sesjami. Deweloperom zaleca się zaimplementowanie mechanizmu fallback: w przypadku braku buforowanego pliku — pobierz dane z sieci i zapisz w Caches ponownie.

Osobny scenariusz — wyładowanie aplikacji (Offload). Przy aktywacji tej funkcji iOS usuwa aplikację, ale zachowuje jej Documents Directory. Caches Directory przy tym jest usuwany. Użytkownik, który przywrócił aplikację, nie otrzyma buforowanych danych — aplikacja musi je pobrać ponownie.

Caches Directory vs Temporary Directory

Różnica między Caches a Temporary (tmp) często powoduje zamieszanie wśród deweloperów. Oba katalogi przechowują tymczasowe dane, ale z różnymi gwarancjami czasu życia i przeznaczeniem.

Wybierz Caches, jeśli dane są przydatne do zachowania między uruchomieniami aplikacji, ale można je przywrócić. Użyj tmp, jeśli dane są potrzebne tylko w bieżącej sesji i nie mają wartości po zakończeniu aplikacji.

Najlepsze praktyki pracy z Caches

Praca z Caches Directory wymaga przestrzegania kilku zasad, które pomagają uniknąć utraty danych, nieoczekiwanego zachowania aplikacji i problemów z wydajnością.

Zawsze sprawdzaj obecność pliku przed odczytem

FileManager.fileExists(atPath:) powinien być wywoływany przed każdym odczytem z Caches. Jeśli plik nie istnieje — pobierz dane z oryginalnego źródła i zapisz w pamięci podręcznej. Nigdy nie zakładaj, że plik z Caches istnieje.

Ograniczaj rozmiar pamięci podręcznej

Ustaw maksymalny rozmiar Caches Directory w aplikacji. Na przykład limit 50 MB dla obrazów i 10 MB dla odpowiedzi JSON. Po przekroczeniu limitu usuwaj najstarsze pliki według daty modyfikacji.

import Foundation

func trimCache(to maxSizeBytes: Int) {
    let cachesURL = FileManager.default
        .urls(for: .cachesDirectory, in: .userDomainMask)
        .first!

    guard let enumerator = FileManager.default
        .enumerator(
            at: cachesURL,
            includingPropertiesForKeys: [.fileSizeKey, .contentModificationDateKey]
        )
    else { return }

    // Wylicz i usuń stare pliki
    // po przekroczeniu limitu rozmiaru
}

Przestrzeganie tych praktyk gwarantuje, że aplikacja działa poprawnie przy wszystkich działaniach systemu związanych z czyszczeniem pamięci podręcznej, a użytkownik nie spotyka się z nieoczekiwaną utratą danych.