ऐप कैश डायरेक्टरी — यह क्या है, उद्देश्य और मोबाइल डेवलपमेंट में इसे कैसे साफ़ करें

ऐप कैश डायरेक्टरी क्या है?

कैश डायरेक्टरी एप्लिकेशन की आंतरिक (या बाहरी) मेमोरी में एक विशेष डायरेक्टरी है जो अस्थायी फ़ाइलों के लिए डिज़ाइन की गई है। Internal Storage से मुख्य अंतर: सिस्टम को बिना सूचना के कैश से फ़ाइलें हटाने का अधिकार है यदि डिवाइस में खाली स्थान कम है। इसलिए, एप्लिकेशन को कभी भी महत्वपूर्ण उपयोगकर्ता डेटा की एकमात्र प्रति कैश में नहीं रखनी चाहिए। कैश डाउनलोड की गई छवियों, सर्वर प्रतिक्रियाओं, प्रीकंपाइल संसाधनों और किसी भी अन्य डेटा के लिए इष्टतम है जिसे दूरस्थ रूप से पुनर्स्थापित या प्रोग्रामेटिक रूप से पुनः बनाया जा सकता है।

Android पर, कैश डायरेक्टरी /data/data/<package>/cache/ पथ पर स्थित है और context.cacheDir के माध्यम से सुलभ है। कैश का आकार स्पष्ट रूप से सीमित नहीं है, लेकिन Google Play 100 MB से अधिक न करने की सलाह देता है, क्योंकि बड़े कैश वाले ऐप्स को नकारात्मक उपयोगकर्ता समीक्षाएँ मिलती हैं। iOS पर, कैश डायरेक्टरी Sandbox कंटेनर के अंदर Library/Caches/ पथ पर स्थित है और NSCachesDirectory के माध्यम से सुलभ है। iOS डिवाइस को बैकअप से पुनर्स्थापित करते समय या स्थान की गंभीर कमी होने पर Caches से फ़ाइलें हटा सकता है — इसके बारे में उपयोगकर्ताओं को ऐप दस्तावेज़ीकरण में सूचित किया जाना चाहिए।

यह समझना कि कौन सा डेटा सुरक्षित रूप से कैश में रखा जा सकता है और कौन सा Internal Storage या Documents में संग्रहीत किया जाना चाहिए, एक प्रमुख डेवलपर कौशल है। गलत कैश उपयोग से दो विपरीत समस्याएँ होती हैं: या तो ऐप बहुत अधिक स्थान लेता है (यदि डेवलपर कैश में वह संग्रहीत करता है जो Documents में होना चाहिए) या उपयोगकर्ता डेटा खो देता है (यदि डेवलपर कैश में वह संग्रहीत करता है जिसे स्थायी रूप से सहेजा जाना चाहिए)। एक सरल नियम का पालन करें: यदि डेटा पुनर्प्राप्त किया जा सकता है — कैश, यदि पुनर्प्राप्ति असंभव है — Internal Storage या Documents।

कैश किए गए डेटा का उद्देश्य और प्रकार

विभिन्न डेटा प्रकारों में अलग-अलग पुनर्निर्माण गति और स्थान आवश्यकताएँ होती हैं। इन विशेषताओं को समझने से डेवलपर को सही ढंग से चुनने में मदद मिलती है कि कौन सी फ़ाइलें कैश में रखनी हैं और कौन सी स्थायी भंडारण में।

छवि और मीडिया फ़ाइल कैश

सबसे सामान्य प्रकार का कैश किया गया डेटा — नेटवर्क से डाउनलोड की गई छवियाँ हैं। Glide, Picasso और Coil जैसी लाइब्रेरीज़ डाउनलोड की गई छवियों को स्वचालित रूप से ऐप की कैश डायरेक्टरी में सहेजती हैं। सोशल ऐप्स में छवि कैश का विशिष्ट आकार 50 से 200 MB तक होता है। कैश का आकार डिवाइस की स्क्रीन रिज़ॉल्यूशन और देखी गई सामग्री की मात्रा पर निर्भर करता है। Glide दो-स्तरीय कैशिंग का उपयोग करता है: पहले RAM में L1 कैश (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 MB से अधिक होता है, लेकिन भारी उपयोग पर 50 MB तक पहुँच सकता है। OkHttpClient.Builder कंस्ट्रक्टर के माध्यम से अधिकतम कैश आकार कॉन्फ़िगर करें और प्रत्येक ऐप लॉन्च पर कैश किए गए डेटा की वैधता जाँचें।

डेटाबेस और प्रीकंपाइल डेटा कैश

SQLite डेटाबेस संचालन के दौरान अस्थायी फ़ाइलें उत्पन्न कर सकते हैं: WAL फ़ाइलें (Write-Ahead Log), रोलबैक जर्नल और इंडेक्स पेज। ये फ़ाइलें मुख्य डेटाबेस के साथ संग्रहीत होती हैं, लेकिन अस्थायी डेटाबेस (जैसे, पूर्ण-पाठ खोज या एनालिटिक्स) के लिए कैश डायरेक्टरी में स्थान निर्दिष्ट किया जा सकता है। प्रीकंपाइल OpenGL और Vulkan शेडर प्रोग्राम भी इस डायरेक्टरी में कैश किए जाते हैं, जो ग्राफ़िक्स दृश्यों की पहली लोडिंग को गति देता है। iOS पर, NSCachesDirectory को प्रीकंपाइल Core Data और अस्थायी छवि प्रसंस्करण फ़ाइलों के भंडारण के लिए अनुशंसित किया जाता है।

Android और iOS पर कैश सफ़ाई कैसे काम करती है

कैश सफ़ाई स्वचालित रूप से (सिस्टम द्वारा) या मैन्युअल रूप से (उपयोगकर्ता या ऐप द्वारा) हो सकती है। डेटा हानि को रोकने के लिए विभिन्न परिदृश्यों में सिस्टम व्यवहार को समझना आवश्यक है।

सिस्टम द्वारा स्वचालित कैश सफ़ाई

Android पर, सिस्टम कैश सफ़ाई प्रक्रिया तब शुरू करता है जब /data विभाजन पर खाली स्थान एक महत्वपूर्ण सीमा (आमतौर पर 500 MB) से नीचे चला जाता है। 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 के अनुसार, कैश साफ़ करने वाले बटन वाले ऐप्स को इस सुविधा के बिना ऐप्स की तुलना में स्थान की कमी के बारे में 22% कम शिकायतें मिलती हैं। कैश सफ़ाई सुरक्षित होनी चाहिए: ऐप को उस स्थिति को सही ढंग से संभालना चाहिए जब कैश की गई फ़ाइलें हटा दी जाती हैं और अगली पहुँच पर उन्हें पारदर्शी रूप से पुनः लोड करना चाहिए।

Android और iOS पर cacheDir में अंतर

समान उद्देश्य के बावजूद, Android और iOS पर कैश डायरेक्टरी के कार्यान्वयन में महत्वपूर्ण अंतर हैं। डेवलपर को दोनों प्लेटफ़ॉर्म पर सही ऐप संचालन के लिए उन्हें ध्यान में रखना होगा।

Android context.externalCacheDir के माध्यम से एक अलग बाहरी कैश डायरेक्टरी प्रदान करता है — यह SD कार्ड पर स्थित है (यदि स्थापित है) और ऐप अनइंस्टॉल करने पर हटाया नहीं जाता है। यह बड़ी मीडिया फ़ाइलों के लिए सुविधाजनक है, लेकिन मेमोरी कार्ड पर कचरा छोड़ने का जोखिम पैदा करता है। iOS में बाहरी कैश की कोई अवधारणा नहीं है: सभी अस्थायी फ़ाइलें Sandbox कंटेनर के अंदर संग्रहीत होती हैं और अनइंस्टॉल करने पर गारंटीकृत रूप से हटा दी जाती हैं। Android पर, कैश उपयोगकर्ता को ऐप सेटिंग्स में दिखाई देता है और वह इसे मैन्युअल रूप से साफ़ कर सकता है। iOS पर, सिस्टम सेटिंग्स व्यक्तिगत ऐप्स का कैश आकार नहीं दिखाती हैं — उपयोगकर्ता केवल ऐप को हटाकर और पुनः इंस्टॉल करके कैश साफ़ कर सकता है, जब तक कि डेवलपर ने इंटरफ़ेस में साफ़ करने का बटन नहीं जोड़ा हो।

एक महत्वपूर्ण अंतर — पुनर्स्थापना पर व्यवहार है। iOS पर, iTunes या iCloud बैकअप से पुनर्स्थापित करते समय, Caches डायरेक्टरी पुनर्स्थापित नहीं होती है, क्योंकि iOS मानता है कि कैश किया गया डेटा पहले लॉन्च पर पुनः बनाया जाएगा। Android पर, Google Drive से पुनर्स्थापित करते समय, केवल Internal Storage का बैकअप लिया जाता है — पुनर्स्थापना के बाद कैश खाली रहता है। दोनों मामलों में, ऐप को खाली कैश के साथ सही ढंग से काम करना चाहिए, उपयोगकर्ता को त्रुटियाँ दिखाए बिना या कार्यक्षमता खोए बिना।

कैश प्रबंधन के लिए सिफ़ारिशें

उचित कैश प्रबंधन उपयोगकर्ता अनुभव और ऐप रेटिंग को प्रभावित करने वाले कारकों में से एक है। निम्नलिखित सिफ़ारिशें सामान्य समस्याओं से बचने और उपयोगकर्ता संतुष्टि बढ़ाने में मदद करेंगी।

• कैश आकार की सीमा निर्धारित करें। अधिकतम आकार मेगाबाइट में निर्दिष्ट करते हुए DiskLruCache या समान लाइब्रेरी का उपयोग करें। सीमा पार होने पर, लाइब्रेरी स्वचालित रूप से सबसे कम उपयोग की गई फ़ाइलों को हटा देती है
• कैश साफ़ करने का बटन लागू करें ऐप सेटिंग्स में। वर्तमान कैश आकार (“12.5 MB” प्रारूप में) दिखाएँ और सफ़ाई से पहले पुष्टि माँगें। सफ़ाई के बाद, प्रदर्शित आकार अपडेट करें
• कैश में वे फ़ाइलें न रखें जिन्हें पुनर्प्राप्त नहीं किया जा सकता। यदि डेटा ऐप संचालन के लिए महत्वपूर्ण है, तो उन्हें Internal Storage (Android) या Documents (iOS) में संग्रहीत करें, और त्वरित पहुँच के लिए केवल एक प्रति कैश में रखें
• लिखने से पहले बाहरी कैश की उपलब्धता जाँचें। Android पर, context.externalCacheDir null लौटा सकता है यदि SD कार्ड स्थापित नहीं है या उपलब्ध नहीं है। हमेशा आंतरिक कैश का फ़ॉलबैक प्रदान करें
• कैश किए गए डेटा के लिए TTL नीति का उपयोग करें। फ़ाइलों को आवश्यकता से अधिक समय तक न रखें: छवियों के लिए — 24–48 घंटे, API प्रतिक्रियाओं के लिए — डेटा अद्यतन आवृत्ति के आधार पर 5 मिनट से 1 घंटे तक

ऐप एनालिटिक्स में कैश आकार की नियमित रूप से निगरानी करें। Firebase Analytics या समान सिस्टम में कैश आकार मीट्रिक रिपोर्टिंग को एकीकृत करें। यदि औसत कैश आकार 100 MB से अधिक है, तो कैशिंग रणनीति को अनुकूलित करें: शायद ही कभी उपयोग किए जाने वाले डेटा के लिए TTL कम करें, कैशिंग से पहले छवि संपीड़न लागू करें (PNG के बजाय WebP, JPEG गुणवत्ता 85% तक कम करें), सर्वर से सामग्री लोड करने के लिए पेजिनेशन का उपयोग करें। याद रखें कि 16–32 GB वाले डिवाइस वाले उपयोगकर्ता ऐप आकार के प्रति विशेष रूप से संवेदनशील होते हैं: जब कैश 200 MB तक पहुँचता है, तो कई उपयोगकर्ता इसे साफ़ करने का तरीका खोजने लगते हैं या बस ऐप हटा देते हैं। Google सर्वेक्षण के अनुसार, 38% उपयोगकर्ताओं ने अनियंत्रित कैश वृद्धि और स्थान खपत के कारण कम से कम एक ऐप हटाया है।