دليل التخزين المؤقت للتطبيق — ما هو، الغرض منه وكيفية مسحه في تطوير التطبيقات المحمولة

ما هو دليل التخزين المؤقت للتطبيق؟

دليل التخزين المؤقت هو دليل خاص في الذاكرة الداخلية (أو الخارجية) للتطبيق مصمم للملفات المؤقتة. الفرق الرئيسي عن Internal Storage: يحق للنظام حذف الملفات من ذاكرة التخزين المؤقت دون إشعار إذا كان الجهاز يعاني من نقص المساحة الحرة. لذلك، لا يجب على التطبيق أبدًا تخزين النسخة الوحيدة من بيانات المستخدم المهمة في ذاكرة التخزين المؤقت. ذاكرة التخزين المؤقت مثالية للصور المحملة، واستجابات الخادم، والموارد المترجمة مسبقًا، وأي بيانات أخرى يمكن استعادتها عن بُعد أو إعادة إنشائها برمجيًا.

على Android، يقع دليل التخزين المؤقت في المسار /data/data/<package>/cache/ ويمكن الوصول إليه عبر context.cacheDir. حجم ذاكرة التخزين المؤقت غير محدود بشكل صريح، لكن Google Play توصي بعدم تجاوز 100 ميجابايت، لأن التطبيقات ذات ذاكرة التخزين المؤقت الكبيرة تحصل على تقييمات سلبية من المستخدمين. على iOS، يقع دليل التخزين المؤقت داخل حاوية Sandbox في المسار Library/Caches/ ويمكن الوصول إليه عبر NSCachesDirectory. يمكن لـ iOS حذف الملفات من Caches عند استعادة الجهاز من نسخة احتياطية أو عند نقص حاد في المساحة — يجب إبلاغ المستخدمين بهذا في وثائق التطبيق.

فهم البيانات التي يمكن وضعها بأمان في ذاكرة التخزين المؤقت والتي يجب تخزينها في Internal Storage أو Documents هو مهارة أساسية للمطور. الاستخدام غير الصحيح لذاكرة التخزين المؤقت يؤدي إلى مشكلتين متعارضتين: إما أن يشغل التطبيق مساحة كبيرة جدًا (إذا قام المطور بتخزين ما يجب أن يكون في Documents في ذاكرة التخزين المؤقت) أو يفقد المستخدم البيانات (إذا قام المطور بتخزين ما يجب حفظه بشكل دائم في ذاكرة التخزين المؤقت). اتبع قاعدة بسيطة: إذا كان يمكن استعادة البيانات — ذاكرة تخزين مؤقت، إذا كانت الاستعادة مستحيلة — Internal Storage أو Documents.

الغرض وأنواع البيانات المخزنة مؤقتًا

أنواع البيانات المختلفة لها سرعة إعادة إنشاء ومتطلبات مساحة مختلفة. يساعد فهم هذه الخصائص المطور على اختيار الملفات التي يجب وضعها في ذاكرة التخزين المؤقت وأيها في التخزين الدائم.

ذاكرة تخزين مؤقت للصور وملفات الوسائط

النوع الأكثر شيوعًا من البيانات المخزنة مؤقتًا هو الصور المحملة من الشبكة. المكتبات Glide و Picasso و Coil تحفظ تلقائيًا الصور المحملة في دليل التخزين المؤقت للتطبيق. يتراوح الحجم النموذجي لذاكرة التخزين المؤقت للصور في التطبيقات الاجتماعية من 50 إلى 200 ميجابايت. يعتمد حجم ذاكرة التخزين المؤقت على دقة شاشة الجهاز وكمية المحتوى المعروض. تستخدم Glide تخزينًا مؤقتًا ذو مستويين: تتحقق أولاً من ذاكرة التخزين المؤقت L1 في RAM (خوارزمية LRU)، ثم ذاكرة التخزين المؤقت L2 على القرص. هذا يضمن تحميلًا سريعًا للصور المعروضة بشكل متكرر دون طلب شبكة إضافي. يتيح تكوين الحد الأقصى لحجم ذاكرة التخزين المؤقت على القرص عبر DiskCacheStrategy التحكم في المساحة المشغولة: عند تجاوز الحد، تقوم المكتبة تلقائيًا بحذف الملفات الأقل استخدامًا.

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 ->
        // كتابة البيانات إلى ذاكرة التخزين المؤقت
    }
}

ذاكرة تخزين مؤقت لطلبات الشبكة

يمكن تخزين استجابات طلبات API مؤقتًا للوصول دون اتصال وتقليل الحمل على الخادم. يوفر OkHttp دعمًا مدمجًا للتخزين المؤقت عبر فئة Cache. تدير رؤوس الاستجابة Cache-Control و ETag سياسة التخزين المؤقت: يحدد الخادم المدة التي تعتبر فيها الاستجابة صالحة. مع التكوين الصحيح، يمكن لذاكرة التخزين المؤقت لطلبات الشبكة تقليل وقت تحميل البيانات بنسبة 60–80% في الزيارات المتكررة وتوفير وظائف أساسية للتطبيق بدون اتصال بالإنترنت. نادرًا ما يتجاوز حجم ذاكرة التخزين المؤقت لطلبات الشبكة 10–20 ميجابايت، لكن مع الاستخدام المكثف للتطبيق يمكن أن يصل إلى 50 ميجابايت. قم بتكوين الحد الأقصى لحجم ذاكرة التخزين المؤقت عبر مُنشئ OkHttpClient.Builder وتحقق من صلاحية البيانات المخزنة مؤقتًا عند كل تشغيل للتطبيق.

ذاكرة تخزين مؤقت لقواعد البيانات والبيانات المترجمة مسبقًا

قواعد بيانات SQLite يمكن أن تولد ملفات مؤقتة أثناء العمل: ملفات WAL (سجل الكتابة المسبقة)، وسجلات التراجع، وصفحات الفهارس. يتم تخزين هذه الملفات بجانب قاعدة البيانات الرئيسية، ولكن لقواعد البيانات المؤقتة (على سبيل المثال، البحث النصي الكامل أو التحليلات) يمكن تحديد موقعها في دليل التخزين المؤقت. يتم أيضًا تخزين برامج shader المترجمة مسبقًا لـ OpenGL و Vulkan في هذا الدليل، مما يسرع التحميل الأولي لمشاهد الرسومات. على iOS، يُوصى باستخدام NSCachesDirectory لتخزين بيانات Core Data المترجمة مسبقًا وملفات معالجة الصور المؤقتة.

كيف يعمل مسح ذاكرة التخزين المؤقت على Android و iOS

يمكن أن يتم مسح ذاكرة التخزين المؤقت تلقائيًا (بواسطة النظام) أو يدويًا (بواسطة المستخدم أو التطبيق). فهم سلوك النظام في السيناريوهات المختلفة ضروري لمنع فقدان البيانات.

المسح التلقائي بواسطة النظام

على Android، يبدأ النظام عملية مسح ذاكرة التخزين المؤقت عندما تنخفض المساحة الحرة على قسم /data عن الحد الحرج (عادة 500 ميجابايت). تقوم عملية cacheflush بتحليل حجم ذاكرة التخزين المؤقت لجميع التطبيقات المثبتة وحذف الملفات الأقل استخدامًا، بدءًا من الأقدم. يمكن للمستخدم أيضًا مسح ذاكرة التخزين المؤقت لجميع التطبيقات يدويًا عبر إعدادات النظام: «الإعدادات ← التخزين ← ذاكرة التخزين المؤقت ← مسح ذاكرة التخزين المؤقت». على iOS، يحدث المسح التلقائي لـ Caches عند استعادة الجهاز من نسخة احتياطية — لا يستعيد iOS محتويات Library/Caches/. بالإضافة إلى ذلك، يمكن لـ iOS حذف الملفات بشكل انتقائي من Caches عند نفاد المساحة الحرة، باستخدام آلية التخزين القابل للتنظيف للبيانات المعزولة.

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، التطبيقات التي تحتوي على زر مسح ذاكرة التخزين المؤقت تحصل على شكاوى أقل بنسبة 22% حول نقص المساحة مقارنة بالتطبيقات بدون هذه الميزة. يجب أن يكون مسح ذاكرة التخزين المؤقت آمنًا: يجب على التطبيق التعامل بشكل صحيح مع الحالة التي يتم فيها حذف الملفات المخزنة مؤقتًا وإعادة تحميلها بشفافية عند الوصول التالي.

الاختلافات بين cacheDir على Android و iOS

على الرغم من الغرض نفسه، فإن تنفيذ أدلة التخزين المؤقت على Android و iOS له اختلافات جوهرية. يجب على المطور مراعاتها للتشغيل الصحيح للتطبيق على كلا المنصتين.

Android يوفر دليل تخزين مؤقت خارجي منفصل عبر context.externalCacheDir — يقع على بطاقة SD (إذا كانت مثبتة) ولا يتم حذفه عند إلغاء تثبيت التطبيق. هذا مناسب للملفات الوسائط الكبيرة، لكنه يخلق خطر ترك المخلفات على بطاقة الذاكرة. iOS ليس لديه مفهوم ذاكرة التخزين المؤقت الخارجية: جميع الملفات المؤقتة تُخزن داخل حاوية Sandbox ويتم حذفها بشكل مضمون عند إلغاء التثبيت. على Android، ذاكرة التخزين المؤقت مرئية للمستخدم في إعدادات التطبيق ويمكنه مسحها يدويًا. على iOS، إعدادات النظام لا تظهر حجم ذاكرة التخزين المؤقت للتطبيقات الفردية — يمكن للمستخدم مسح ذاكرة التخزين المؤقت فقط عن طريق حذف التطبيق وإعادة تثبيته، ما لم يضف المطور زر مسح في الواجهة.

اختلاف مهم — السلوك أثناء الاستعادة. على iOS، عند الاستعادة من نسخة احتياطية لـ iTunes أو iCloud، لا يتم استعادة دليل Caches، لأن iOS يفترض أن البيانات المخزنة مؤقتًا سيتم إعادة إنشائها عند التشغيل الأول. على Android، عند الاستعادة من Google Drive، يتم نسخ Internal Storage فقط احتياطيًا — تبقى ذاكرة التخزين المؤقت فارغة بعد الاستعادة. في كلتا الحالتين، يجب أن يعمل التطبيق بشكل صحيح مع ذاكرة تخزين مؤقت فارغة، دون عرض أخطاء للمستخدم أو فقدان الوظائف.

توصيات إدارة ذاكرة التخزين المؤقت

الإدارة الجيدة لذاكرة التخزين المؤقت للتطبيق هي أحد العوامل المؤثرة على تجربة المستخدم وتقييم التطبيق. التوصيات التالية ستساعد في تجنب المشكلات النموذجية وزيادة رضا المستخدمين.

• حدد حدًا لحجم ذاكرة التخزين المؤقت. استخدم DiskLruCache أو مكتبات مماثلة مع تحديد الحد الأقصى للحجم بالميغابايت. عند تجاوز الحد، تقوم المكتبة تلقائيًا بحذف الملفات الأقل استخدامًا
• نفذ زر مسح ذاكرة التخزين المؤقت في إعدادات التطبيق. اعرض الحجم الحالي لذاكرة التخزين المؤقت (بتنسيق «12.5 ميجابايت») واطلب التأكيد قبل المسح. بعد المسح، قم بتحديث الحجم المعروض
• لا تخزن في ذاكرة التخزين المؤقت الملفات التي لا يمكن استعادتها. إذا كانت البيانات حرجة لعمل التطبيق، قم بتخزينها في Internal Storage (Android) أو Documents (iOS)، وضع نسخة فقط في ذاكرة التخزين المؤقت للوصول السريع
• تحقق من توفر ذاكرة التخزين المؤقت الخارجية قبل الكتابة. على Android، قد يعيد context.externalCacheDir قيمة null إذا كانت بطاقة SD غير مثبتة أو غير متوفرة. وفر دائمًا خيار احتياطي لذاكرة التخزين المؤقت الداخلية
• استخدم سياسة انتهاء الصلاحية (TTL) للبيانات المخزنة مؤقتًا. لا تخزن الملفات لفترة أطول من اللازم: للصور — 24–48 ساعة، لاستجابات API — من 5 دقائق إلى ساعة واحدة حسب تكرار تحديث البيانات

راقب بانتظام حجم ذاكرة التخزين المؤقت في تحليلات التطبيق. قم بدمج إرسال مقياس حجم ذاكرة التخزين المؤقت في Firebase Analytics أو نظام مشابه. إذا تجاوز متوسط حجم ذاكرة التخزين المؤقت 100 ميجابايت، قم بتحسين استراتيجية التخزين المؤقت: قلل TTL للبيانات نادرة الاستخدام، طبق ضغط الصور قبل التخزين المؤقت (WebP بدلاً من PNG، اخفض جودة JPEG إلى 85%)، استخدم التقسيم الصفحي لتحميل المحتوى من الخادم. تذكر أن المستخدمين الذين لديهم أجهزة بسعة 16–32 جيجابايت حساسون بشكل خاص لحجم التطبيق: عند وصول ذاكرة التخزين المؤقت إلى 200 ميجابايت، يبدأ العديد من المستخدمين في البحث عن طريقة لمسحها أو ببساطة حذف التطبيق. وفقًا لاستطلاع Google، قام 38% من المستخدمين بحذف تطبيق واحد على الأقل بسبب النمو غير المنضبط لذاكرة التخزين المؤقت والمساحة المشغولة.