Disk Cache: ano ito, disk cache ng iOS at mga prinsipyo ng paggana

Ano ang Disk Cache sa iOS?

Disk Cache — ay isang teknolohiya ng pansamantalang pag-iimbak ng data sa permanenteng storage ng device (flash memory) upang pabilisin ang mga kasunod na request sa parehong data. Hindi tulad ng RAM cache, pinapanatili ng Disk Cache ang data pagkatapos ng pag-restart ng application at maging ng device.

Ang iOS ay nagbibigay ng dalawang pangunahing antas ng pag-cache: operational (NSCache, memorya) at disk (URLCache, file system). Ang disk cache ay 10–100 beses na mas mabagal kaysa sa operational cache, ngunit mas mabilis kaysa sa network request — ang pagkakaiba ay maaaring 2 hanggang 3 order ng magnitude. Ang optimal na diskarte ay gumagamit ng dalawang antas na cache: memorya para sa mainit na data at disk para sa malamig na data.

Ayon sa Apple Performance Optimization Guide, 2023, ang wastong na-configure na Disk Cache ay nagbabawas ng oras ng pag-load ng content ng 60–80% para sa paulit-ulit na pagtingin at nagbabawas ng konsumo ng trapiko ng 40–70%. Para sa mga application na may media content (mga larawan, video, audio), ang pag-cache ay isang kritikal na factor ng UX.

URLCache: built-in na mekanismo ng pag-cache

URLCache — ay isang built-in na Foundation class na nag-iimplementa ng pinagsamang cache para sa mga URLSession request. Awtomatiko nitong sine-save ang mga tugon ng server sa disk at memorya, pinamamahalaan ang laki ng cache at mga patakaran sa invalidation batay sa HTTP headers na Cache-Control, Expires at ETag.

import Foundation

let cache = URLCache(
    memoryCapacity: 50 * 1024 * 1024,
    diskCapacity: 200 * 1024 * 1024,
    diskPath: "network-cache"
)

URLCache.shared = cache

let config = URLSessionConfiguration.default
config.urlCache = cache
config.requestCachePolicy = .returnCacheDataElseLoad

let session = URLSession(configuration: config)

Mga patakaran sa pag-cache ng URLCache ay tumutukoy kung kailan gagamitin ang naka-cache na data at kung kailan gagawa ng bagong request. Mga pangunahing patakaran: useProtocolCachePolicy (batay sa server headers), reloadIgnoringLocalCacheData (palaging mula sa server), returnCacheDataElseLoad (una ang cache), returnCacheDataDontLoad (cache lang — offline mode).

Cache-Control — HTTP header na ipinapadala ng server kasama ng tugon, na nagpapahiwatig ng max-age (oras ng buhay sa segundo), must-revalidate (suriin ang pagiging bago), no-cache (huwag gamitin nang walang beripikasyon) at no-store (huwag i-cache). Ang iOS ay mahigpit na sumusunod sa mga header na ito nang awtomatiko kapag gumagamit ng URLCache na may patakarang useProtocolCachePolicy.

Custom na mga diskarte sa pag-cache at invalidation

Custom na cache ay kailangan kapag ang built-in na URLCache ay hindi sapat: para sa pag-iimbak ng mga naprosesong larawan, serialized na modelo ng data, o resulta ng mga kalkulasyon. Sa ganitong mga kaso, ang developer ay lumilikha ng sariling sistema ng pag-cache batay sa Caches directory sa Sandbox ng application.

class DiskCache<T: Codable> {
    private let cacheDir: URL
    private let encoder = JSONEncoder()
    private let decoder = JSONDecoder()

    init() {
        let paths = FileManager.default
            .urls(for: .cachesDirectory,
                     in: .userDomainMask)
        cacheDir = paths[0].appendingPathComponent(
            "data-cache", isDirectory: true
        )
        try? FileManager.default
            .createDirectory(at: cacheDir,
                             withIntermediateDirectories: true)
    }

    func set(value: T, for key: String) {
        let url = cacheDir.appendingPathComponent(
            SHA256.hash(key)
        )
        if let data = try? encoder.encode(value) {
            try? data.write(to: url)
        }
    }

    func get(for key: String) -> T? {
        let url = cacheDir.appendingPathComponent(
            SHA256.hash(key)
        )
        guard let data = try? Data(contentsOf: url) else { return nil }
        return try? decoder.decode(T.self, from: data)
    }

    func clearAll() {
        try? FileManager.default
            .removeItem(at: cacheDir)
    }
}

Mga diskarte sa invalidation ng cache ay tumutukoy kung kailan itinuturing na luma ang nakaimbak na data: TTL (Time-To-Live) — nabubuhay ang data ng fixed na oras pagkatapos ng pagsulat; event-driven — invalidation kapag may nangyaring pangyayari (hal. pag-update ng data sa server); version-based — invalidation kapag nagbago ang bersyon ng API o format ng data; LRU (Least Recently Used) — awtomatikong pag-alis ng pinakabihirang ginamit na mga entry kapag nalampasan ang limitasyon sa laki.

Praktikal na patakaran: Ang TTL ay angkop para sa balita at content na nahuhulaan ang pagkaluma. Event-driven — para sa data na pinamamahalaan ng server sa pamamagitan ng push notification. Version-based — para sa mga configuration at cache ng modelo ng data. LRU — unibersal na pagpipilian para sa media file na may limitadong espasyo sa disk.

Pagganap at mga limitasyon ng cache

Pagganap ng Disk Cache ay sinusukat sa pamamagitan ng hit ratio — porsyento ng mga request na natugunan mula sa cache nang hindi gumagamit ng network. Ang tipikal na hit ratio para sa well-configure na cache ng larawan ay 70–90%, para sa mga tugon ng API — 40–60%, para sa streaming video — 30–50%.

Mga limitasyon ng Disk Cache sa iOS: maaaring tanggalin ng system ang nilalaman ng Caches directory anumang oras kapag kulang ang espasyo sa disk. Ang pag-uugali na ito ay hindi ma-configure — ang iOS mismo ang nagdedesisyon kung kailan at aling mga cache file ang tatanggalin. Samakatuwid, hindi dapat maglaman ang cache ng data na hindi mababawi mula sa network o iba pang mga mapagkukunan.

Epekto sa flash memory: ang madalas na pagsulat sa Disk Cache ay nagpapabilis ng pagkasira ng flash memory. Ang iOS ay gumagamit ng TRIM at wear leveling upang mabawasan ang pagkasira, ngunit inirerekomenda sa mga developer na iwasan ang labis na pagsulat: huwag i-update ang cache nang mas madalas kaysa isang beses bawat 5 minuto para sa parehong file; pagsamahin ang maliliit na pagsulat sa isa; gumamit ng NSCache para sa pansamantalang data na hindi kailangang iimbak sa disk.

Pinakamahusay na kasanayan sa pag-cache sa iOS

Dalawang antas na cache — karaniwang arkitektura para sa iOS application: memorya (NSCache) para sa data na madalas na ina-access at disk (URLCache o custom) para sa data na dapat panatilihin sa pagitan ng mga session. Oras ng buhay sa memorya — minuto, sa disk — oras o araw.

Pag-cache ng mga larawan: gumamit ng mga espesyalisadong library (Kingfisher, SDWebImage, Nuke) na nag-iimplementa ng dalawang antas na cache na may awtomatikong invalidation, pamamahala ng memorya, at asynchronous na pagsulat sa disk. Ang sariling implementasyon ng cache ng larawan ay nangangailangan ng pagsasaalang-alang ng decoding, color space, at scaling.

Cache at seguridad: huwag i-cache ang kumpidensyal na data (mga password, token, personal na data) sa disk nang walang encryption. Ang URLCache ay hindi nag-e-encrypt ng data bilang default — gumamit ng NSFileProtection o encryption sa antas ng application para sa sensitibong nilalaman. Para sa mga network request na may awtorisasyon, gamitin ang patakarang .reloadIgnoringLocalCacheData.

Pag-monitor ng cache: subaybayan ang hit ratio, kasalukuyang laki ng cache, at bilang ng mga pagsulat bawat minuto. Kung ang hit ratio ay bumaba sa ibaba 30% — ang cache ay hindi epektibo at nangangailangan ng pagbabago ng diskarte o pagtaas ng laki. Ayon sa Point-Free (2024), ang pag-monitor ng cache ay isa sa mga pinaka-underestimated na kasanayan sa pag-optimize ng pagganap ng iOS application.