Caches Directory হলো iOS অ্যাপ্লিকেশনের স্যান্ডবক্সের মধ্যে একটি ডিরেক্টরি যা অস্থায়ী ডেটা সংরক্ষণের জন্য ডিজাইন করা হয়েছে যা নেটওয়ার্ক থেকে পুনরুদ্ধার বা পুনরায় লোড করা যেতে পারে। Apple File System Basics (2024) অনুসারে, ডিস্কে জায়গা খালি করতে সিস্টেম যে কোনো সময় Caches Directory থেকে ফাইল মুছে ফেলতে পারে — অ্যাপ্লিকেশনকে এই ফাইলগুলোর অনুপস্থিতি সঠিকভাবে সামলাতে হবে এবং প্রয়োজনে সেগুলো পুনরুদ্ধার করতে হবে। Documents Directory-এর বিপরীতে, Caches-এর ডেটা iCloud এবং iTunes ব্যাকআপে অন্তর্ভুক্ত হয় না, যা ব্যবহারকারীর ক্লাউড স্টোরেজের উপর চাপ কমায়।
মূল পয়েন্ট
Caches Directory হলো iOS অ্যাপ্লিকেশন স্যান্ডবক্সের ভিতরে একটি ডিরেক্টরি যা প্রয়োজনে পুনরুদ্ধার করা যেতে পারে এমন ডেটা সংরক্ষণের জন্য অপ্টিমাইজ করা। Documents Directory-এর বিপরীতে, Caches ব্যবহারকারীর ডেটার জন্য নয় — এটি অ্যাপ্লিকেশনের কর্মক্ষমতা দ্রুত করার জন্য অস্থায়ী স্টোরেজ।
iOS ক্যাশে করা নেটওয়ার্ক প্রতিক্রিয়া, প্রিলোডেড ছবি, সিরিয়ালাইজড অবজেক্ট এবং অ্যাপ্লিকেশন পুনরুদ্ধার করতে পারে এমন ডেটা সংরক্ষণের জন্য Caches Directory ব্যবহার করে। ডেভেলপারদের এই ডিরেক্টরিতে দীর্ঘমেয়াদী ডেটা স্টোরেজের উপর নির্ভর করা উচিত নয়।
Apple WWDC 2020 অনুসারে, প্রায় 40% iOS অ্যাপ্লিকেশন ক্যাশে করা ছবি এবং নেটওয়ার্ক ডেটা সংরক্ষণের জন্য Caches Directory ব্যবহার করে, যখন 25% ডেভেলপার এই ডিরেক্টরিগুলোর মধ্যে পার্থক্য না বোঝার কারণে Caches-এ ভুলভাবে ডেটা রাখে যা Documents বা Application Support-এ থাকা উচিত।
Caches-এর একটি গুরুত্বপূর্ণ বৈশিষ্ট্য: অ্যাপ্লিকেশনকে সেই পরিস্থিতিগুলো সঠিকভাবে সামলাতে হবে যখন সিস্টেম দ্বারা একটি ক্যাশ ফাইল মুছে ফেলা হয়েছে। যদি ক্যাশ মুছে ফেলার ফলে অ্যাপ্লিকেশনের কার্যকারিতা নষ্ট হয়, তাহলে ডেটা ভুল ডিরেক্টরিতে সংরক্ষণ করা হয়েছে।
Swift-এ, Caches Directory-তে পাথ .cachesDirectory সহ স্ট্যান্ডার্ড FileManager পদ্ধতি ব্যবহার করে পাওয়া যায়। এটি একটি সাধারণ অপারেশন যা নেটওয়ার্ক ডেটার সাথে কাজ করে এমন প্রায় প্রতিটি iOS অ্যাপ্লিকেশনে ব্যবহৃত হয়।
import Foundation
let fileManager = FileManager.default
guard let cachesURL = fileManager.urls(
for: .cachesDirectory,
in: .userDomainMask
).first else { return }
// Save cached JSON
let cacheFile = cachesURL.appendingPathComponent("feed_cache.json")
let jsonData = try JSONSerialization.data(
withJSONObject: response,
options: [.prettyPrinted]
)
try jsonData.write(to: cacheFile)
Objective-C, NSCachesDirectory-এর সাথে NSSearchPathForDirectoriesInDomains ব্যবহার করে। যদিও Apple Swift API সুপারিশ করে, Caches Directory-এর সাথে Objective-C কোড কার্যকর এবং সমর্থিত থাকে।
@import Foundation;
NSArray *paths = NSSearchPathForDirectoriesInDomains(
NSCachesDirectory,
NSUserDomainMask,
YES
);
NSString *cachesPath = paths.firstObject;
NSString *cacheFile = [cachesPath stringByAppendingPathComponent:@"feed_cache.plist"];
Swift প্রজেক্টের URL-ভিত্তিক API পছন্দ করা উচিত: এটি টাইপ-সেফ এবং SwiftUI এবং Combine-এর মতো আধুনিক ফ্রেমওয়ার্কের সাথে আরও ভালোভাবে একীভূত হয়।
Caches Directory ডেটার বেশ কয়েকটি বিভাগের জন্য সর্বোত্তম যা অ্যাপ্লিকেশন কর্মক্ষমতা দ্রুত করতে ব্যবহার করে, কিন্তু এটি সত্যের একমাত্র উৎস নয়। ক্যাশিংয়ের জন্য সঠিক ডেটা নির্বাচন সরাসরি UX এবং অ্যাপ্লিকেশনের কর্মক্ষমতা প্রভাবিত করে।
API থেকে JSON প্রতিক্রিয়া, নিউজ ফিড ডেটা, অবজেক্ট তালিকা — সবকিছু যা অ্যাপ্লিকেশন সার্ভার থেকে পুনরায় ডাউনলোড করতে পারে। HTTP প্রতিক্রিয়ার স্বয়ংক্রিয় ক্যাশিংয়ের জন্য URLCache ব্যবহার করুন অথবা সিরিয়ালাইজড অবজেক্ট ম্যানুয়ালি সংরক্ষণ করুন।
নেটওয়ার্ক থেকে ডাউনলোড করা ছবি Caches Directory-র সবচেয়ে সাধারণ ব্যবহার। SDWebImage এবং Kingfisher-এর মতো লাইব্রেরি ডিফল্টভাবে ক্যাশে করা ছবি Caches-এ সংরক্ষণ করে।
| ডেটার ধরন | Caches-এর জন্য উপযুক্ত | সংরক্ষণকাল |
|---|---|---|
| JSON API প্রতিক্রিয়া | হ্যাঁ | সিস্টেম পরিষ্কার পর্যন্ত |
| নেটওয়ার্ক থেকে ছবি | হ্যাঁ | সিস্টেম পরিষ্কার পর্যন্ত |
| ডিবাগ লগ | শর্তসাপেক্ষ | tmp-এ ভালো |
| গেম সেভ | না | শুধু Documents |
| অ্যাপ কনফিগারেশন | না | Application Support |
যদি ডেটা পুনরুদ্ধার করা না যায়, তাহলে তার স্থান Caches-এ নয়। এটি সবচেয়ে সহজ মানদণ্ড: কল্পনা করুন যে আগামীকাল সিস্টেম Caches থেকে সব ফাইল মুছে ফেলবে। যদি অ্যাপ্লিকেশন সঠিকভাবে কাজ চালিয়ে যায়, তাহলে ডেটা সঠিকভাবে সংরক্ষণ করা হয়েছে।
iOS স্বয়ংক্রিয়ভাবে Caches Directory পরিষ্কার পরিচালনা করে, কিন্তু সঠিক ট্রিগার এবং অ্যালগরিদম Apple দ্বারা নথিভুক্ত নয়। এটি জানা যায় যে সিস্টেম ডিস্কে জায়গার অভাব হলে, পাশাপাশি Offload Unused Apps বৈশিষ্ট্য সক্রিয় থাকলে Caches থেকে ফাইল মুছে ফেলতে পারে।
পরিষ্কার প্রক্রিয়া অ্যাপ্লিকেশনের জন্য স্বচ্ছ: সিস্টেম বিজ্ঞপ্তি ছাড়াই ফাইল মুছে ফেলে। অ্যাপ্লিকেশনকে পড়ার আগে ফাইলের অস্তিত্ব পরীক্ষা করতে হবে এবং অনুপস্থিত থাকলে পুনরায় তৈরি করতে হবে। Caches-এর সাথে কাজ করার সময় দীর্ঘমেয়াদী স্টোরেজের উপর নির্ভর না করা একটি মূল প্রয়োজন।
Apple-এর নিবন্ধ “File System Basics” (2024) অনুসারে, অ্যাপ্লিকেশন আশা করা উচিত নয় যে Caches Directory-তে ফাইল সেশনের মধ্যে উপলব্ধ থাকবে। ডেভেলপারদের একটি ফলব্যাক ব্যবস্থা বাস্তবায়ন করার পরামর্শ দেওয়া হচ্ছে: যদি ক্যাশে করা ফাইল অনুপস্থিত থাকে, তাহলে নেটওয়ার্ক থেকে ডেটা ডাউনলোড করুন এবং আবার Caches-এ সংরক্ষণ করুন।
একটি পৃথক পরিস্থিতি হলো অ্যাপ অফলোড (Offload)। যখন এই বৈশিষ্ট্য সক্রিয় হয়, iOS অ্যাপ্লিকেশন সরিয়ে ফেলে কিন্তু তার Documents Directory রেখে দেয়। Caches Directory এই প্রক্রিয়ায় মুছে ফেলা হয়। যে ব্যবহারকারী অ্যাপ্লিকেশন পুনরুদ্ধার করেন তিনি ক্যাশে করা ডেটা পাবেন না — অ্যাপ্লিকেশনকে এটি পুনরায় ডাউনলোড করতে হবে।
Caches এবং Temporary (tmp) ডিরেক্টরির মধ্যে পার্থক্য প্রায়ই ডেভেলপারদের মধ্যে বিভ্রান্তি সৃষ্টি করে। উভয় ডিরেক্টরি অস্থায়ী ডেটা সংরক্ষণ করে, কিন্তু ভিন্ন জীবনকালের গ্যারান্টি এবং উদ্দেশ্য সহ।
| বৈশিষ্ট্য | Caches Directory | Temporary Directory |
|---|---|---|
| জীবনকাল | সেশন থেকে সেশন (গ্যারান্টি নয়) | শুধু সেশনের মধ্যে |
| সিস্টেম পরিষ্কার | জায়গার অভাব হলে | সেশন শেষ বা রিবুটে |
| উদ্দেশ্য | কর্মক্ষমতা দ্রুত করার জন্য ক্যাশ | খুব অস্থায়ী ডেটা |
| উদাহরণ | ক্যাশে করা ছবি | এক্সপোর্টের আগে অস্থায়ী ফাইল |
| ব্যাকআপ | না | না |
Caches বেছে নিন যদি অ্যাপ্লিকেশন লঞ্চের মধ্যে ডেটা রাখা উপকারী হয় কিন্তু পুনরুদ্ধার করা যেতে পারে। tmp ব্যবহার করুন যদি ডেটা শুধু বর্তমান সেশনে প্রয়োজন এবং অ্যাপ্লিকেশন শেষ হওয়ার পরে এর কোনো মূল্য না থাকে।
Caches Directory-এর সাথে কাজ করার জন্য বেশ কয়েকটি নিয়ম অনুসরণ করা প্রয়োজন যা ডেটা হারানো, অপ্রত্যাশিত অ্যাপ্লিকেশন আচরণ এবং কর্মক্ষমতা সমস্যা এড়াতে সাহায্য করে।
FileManager.fileExists(atPath:) Caches থেকে প্রতিটি পড়ার আগে কল করা উচিত। যদি ফাইল অনুপস্থিত থাকে, তাহলে মূল উৎস থেকে ডেটা লোড করুন এবং ক্যাশে সংরক্ষণ করুন। কখনই ধরে নেবেন না যে Caches-এ একটি ফাইল বিদ্যমান।
আপনার অ্যাপ্লিকেশনে Caches Directory-র জন্য সর্বোচ্চ আকার নির্ধারণ করুন। উদাহরণস্বরূপ, ছবির জন্য 50 MB এবং JSON প্রতিক্রিয়ার জন্য 10 MB-এর সীমা। সীমা অতিক্রম করলে, পরিবর্তনের তারিখ অনুসারে সবচেয়ে পুরনো ফাইল মুছে ফেলুন।
import Foundation
func trimCache(to maxSizeBytes: Int) {
let cachesURL = FileManager.default
.urls(for: .cachesDirectory, in: .userDomainMask)
.first!
guard let enumerator = FileManager.default
.enumerator(
at: cachesURL,
includingPropertiesForKeys: [.fileSizeKey, .contentModificationDateKey]
)
else { return }
// Enumerate and remove old files
// when exceeding size limit
}
এই অনুশীলনগুলি অনুসরণ করা নিশ্চিত করে যে অ্যাপ্লিকেশন সিস্টেম ক্যাশ পরিষ্কার করার ক্রিয়া নির্বিশেষে সঠিকভাবে কাজ করে, এবং ব্যবহারকারীরা অপ্রত্যাশিত ডেটা হানির সম্মুখীন হন না।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
না, iOS Caches থেকে ফাইল মুছে ফেলার আগে কোনো বিজ্ঞপ্তি পাঠায় না। পরিষ্কার প্রক্রিয়া অ্যাপ্লিকেশনের জন্য সম্পূর্ণ স্বচ্ছ। মুছে ফেলার বিষয়টি জানার একমাত্র উপায় হলো ফাইল পড়ার চেষ্টা করা — FileManager nil ফেরত দেয় বা ত্রুটি নিক্ষেপ করে, এবং অ্যাপ্লিকেশনকে এই পরিস্থিতি সামলাতে হবে।
ব্যবহারকারীদের Files বা iTunes-এর মাধ্যমে Caches Directory-তে সরাসরি প্রবেশাধিকার নেই। তবে, তারা Settings > General > Storage-এর মাধ্যমে সব অ্যাপ্লিকেশনের ক্যাশ পরিষ্কার করতে পারেন, একটি নির্দিষ্ট অ্যাপ্লিকেশন নির্বাচন করে “Offload App” টিপে। iOS জায়গার অভাব হলে স্বয়ংক্রিয়ভাবে ক্যাশ পরিষ্কার করতে পারে।
URLCache হলো Foundation থেকে HTTP অনুরোধ ক্যাশিংয়ের একটি অন্তর্নির্মিত প্রক্রিয়া। এটি স্বয়ংক্রিয়ভাবে ক্যাশে করা প্রতিক্রিয়া সংরক্ষণ এবং লোড করে, অভ্যন্তরীণভাবে Caches Directory ব্যবহার করে। ম্যানুয়াল সংরক্ষণ আরও নিয়ন্ত্রণ দেয়: আপনি ফরম্যাট বেছে নিতে, ডেটা এনক্রিপ্ট করতে এবং প্রতিটি ফাইলের জীবনকাল পৃথকভাবে পরিচালনা করতে পারেন।
App Store-এর মাধ্যমে অ্যাপ্লিকেশন আপডেট করলে, Caches Directory সংরক্ষিত থাকে। তবে, নতুন আপডেট ইনস্টলেশনের জন্য বেশি জায়গা প্রয়োজন হলে সিস্টেম বিষয়বস্তু মুছে ফেলতে পারে। আপডেটের পরে Caches-এর স্থায়িত্বের উপর ডেভেলপারের নির্ভর করা উচিত নয় — এটি ফলব্যাক প্রক্রিয়া বাস্তবায়নের একটি অতিরিক্ত কারণ।
একটি নির্দিষ্ট NSURLSession সেশনের জন্য URLCache nil-এ সেট করুন অথবা .reloadIgnoringLocalCacheData ক্যাশিং নীতি ব্যবহার করুন। আপনি খালি ক্যাশ সহ URLSessionConfiguration-ও তৈরি করতে পারেন: sessionConfiguration.urlCache = nil। এটি সেই ডেটার জন্য উপযোগী যা সর্বদা আপ-টু-ডেট থাকা উচিত।
সারসংক্ষেপ
আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব
IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন