Direktoryo ng cache ng app — ano ito, layunin at paano linisin sa mobile development

Ano ang direktoryo ng cache ng app?

Ang direktoryo ng cache ay isang espesyal na direktoryo sa internal (o external) na memorya ng app, na nilalayon para sa mga pansamantalang file. Ang pangunahing pagkakaiba sa Internal Storage: ang system ay may karapatang tanggalin ang mga file mula sa cache nang walang abiso kung ang device ay walang sapat na libreng espasyo. Samakatuwid, hindi dapat itago ng app ang tanging kopya ng mahahalagang data ng user sa cache. Ang cache ay pinakamainam para sa mga na-download na larawan, mga tugon ng server, mga pre-compile na resource, at anumang iba pang data na maaaring ibalik mula sa malayo o muling likhain nang programmatically.

Sa Android, ang direktoryo ng cache ay matatagpuan sa path na /data/data/<pakete>/cache/ at naa-access sa pamamagitan ng context.cacheDir. Ang laki ng cache ay hindi tahasang limitado, ngunit inirerekomenda ng Google Play na huwag lumampas sa 100 MB, dahil ang mga app na may malaking cache ay nakakatanggap ng negatibong review mula sa mga user. Sa iOS, ang direktoryo ng cache ay matatagpuan sa loob ng Sandbox container sa path na Library/Caches/ at naa-access sa pamamagitan ng NSCachesDirectory. Maaaring tanggalin ng iOS ang mga file mula sa Caches kapag nire-restore ang device mula sa isang backup o kapag kritikal ang kakulangan ng espasyo \u2014 dapat bigyan ng babala ang mga user tungkol dito sa dokumentasyon ng app.

Ang pag-unawa kung aling data ang maaaring ligtas na ilagay sa cache at alin ang dapat itago sa Internal Storage o Documents ay isang pangunahing kasanayan ng developer. Ang hindi tamang paggamit ng cache ay humahantong sa dalawang magkasalungat na problema: alinman sa app ay kumukuha ng masyadong maraming espasyo (kung ang developer ay nag-iimbak sa cache ng dapat na nasa Documents), o ang user ay nawawalan ng data (kung ang developer ay nag-iimbak sa cache ng dapat na permanenteng naka-save). Sundin ang isang simpleng panuntunan: kung ang data ay maaaring maibalik \u2014 cache, kung ang pagpapanumbalik ay imposible \u2014 Internal Storage o Documents.

Layunin at mga uri ng naka-cache na data

Ang iba't ibang uri ng data ay may iba't ibang bilis ng muling paglikha at mga kinakailangan sa volume. Ang pag-unawa sa mga katangiang ito ay tumutulong sa developer na pumili nang tama kung aling mga file ang ilalagay sa cache at alin sa permanenteng imbakan.

Cache para sa mga larawan at media file

Ang pinakakaraniwang uri ng naka-cache na data ay mga larawan na na-download mula sa network. Ang mga library tulad ng Glide, Picasso, at Coil ay awtomatikong nag-iimbak ng mga na-download na larawan sa direktoryo ng cache ng app. Ang tipikal na laki ng cache ng larawan sa mga social app ay mula 50 hanggang 200 MB. Ang laki ng cache ay depende sa resolution ng screen ng device at dami ng napanood na nilalaman. Gumagamit ang Glide ng two-level na caching: una nitong sinusuri ang L1 cache sa RAM (LRU algorithm), pagkatapos ang L2 cache sa disk. Tinitiyak nito ang mabilis na pag-load ng mga muling napanood na larawan nang walang paulit-ulit na kahilingan sa network. Ang pagtatakda ng maximum na laki ng disk cache sa pamamagitan ng DiskCacheStrategy ay nagpapahintulot sa pagkontrol ng espasyo na ginagamit: pagkatapos lumampas sa limitasyon, awtomatikong tinatanggal ng library ang mga file na pinakabihirang ginagamit.

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 ->
        // pagsusulat ng data sa cache
    }
}

Cache para sa mga kahilingan sa network

Ang mga tugon ng mga kahilingan sa API ay maaaring i-cache para sa offline na access at pagbawas ng load ng server. Ang OkHttp ay nagbibigay ng built-in na suporta para sa caching sa pamamagitan ng Cache class. Ang mga header ng tugon na Cache-Control at ETag ay namamahala sa patakaran ng caching: tinutukoy ng server kung gaano katagal itinuturing na kasalukuyan ang tugon. Sa tamang configuration, ang cache ng mga kahilingan sa network ay maaaring bawasan ang oras ng pag-load ng data ng 60\u201380% sa mga paulit-ulit na pagbisita at magbigay ng pangunahing functionality ng app nang walang koneksyon sa internet. Ang laki ng cache ng mga kahilingan sa network ay bihirang lumampas sa 10\u201320 MB, ngunit sa aktibong paggamit ng app ay maaaring umabot sa 50 MB. Itakda ang maximum na laki ng cache sa pamamagitan ng OkHttpClient.Builder constructor at suriin ang pagiging bago ng naka-cache na data sa bawat pag-start ng app.

Cache para sa database at pre-compile na data

Ang mga SQLite database ay maaaring makabuo ng mga pansamantalang file habang gumagana: mga WAL file (Write-Ahead Log), mga rollback journal, at mga pahina ng index. Ang mga file na ito ay iniimbak sa tabi ng pangunahing database, ngunit para sa mga pansamantalang database (halimbawa, full-text na paghahanap o analytics) ay maaaring tukuyin ang paglalagay sa direktoryo ng cache. Ang mga pre-compile na shader program ng OpenGL at Vulkan ay naka-cache din sa direktoryong ito, na nagpapabilis sa unang pag-load ng mga graphic na scene. Sa iOS, ang NSCachesDirectory ay inirerekomenda para sa pag-iimbak ng pre-compile na Core Data at mga pansamantalang file sa pagproseso ng imahe.

Paano gumagana ang pag-clear ng cache sa Android at iOS

Ang pag-clear ng cache ay maaaring mangyari nang awtomatiko (ng system) o manu-mano (ng user o app). Ang pag-unawa sa pag-uugali ng system sa iba't ibang sitwasyon ay kinakailangan upang maiwasan ang pagkawala ng data.

Awtomatikong pag-clear ng system

Sa Android, sinisimulan ng system ang proseso ng pag-clear ng cache kapag ang dami ng libreng espasyo sa /data partition ay bumaba sa ibaba ng kritikal na threshold (karaniwang 500 MB). Ang prosesong cacheflush ay nagsusuri ng laki ng cache ng lahat ng naka-install na app at tinatanggal ang mga file na pinakabihirang ginagamit, simula sa pinakaluma. Maaari ring manu-manong i-clear ng user ang cache ng lahat ng app sa pamamagitan ng mga setting ng system: \u201eMga Setting \u2192 Imbakan \u2192 Cache \u2192 I-clear ang cache\u201d. Sa iOS, ang awtomatikong pag-clear ng Caches ay nangyayari kapag nire-restore ang device mula sa isang backup \u2014 hindi nire-restore ng iOS ang nilalaman ng Library/Caches/. Bukod pa rito, maaaring piliing tanggalin ng iOS ang mga file mula sa Caches kapag nauubos ang libreng espasyo sa device, gamit ang purgeable storage mechanism para sa mga isolated na data.

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

Programmatic na pag-clear ng cache ng app

Ang developer ay maaaring magpatupad ng programmatic na pag-clear ng cache sa kahilingan ng user o ayon sa iskedyul. Sa Android, upang i-clear ang sariling cache, sapat na tanggalin ang lahat ng file sa context.cacheDir at context.externalCacheDir. Sa iOS, maaaring i-clear ang nilalaman ng Library/Caches/, ngunit huwag tanggalin ang direktoryo mismo \u2014 tanging ang nilalaman nito. Inirerekomenda na ipakita sa user ang kasalukuyang laki ng cache sa mga setting ng app at isang button na \u201eI-clear ang cache\u201d na may kumpirmasyon. Ayon sa Google Play Console, ang mga app na may button sa pag-clear ng cache ay tumatanggap ng 22% mas kaunting reklamo tungkol sa kakulangan ng espasyo kumpara sa mga app na walang ganoong feature. Ang pag-clear ng cache ay dapat na ligtas: dapat na maayos na pangasiwaan ng app ang sitwasyon kung kailan tinanggal ang mga naka-cache na file at transparent na muling i-load ang mga ito sa susunod na pag-access.

Mga pagkakaiba ng cacheDir sa Android at iOS

Sa kabila ng parehong layunin, ang implementasyon ng mga direktoryo ng cache sa Android at iOS ay may makabuluhang pagkakaiba. Dapat isaalang-alang ng developer ang mga ito para sa tamang pagpapatakbo ng app sa parehong platform.

Ang Android ay nagbibigay ng hiwalay na external na cache directory sa pamamagitan ng context.externalCacheDir \u2014 ito ay matatagpuan sa SD card (kung naka-install) at hindi natatanggal kapag inalis ang app. Ito ay maginhawa para sa malalaking media file, ngunit lumilikha ng panganib na mag-iwan ng basura sa memory card. Ang iOS ay walang konsepto ng external na cache: lahat ng pansamantalang file ay iniimbak sa loob ng Sandbox container at garantisadong tatanggalin kapag nag-uninstall. Sa Android, ang cache ay nakikita ng user sa mga setting ng app at maaari niya itong i-clear nang manu-mano. Sa iOS, ang mga setting ng system ay hindi nagpapakita ng laki ng cache ng mga indibidwal na app \u2014 maaari lamang i-clear ng user ang cache sa pamamagitan ng pagtanggal at muling pag-install ng app, maliban kung ang developer ay nagdagdag ng button sa pag-clear sa interface.

Isang mahalagang pagkakaiba \u2014 pag-uugali sa pag-restore. Sa iOS, kapag nag-restore mula sa iTunes o iCloud backup, ang Caches directory ay hindi nire-restore, dahil itinuturing ng iOS na ang naka-cache na data ay muling lilikhain sa unang pag-start. Sa Android, kapag nag-restore mula sa Google Drive, tanging ang Internal Storage ang na-archive \u2014 ang cache ay nananatiling walang laman pagkatapos ng restore. Sa parehong kaso, ang app ay dapat gumana nang tama sa walang laman na cache, nang hindi nagpapakita ng mga error sa user at hindi nawawalan ng functionality.

Mga rekomendasyon sa pamamahala ng cache

Ang mahusay na pamamahala ng cache ay isa sa mga factor na nakakaapekto sa karanasan ng user at rating ng app. Ang mga sumusunod na rekomendasyon ay makakatulong na maiwasan ang mga karaniwang problema at mapataas ang kasiyahan ng user.

• Magtakda ng limitasyon sa laki ng cache. Gumamit ng DiskLruCache o katulad na library na may pagtukoy ng maximum na volume sa megabytes. Pagkatapos lumampas sa limitasyon, awtomatikong tinatanggal ng library ang mga file na pinakabihirang ginagamit
• Magpatupad ng button sa pag-clear ng cache sa mga setting ng app. Ipakita ang kasalukuyang laki ng cache (sa format na \u201e12.5 MB\u201d) at humingi ng kumpirmasyon bago mag-clear. Pagkatapos mag-clear, i-update ang ipinapakitang laki
• Huwag itago sa cache ang mga file na hindi maaaring maibalik. Kung ang data ay kritikal para sa pagpapatakbo ng app, itago ito sa Internal Storage (Android) o Documents (iOS), at sa cache ay maglagay lamang ng kopya para sa mabilis na access
• Suriin ang availability ng external na cache bago magsulat. Sa Android, ang context.externalCacheDir ay maaaring magbalik ng null kung ang SD card ay hindi naka-install o hindi available. Laging magbigay ng fallback sa internal na cache
• Gumamit ng patakaran sa pag-expire (TTL) para sa naka-cache na data. Huwag itago ang mga file nang mas mahaba kaysa kinakailangan: para sa mga larawan \u2014 24\u201348 oras, para sa mga tugon ng API \u2014 mula 5 minuto hanggang 1 oras depende sa dalas ng pag-update ng data

Regular na subaybayan ang laki ng cache sa analytics ng app. Isama ang pagpapadala ng metric ng laki ng cache sa Firebase Analytics o katulad na system. Kung ang average na laki ng cache ay lumampas sa 100 MB, i-optimize ang caching strategy: bawasan ang TTL para sa bihirang ginagamit na data, ipatupad ang compression ng larawan bago mag-cache (WebP sa halip na PNG, pagbaba ng kalidad ng JPEG sa 85%), gumamit ng pagination para sa pag-load ng content mula sa server. Tandaan na ang mga user na may 16\u201332 GB device ay partikular na sensitibo sa laki ng app: kapag umabot sa 200 MB ang cache, maraming user ang nagsisimulang maghanap ng paraan upang mag-clear o tanggalin na lang ang app. Ayon sa isang survey ng Google, 38% ng mga user ay nagtanggal ng kahit isang app dahil sa hindi kontroladong paglaki ng cache at espasyo na ginamit.