অ্যাপ ক্যাশ ডিরেক্টরি — এটি কী, উদ্দেশ্য এবং মোবাইল ডেভেলপমেন্টে কীভাবে সাফ করবেন

অ্যাপ ক্যাশ ডিরেক্টরি কী?

ক্যাশ ডিরেক্টরি হল অ্যাপ্লিকেশনের অভ্যন্তরীণ (বা বাহ্যিক) মেমরির একটি বিশেষ ডিরেক্টরি যা অস্থায়ী ফাইলগুলির জন্য ডিজাইন করা হয়েছে। 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 কার্ড ইনস্টল না থাকে বা উপলব্ধ না হয়। সর্বদা অভ্যন্তরীণ ক্যাশের ফallback প্রদান করুন
• ক্যাশ করা ডেটার জন্য TTL নীতি ব্যবহার করুন। প্রয়োজনীয়তার চেয়ে বেশি সময় ফাইল রাখবেন না: ছবির জন্য — 24–48 ঘন্টা, API প্রতিক্রিয়ার জন্য — ডেটা আপডেট ফ্রিকোয়েন্সির উপর নির্ভর করে 5 মিনিট থেকে 1 ঘন্টা

অ্যাপ অ্যানালিটিক্সে ক্যাশ আকার নিয়মিত পর্যবেক্ষণ করুন। Firebase Analytics বা অনুরূপ সিস্টেমে ক্যাশ আকার মেট্রিক রিপোর্টিং একীভূত করুন। যদি গড় ক্যাশ আকার 100 MB অতিক্রম করে, ক্যাশিং কৌশল অপ্টিমাইজ করুন: খুব কমই ব্যবহৃত ডেটার জন্য TTL হ্রাস করুন, ক্যাশ করার আগে ছবি কম্প্রেশন প্রয়োগ করুন (PNG-এর পরিবর্তে WebP, JPEG গুণমান 85% এ কমিয়ে দিন), সার্ভার থেকে কন্টেন্ট লোড করার জন্য পেজিনেশন ব্যবহার করুন। মনে রাখবেন যে 16–32 GB ডিভাইসের ব্যবহারকারীরা অ্যাপের আকারের প্রতি বিশেষভাবে সংবেদনশীল: যখন ক্যাশ 200 MB-এ পৌঁছায়, অনেক ব্যবহারকারী এটি সাফ করার উপায় খুঁজতে শুরু করেন বা কেবল অ্যাপ মুছে ফেলেন। Google জরিপ অনুসারে, 38% ব্যবহারকারী অনিয়ন্ত্রিত ক্যাশ বৃদ্ধি এবং স্থান খরচের কারণে অন্তত একটি অ্যাপ মুছে ফেলেছেন।