Tətbiqin keş qovluğu — bu nədir, məqsədi və mobil inkişafda necə təmizlənməlidir

Tətbiqin keş qovluğu nədir?

Keş qovluğu — tətbiqin daxili (və ya xarici) yaddaşında müvəqqəti fayllar üçün nəzərdə tutulmuş xüsusi qovluqdur. Internal Storage-dən əsas fərqi: cihazda boş yer çatışmadıqda sistem xəbərdarlıq etmədən keş fayllarını silə bilər. Buna görə tətbiq heç vaxt keşdə istifadəçinin vacib məlumatlarının yeganə surətini saxlamamalıdır. Keş yüklənmiş şəkillər, server cavabları, prekompil edilmiş resurslar və uzaqdan bərpa oluna və ya proqram vasitəsilə yenidən yaradıla bilən digər məlumatlar üçün optimaldır.

Android-də keş qovluğu /data/data/<paket>/cache/ ünvanındadır və context.cacheDir vasitəsilə əldə olunur. Keşin ölçüsü açıqca məhdudlaşdırılmayıb, lakin Google Play 100 MB-ı keçməməyi tövsiyə edir, çünki böyük keşi olan tətbiqlər istifadəçilərdən pis rəy alır. iOS-da keş qovluğu Sandbox konteyneri daxilində Library/Caches/ ünvanındadır və NSCachesDirectory vasitəsilə əldə olunur. iOS cihazı ehtiyat nüsxədən bərpa edərkən və ya kritik yer çatışmazlığında Caches fayllarını silə bilər — bu barədə tətbiq sənədlərində istifadəçiləri xəbərdar etmək lazımdır.

Hansı məlumatların keşdə, hansıların isə Internal Storage və ya Documents-də saxlanmasını başa düşmək proqramçının əsas bacarığıdır. Keşdən yanlış istifadə iki əks problemə gətirib çıxarır: ya tətbiq çox yer tutur (proqramçı keşdə Documents-də olmalı olanı saxlayırsa), ya da istifadəçi məlumat itirir (proqramçı keşdə daimi saxlanmalı olanı saxlayırsa). Sadə qaydaya əməl edin: məlumat bərpa oluna bilərsə — keş, bərpa mümkün deyilsə — Internal Storage və ya Documents.

Keşləşdirilən məlumatların məqsədi və növləri

Müxtəlif məlumat növlərinin müxtəlif bərpa sürəti və həcm tələbləri var. Bu xarakteristikaları başa düşmək proqramçıya hansı faylların keşdə, hansıların isə daimi yaddaşda saxlanacağını düzgün seçməyə kömək edir.

Şəkillərin və media fayllarının keşi

Ən geniş yayılmış keşləşdirilən məlumat növü şəbəkədən yüklənmiş şəkillərdir. Glide, Picasso və Coil kitabxanaları yüklənmiş şəkilləri avtomatik olaraq tətbiqin keş qovluğunda saxlayır. Sosial tətbiqlərdə şəkil keşinin tipik ölçüsü 50 ilə 200 MB arasındadır. Keşin ölçüsü cihazın ekran həlli və baxılan məzmunun miqdarından asılıdır. Glide iki səviyyəli keşləşdirmədən istifadə edir: əvvəlcə operativ yaddaşda L1 keşini (LRU alqoritmi), sonra diskdə L2 keşini yoxlayır. Bu, şəbəkəyə təkrar sorğu olmadan təkrar baxılan şəkillərin sürətli yüklənməsini təmin edir. DiskCacheStrategy vasitəsilə disk keşinin maksimum ölçüsünün tənzimlənməsi yerin idarə edilməsinə imkan verir: limit aşıldıqda kitabxana avtomatik olaraq ən az istifadə olunan faylları silir.

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 ->
        // məlumatların keşə yazılması
    }
}

Şəbəkə sorğularının keşi

API sorğularının cavabları oflayn giriş və server yükünü azaltmaq üçün keşləşdirilə bilər. OkHttp Cache sinfi vasitƏlə daxili keşləşdirmə dəstəyi təmin edir. Cache-Control və ETag cavab başlıqları keşləşdirmə siyasətini idarə edir: server cavabın nə qədər aktual olduğunu göstərir. Düzgün konfiqurasiya ilə şəbəkə sorğularının keşi təkrar ziyarətlərdə məlumat yüklənmə vaxtını 60–80% azalda və internet bağlantısı olmadan tətbiqin əsas funksionallığını təmin edə bilər. Şəbəkə sorğularının keşinin ölçüsü nadir hallarda 10–20 MB-ı keçir, lakin aktiv istifadədə 50 MB-ıa çata bilər. OkHttpClient.Builder konstruktoru vasitəsilə keşin maksimum ölçüsünü təyin edin və tətbiqin hər işə salınmasında keşləşdirilmiş məlumatların aktuallığını yoxlayın.

Verilənlər bazası və prekompil edilmiş məlumatların keşi

SQLite verilənlər bazaları iş zamanı müvəqqəti fayllar yarada bilər: WAL faylları (Write-Ahead Log), geri qayıtma jurnalları və indeks səhifələri. Bu fayllar əsas verilənlər bazasının yanında saxlanılır, lakin müvəqqəti verilənlər bazaları üçün (məsələn, tam mətnli axtarış və ya analitika) keş qovluğunda yerləşdirilmə göstərilə bilər. OpenGL və Vulkan-ın prekompil edilmiş shader proqramları da bu qovluqda keşləşdirilir ki, bu da qrafik səhnələrin ilk yüklənməsini sürətləndirir. iOS-da NSCachesDirectory Core Data-nın prekompil edilmiş məlumatlarının və şəkil emalının müvəqqəti fayllarının saxlanması üçün tövsiyə olunur.

Android və iOS-da keşin təmizlənməsi necə işləyir

Keşin təmizlənməsi avtomatik (sistem tərəfindən) və ya əl ilə (istifadəçi və ya tətbiq tərəfindən) baş verə bilər. Məlumat itkisinin qarşısını almaq üçün müxtəlif ssenarilərdə sistemin davranışını başa düşmək lazımdır.

Sistem tərəfindən avtomatik təmizləmə

Android-də sistem /data bölməsində boş yerin həcmi kritik həddən (adətən 500 MB) aşağı düşdükdə keşin təmizlənməsi prosesini işə salır. cacheflush prosesi bütün qurulmuş tətbiqlərin keş ölçüsünü təhlil edir və ən köhnələrdən başlayaraq ən az istifadə olunan faylları silir. İstifadəçi həmçinin sistem parametrləri vasitəsilə bütün tətbiqlərin keşini əl ilə təmizləyə bilər: „Parametrlər → Yaddaş → Keş → Keşi təmizlə”. iOS-da Caches-in avtomatik təmizlənməsi cihazı ehtiyat nüsxədən bərpa edərkən baş verir — iOS Library/Caches/ məzmununu bərpa etmir. Bundan əlavə, iOS cihazda boş yer bitdikdə Caches-dən faylları seçmə şəkildə silə, təcrid olunmuş məlumatlar üçün purgeable storage mexanizmindən istifadə edə bilər.

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

Tətbiq tərəfindən proqram təmizliyi

Proqramçı istifadəçinin istəyi ilə və ya cədvəl üzrə proqram təmizliyini həyata keçirə bilər. Android-də öz keşini təmizləmək üçün context.cacheDir və context.externalCacheDir-dəki bütün faylları silmək kifayətdir. iOS-da Library/Caches/ məzmununu təmizləmək olar, lakin qovluğun özünü yox, yalnız məzmununu silin. Tətbiq parametrlərində istifadəçiyə cari keş ölçüsü və təsdiqlə „Keşi təmizlə” düyməsi göstərmək tövsiyə olunur. Google Play Console məlumatlarına görə, keşi təmizləmə düyməsi olan tətbiqlər bu funksiyasız tətbiqlərlə müqayisədə 22% az yer çatışmazlığı şikayəti alır. Keşin təmizlənməsi təhlükəsiz olmalıdır: tətbiq keşləşdirilmiş fayllar silindikdə vəziyyəti düzgün idarə etməli və növbəti müraciətdə şəffaf şəkildə yenidən yükləməlidir.

Android və iOS-da cacheDir fərqləri

Eyni təyinata baxmayaraq, Android və iOS-da keş qovluqlarının tətbiqi əhəmiyyətli fərqlərə malikdir. Proqramçı hər iki platformada tətbiqin düzgün işləməsi üçün bunları nəzərə almalıdır.

Android context.externalCacheDir vasitəsilə ayrıca xarici keş qovluğu təqdim edir — o, SD kartdadır (quraşdırılıbsa) və tətbiq silindikdə silinmir. Bu, böyük media faylları üçün əlverişlidir, lakin yaddaş kartında zibil qalma riski yaradır. iOS xarici keş anlayışına malik deyil: bütün müvəqqəti fayllar Sandbox konteyneri daxilində saxlanılır və deinstallasya zamanı zəmanətlə silinir. Android-də keş istifadəçiyə tətbiq parametrlərində görünür və o, onu əl ilə təmizləyə bilər. iOS-da sistem parametrləri ayrı-ayrı tətbiqlərin keş ölçüsünü göstərmir — istifadəçi keşi yalnız tətbiqi silib yenidƏn qurmaqla təmizləyə bilər, əgər proqramçı interfeysə təmizlik düyməsi əlavə etməyibsə.

Əhəmiyyətli fərq — bərpa zamanı davranış. iOS-da iTunes və ya iCloud ehtiyat nüsxəsindən bərpa edərkən Caches qovluğu bərpa edilmir, çünki iOS keşləşdirilmiş məlumatların ilk işə salınmada yenidƏn yaradılacağını gözləyir. Android-də Google Drive-dən bərpa edərkən yalnız Internal Storage arxivləşdirilir — bərpadan sonra keş boş qalır. Hər iki halda tətbiq boş keşlə düzgün işləməli, istifadəçiyə səhv göstərməməli və funksionallığı itirməməlidir.

Keşin idarə edilməsi üzrə tövsiyələr

Keşin bacarıqlı idarə edilməsi tətbiqin istifadəçi təcrübəsinə və reytinqinə təsir edən amillərdən biridir. Aşağıdakı tövsiyələr tipik problemlərdən qaçmağa və istifadəçi məmnuniyyətini artırmağa kömək edəcək.

• Keşin ölçüsü həddini təyin edin. DiskLruCache və ya oxşar kitabxanalardan maksimum həcmi meqabaytlarla göstərərək istifadə edin. Limit aşıldıqda kitabxana avtomatik olaraq ən az istifadə olunan faylları silir
• Tətbiq parametrlərində təmizlik düyməsi yaradın. Cari keş ölçüsünü („12.5 MB” formatında) göstərin və təmizlikdən əvvəl təsdiq tələb edin. Təmizlikdən sonra göstərilən ölçünü yeniləyin
• Keşdə bərpa olunmayan faylları saxlamayın. Məlumat tətbiqin işləməsi üçün kritikdirsə, onu Internal Storage (Android) və ya Documents (iOS)-də saxlayın, keşdə isə yalnız sürətli giriş üçün surət saxlayın
• Yazıdan əvvəl xarici keşin əlçatanlığını yoxlayın. Android-də context.externalCacheDir SD kart quraşdırılmayıbsa və ya əlçatan deyilsə null qaytara bilər. Həmişə daxili keşə fallback nəzərdə tutun
• Köhnəlmə siyasəti (TTL) tətbiq edin. Faylları lazım olduğundan artıq saxlamayın: şəkillər üçün 24–48 saat, API cavabları üçün məlumat yenilənmə tezliyindən asılı olaraq 5 dəqiqədən 1 saata qədər

Mütəmadi olaraq tətbiq analitikasında keş ölçüsünü izləyin. Firebase Analytics və ya oxşar sistemə keş ölçüsü metrikasının göndərilməsini inteqrasiya edin. Orta keş ölçüsü 100 MB-ı keçərsə, keşləşdirmə strategiyasını optimallaşdırın: nadir istifadə olunan məlumatlar üçün TTL-i azaldın, keşləşdirmədən əvvəl şəkil sıxılmasını tətbiq edin (PNG əvəzinə WebP, JPEG keyfiyyətini 85%-ə endirin), serverdən məzmun yükləmək üçün paginasiyadan istifadə edin. Yadda saxlayın ki, 16–32 GB yaddaşlı cihazların istifadəçiləri tətbiqin ölçüsünə xüsusilə həssasdır: keş 200 MB-ıa çatdıqda bir çox istifadəçi təmizlik yolu axtarmağa və ya sadəcə tətbiqi silməyə başlayır. Google sorğusuna görə, istifadəçilərin 38%-i nəzarətsiz keş artımı və tutulan yer səbəbindən ən azı bir tətbiqi silib.