دایرکتوری کش برنامه — چیست، کاربرد و نحوه پاک کردن در توسعه موبایل

دایرکتوری کش برنامه چیست؟

دایرکتوری کش یک دایرکتوری ویژه در حافظه داخلی (یا خارجی) برنامه است که برای فایل‌های موقت در نظر گرفته شده است. تفاوت اصلی با Internal Storage: سیستم حق دارد بدون اطلاع‌رسانی فایل‌ها را از کش حذف کند، اگر دستگاه فضای خالی کافی نداشته باشد. بنابراین برنامه هرگز نباید تنها نسخه داده‌های مهم کاربر را در کش ذخیره کند. کش برای تصاویر بارگذاری شده، پاسخ‌های سرور، منابع پیش‌کامپایل شده و هر داده دیگری که می‌توان از راه دور بازیابی یا برنامه‌نویسی دوباره ایجاد کرد، بهینه است.

در Android، دایرکتوری کش در مسیر /data/data/<package>/cache/ قرار دارد و از طریق context.cacheDir قابل دسترسی است. اندازه کش به صراحت محدود نشده، اما Google Play توصیه می‌کند از ۱۰۰ مگابایت تجاوز نکند، زیرا برنامه‌های با کش بزرگ نظرات منفی کاربران را دریافت می‌کنند. در iOS دایرکتوری کش در داخل کانتینر Sandbox در مسیر Library/Caches/ قرار دارد و از طریق NSCachesDirectory قابل دسترسی است. iOS ممکن است فایل‌های Caches را هنگام بازیابی دستگاه از پشتیبان یا در کمبود بحرانی فضا حذف کند — باید کاربران را در مستندات برنامه از این موضوع آگاه کرد.

درک اینکه کدام داده را می‌توان با خیال راحت در کش قرار داد و کدام باید در Internal Storage یا Documents ذخیره شود، مهارت کلیدی توسعه‌دهنده است. استفاده نادرست از کش به دو مشکل متضاد منجر می‌شود: یا برنامه فضای زیادی اشغال می‌کند (اگر توسعه‌دهنده آنچه را که باید در Documents باشد در کش ذخیره کند)، یا کاربر داده‌ها را از دست می‌دهد (اگر توسعه‌دهنده آنچه را که باید دائمی ذخیره شود در کش قرار دهد). از یک قانون ساده پیروی کنید: اگر داده قابل بازیابی است — کش، اگر بازیابی غیرممکن است — Internal Storage یا Documents.

کاربرد و انواع داده‌های کش

انواع مختلف داده‌ها سرعت بازآفرینی و نیازهای حجمی متفاوتی دارند. درک این ویژگی‌ها به توسعه‌دهنده کمک می‌کند تا به درستی انتخاب کند کدام فایل‌ها را در کش و کدام را در ذخیره دائمی قرار دهد.

کش تصاویر و فایل‌های رسانه‌ای

رایج‌ترین نوع داده‌های کش — تصاویر بارگذاری شده از شبکه هستند. کتابخانه‌های Glide، Picasso و Coil به طور خودکار تصاویر بارگذاری شده را در دایرکتوری کش برنامه ذخیره می‌کنند. حجم معمول کش تصاویر در برنامه‌های اجتماعی بین ۵۰ تا ۲۰۰ مگابایت است. اندازه کش به وضوح صفحه نمایش دستگاه و میزان محتوای مشاهده شده بستگی دارد. Glide از کش دو سطحی استفاده می‌کند: ابتدا کش L1 در حافظه RAM (الگوریتم LRU)، سپس کش L2 روی دیسک. این کار بارگذاری سریع تصاویر مشاهده شده مجدد را بدون درخواست دوباره از شبکه تضمین می‌کند. تنظیم حداکثر اندازه کش دیسک از طریق DiskCacheStrategy به شما امکان کنترل فضای اشغال شده را می‌دهد: هنگام تجاوز از حد مجاز، کتابخانه به طور خودکار کم‌استفاده‌ترین فایل‌ها را حذف می‌کند.

val cacheDir = File(context.cacheDir, "image_cache")
val maxSize = 50 * 1024 * 1024 // 50 مگابایت

val cache = DiskLruCache.open(cacheDir, 1, 1, maxSize)
cache.edit("key")?.let { editor ->
    editor.newOutputStream(0).use { stream ->
        // ذخیره داده در کش
    }
}

کش درخواست‌های شبکه

پاسخ‌های درخواست‌های API را می‌توان برای دسترسی آفلاین و کاهش بار سرور کش کرد. OkHttp پشتیبانی داخلی از کش را از طریق کلاس Cache فراهم می‌کند. هدرهای Cache-Control و ETag سیاست کش را کنترل می‌کنند: سرور مشخص می‌کند که پاسخ تا چه مدت معتبر است. با پیکربندی صحیح، کش درخواست‌های شبکه می‌تواند زمان بارگذاری داده را در بازدیدهای مکرر ۶۰-۸۰٪ کاهش دهد و عملکرد اولیه برنامه را بدون اتصال اینترنت تضمین کند. اندازه کش درخواست‌های شبکه به ندرت از ۱۰-۲۰ مگابایت تجاوز می‌کند، اما در استفاده فعال از برنامه ممکن است به ۵۰ مگابایت برسد. حداکثر اندازه کش را از طریق سازنده OkHttpClient.Builder تنظیم کنید و در هر بار راه‌اندازی برنامه اعتبار داده‌های کش را بررسی کنید.

کش پایگاه‌های داده و داده‌های پیش‌کامپایل شده

پایگاه‌های داده SQLite ممکن است در حین کار فایل‌های موقت تولید کنند: فایل‌های WAL (Write-Ahead Log)، لاگ‌های بازگشت و صفحات ایندکس. این فایل‌ها در کنار پایگاه داده اصلی ذخیره می‌شوند، اما برای پایگاه‌های داده موقت (مثلاً جستجوی متن کامل یا تحلیل) می‌توان مکان را در دایرکتوری کش مشخص کرد. برنامه‌های shader پیش‌کامپایل شده OpenGL و Vulkan نیز در این دایرکتوری کش می‌شوند که بارگذاری اولیه صحنه‌های گرافیکی را تسریع می‌کند. در iOS، NSCachesDirectory برای ذخیره داده‌های پیش‌کامپایل شده Core Data و فایل‌های موقت پردازش تصویر توصیه می‌شود.

پاک‌سازی کش در Android و iOS چگونه کار می‌کند

پاک‌سازی کش می‌تواند به طور خودکار (توسط سیستم) یا دستی (توسط کاربر یا برنامه) انجام شود. درک رفتار سیستم در سناریوهای مختلف برای جلوگیری از از دست رفتن داده ضروری است.

پاک‌سازی خودکار توسط سیستم

در Android، سیستم زمانی فرآیند پاک‌سازی کش را شروع می‌کند که حجم فضای خالی پارتیشن /data از آستانه بحرانی (معمولاً ۵۰۰ مگابایت) پایین‌تر رود. فرآیند cacheflush اندازه کش همه برنامه‌های نصب شده را تحلیل کرده و کم‌استفاده‌ترین فایل‌ها را از قدیمی‌ترین‌ها شروع به حذف می‌کند. کاربر همچنین می‌تواند از طریق تنظیمات سیستم کش همه برنامه‌ها را به صورت دستی پاک کند: «تنظیمات → ذخیره‌سازی → کش → پاک کردن کش». در iOS، پاک‌سازی خودکار Caches هنگام بازیابی دستگاه از پشتیبان رخ می‌دهد — iOS محتوای Library/Caches/ را بازیابی نمی‌کند. علاوه بر این، iOS ممکن است به صورت انتخابی فایل‌ها را از Caches حذف کند، زمانی که فضای خالی دستگاه تمام می‌شود، با استفاده از مکانیزم purgeable storage برای داده‌های جدا شده.

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

پاک‌سازی برنامه‌نویسی کش توسط برنامه

توسعه‌دهنده می‌تواند پاک‌سازی برنامه‌نویسی کش را به درخواست کاربر یا به صورت برنامه‌ریزی شده پیاده‌سازی کند. در Android برای پاک‌سازی کش خود کافی است همه فایل‌های موجود در context.cacheDir و context.externalCacheDir حذف شوند. در iOS می‌توان محتوای Library/Caches/ را پاک کرد، اما خود دایرکتوری را حذف نکنید — فقط محتوای آن. توصیه می‌شود اندازه فعلی کش را در تنظیمات برنامه به کاربر نشان دهید و دکمه «پاک کردن کش» با تأیید قرار دهید. طبق داده‌های Google Play Console، برنامه‌های دارای دکمه پاک‌سازی کش ۲۲٪ شکایت کمتری در مورد کمبود فضا در مقایسه با برنامه‌های بدون این ویژگی دریافت می‌کنند. پاک‌سازی کش باید ایمن باشد: برنامه باید وضعیت حذف فایل‌های کش را به درستی مدیریت کرده و در مراجعه بعدی آن‌ها را به صورت شفاف دوباره بارگذاری کند.

تفاوت‌های cacheDir در Android و iOS

با وجود کاربرد یکسان، پیاده‌سازی دایرکتوری‌های کش در Android و iOS تفاوت‌های قابل توجهی دارد. توسعه‌دهنده باید این موارد را برای عملکرد صحیح برنامه در هر دو پلتفرم در نظر بگیرد.

Android یک دایرکتوری کش خارجی جداگانه از طریق context.externalCacheDir فراهم می‌کند — روی SD-Card (در صورت نصب) قرار دارد و با حذف برنامه پاک نمی‌شود. این برای فایل‌های رسانه‌ای بزرگ مناسب است، اما خطر باقی ماندن زباله روی کارت حافظه را ایجاد می‌کند. iOS مفهوم کش خارجی را ندارد: همه فایل‌های موقت در داخل کانتینر Sandbox ذخیره شده و با حذف نصب برنامه به طور تضمینی پاک می‌شوند. در Android، کش در تنظیمات برنامه برای کاربر قابل مشاهده است و می‌تواند آن را به صورت دستی پاک کند. در iOS، تنظیمات سیستم اندازه کش برنامه‌های جداگانه را نشان نمی‌دهد — کاربر فقط می‌تواند با حذف و نصب مجدد برنامه کش را پاک کند، مگر اینکه توسعه‌دهنده دکمه پاک‌سازی را در رابط کاربری اضافه کرده باشد.

تفاوت مهم — رفتار هنگام بازیابی. در iOS هنگام بازیابی از پشتیبان iTunes یا iCloud، دایرکتوری Caches بازیابی نمی‌شود، زیرا iOS معتقد است داده‌های کش در اولین راه‌اندازی دوباره ایجاد می‌شوند. در Android هنگام بازیابی از Google Drive، فقط Internal Storage پشتیبان گرفته می‌شود — کش پس از بازیابی خالی می‌ماند. در هر دو مورد، برنامه باید با کش خالی به درستی کار کند، بدون اینکه خطا به کاربر نشان دهد یا عملکردی را از دست بدهد.

توصیه‌های مدیریت کش

مدیریت صحیح کش برنامه یکی از عوامل مؤثر بر تجربه کاربر و رتبه برنامه است. توصیه‌های زیر به جلوگیری از مشکلات معمول و افزایش رضایت کاربران کمک می‌کند.

• محدودیت اندازه کش را تعیین کنید. از DiskLruCache یا کتابخانه‌های مشابه با تعیین حداکثر حجم بر حسب مگابایت استفاده کنید. هنگام تجاوز از حد مجاز، کتابخانه به طور خودکار کم‌استفاده‌ترین فایل‌ها را حذف می‌کند
• دکمه پاک‌سازی کش را در تنظیمات برنامه پیاده‌سازی کنید. اندازه فعلی کش را (به فرمت «۱۲.۵ مگابایت») نشان داده و قبل از پاک‌سازی تأیید بگیرید. پس از پاک‌سازی، اندازه نمایش داده شده را به‌روز کنید
• در کش ذخیره نکنید فایل‌هایی که قابل بازیابی نیستند. اگر داده برای عملکرد برنامه حیاتی است، آن را در Internal Storage (Android) یا Documents (iOS) ذخیره کرده و فقط یک کپی برای دسترسی سریع در کش قرار دهید
• دسترسی به کش خارجی را قبل از نوشتن بررسی کنید. در Android، context.externalCacheDir ممکن است null برگرداند اگر SD-Card نصب یا در دسترس نباشد. همیشه fallback به کش داخلی را در نظر بگیرید
• از سیاست انقضا (TTL) برای داده‌های کش استفاده کنید. فایل‌ها را بیش از حد لازم نگه ندارید: برای تصاویر — ۲۴-۴۸ ساعت، برای پاسخ‌های API — از ۵ دقیقه تا ۱ ساعت بسته به فراوانی به‌روزرسانی داده

به طور منظم اندازه کش را در تحلیل برنامه پایش کنید. ارسال متریک اندازه کش را در Firebase Analytics یا سیستم مشابه ادغام کنید. اگر میانگین اندازه کش از ۱۰۰ مگابایت بیشتر شد، استراتژی کش را بهینه کنید: TTL را برای داده‌های کم‌استفاده کاهش دهید، فشرده‌سازی تصاویر را قبل از کش پیاده‌سازی کنید (WebP به جای PNG، کاهش کیفیت JPEG به ۸۵٪)، از صفحه‌بندی برای بارگذاری محتوا از سرور استفاده کنید. به یاد داشته باشید که کاربران با دستگاه‌های ۱۶-۳۲ گیگابایتی به ویژه به اندازه برنامه حساس هستند: با رسیدن کش به ۲۰۰ مگابایت، بسیاری از کاربران به دنبال روش پاک‌سازی می‌گردند یا به سادگی برنامه را حذف می‌کنند. طبق نظرسنجی Google، ۳۸٪ از کاربران حداقل یک برنامه را به دلیل رشد کنترل‌نشده کش و فضای اشغال شده حذف کرده‌اند.