মৌলিক ধারনা

অ্যান্ড্রয়েডে মেমরি ব্যবহার বুঝতে হলে, আপনাকে উচ্চ-স্তরের জাভা অবজেক্ট থেকে শুরু করে নিম্ন-স্তরের কার্নেল পেজ পর্যন্ত বিভিন্ন দৃষ্টিকোণ থেকে সিস্টেমটিকে দেখতে হবে।

পারফরম্যান্সের খাদ

মেমোরির ব্যবহার নিজে থেকে ভালো বা খারাপ কোনো বিষয় নয়; আসল বিষয় হলো আপনি মেমোরিটি কীসের জন্য ব্যবহার করছেন। তবে, যখন আপনি কোনো ডিভাইসের উপলব্ধ মেমোরির সীমার কাছাকাছি পৌঁছান, তখন আপনার পারফরম্যান্স হঠাৎ করেই তলানিতে গিয়ে ঠেকে।

যখন আপনি চূড়ান্ত সীমা থেকে অনেক দূরে থাকেন, তখন সামান্য পরিমাণে মেমরি ব্যবহার (যেমন, ৫০ মেগাবাইট) বাড়ালেও পারফরম্যান্সে তেমন কোনো লক্ষণীয় প্রভাব নাও পড়তে পারে। তবে, যখন উপলব্ধ র‍্যাম শেষ হয়ে যায়, তখনই চূড়ান্ত সীমায় পৌঁছানো যায়। এই পর্যায়ে, জায়গা খালি করার জন্য অপারেটিং সিস্টেমকে মেমরি পেজিং আউট করা এবং প্রসেস বন্ধ করা শুরু করতে হয়। এই চূড়ান্ত সীমা অতিক্রম করলে, মেমরি ব্যবহারে সামান্য বৃদ্ধিও মারাত্মক "থ্র্যাশিং"-এর কারণ হতে পারে, যেখানে গুরুত্বপূর্ণ প্রসেসগুলো বন্ধ হয়ে যাওয়ার কারণে ডিভাইসটি সাড়া দেওয়া বন্ধ করে দেয় বা রিবুট হয়ে যায় বলে মনে হয়।

অ্যান্ড্রয়েড স্ট্যাক

অ্যান্ড্রয়েড স্ট্যাকের প্রতিটি স্তরের মেমরি সম্পর্কে নিজস্ব স্বতন্ত্র ধারণা রয়েছে:

1. অ্যাপ্লিকেশন (জাভা/কটলিন) : ডেভেলপাররা প্রধানত জাভা হিপে বরাদ্দকৃত জাভা অবজেক্টগুলো দেখতে পান।
2. অ্যান্ড্রয়েড রানটাইম (ART) : ART কার্নেলের ভার্চুয়াল মেমরি পেজ ব্যবহার করে জাভা/কটলিন হিপ পরিচালনা করে। পূর্বে এটি ডালভিক (Dalvik) নামে পরিচিত ছিল (শব্দ দুটি কখনও কখনও একে অপরের পরিবর্তে ব্যবহৃত হয়)।
3. লিনাক্স কার্নেল : কার্নেল মেমরিকে ফিজিক্যাল এবং ভার্চুয়াল পেজের পরিপ্রেক্ষিতে দেখে। ঐতিহ্যগতভাবে, এগুলি ৪ কিলোবাইট (KB) হয়, কিন্তু অ্যান্ড্রয়েড ১৬ কিলোবাইট পেজ সাইজও সমর্থন করে। কার্নেল 'জাভা অবজেক্ট' সম্পর্কে কিছুই জানে না।

আপনি যদি মেমরি অপ্টিমাইজ করতে চান, তবে আপনাকে হয় আপনার নিজের লেয়ারের মধ্যেই অপ্টিমাইজ করতে হবে (যেমন, কম বিটম্যাপ লোড করে) অথবা আপনার উচ্চ-স্তরের অ্যালোকেশনগুলো কীভাবে বাস্তব পেজ ব্যবহারে রূপান্তরিত হয় তা বোঝার জন্য আপনার নিচের লেয়ারগুলো বুঝতে হবে।

মেমরির প্রকারভেদ: অ্যানোনিমাস বনাম ফাইল-ব্যাকড

অপারেটিং সিস্টেম কীভাবে মেমরি পুনরুদ্ধার করে, সেই বিষয়ে বিস্তারিত জানার আগে আপনাকে লিনাক্সের মেমরি পেজের দুটি মৌলিক বিভাগ সম্পর্কে বুঝতে হবে:

1. অ্যানোনিমাস মেমরি ( anon ) : এমন মেমরি যা স্টোরেজে কোনো ফাইল দ্বারা সমর্থিত নয় । এর মধ্যে অন্তর্ভুক্ত রয়েছে C/C++ malloc (যেমন Scudo allocator) দ্বারা বরাদ্দকৃত মেমরি এবং Java/Kotlin হিপে Java অবজেক্টের জন্য বরাদ্দকৃত মেমরি। যেহেতু এই মেমরিতে ফিরে যাওয়ার জন্য কোনো সোর্স ফাইল নেই, তাই OS-কে হয় এটিকে RAM-এ রাখতে হয় অথবা চাপের মুখে এটিকে কম্প্রেস করে ZRAM-এ সোয়াপ আউট করতে হয়।
2. ফাইল-সমর্থিত মেমরি ( file ) : যে মেমরি স্টোরেজের কোনো ফাইল থেকে সরাসরি ম্যাপ করা হয়। এর মধ্যে এক্সিকিউটেবল কোড (DEX ফাইল, .so নেটিভ লাইব্রেরি) এবং ফন্ট অন্তর্ভুক্ত।

দ্রষ্টব্য: অ্যান্ড্রয়েড প্রচলিত ডিস্ক সোয়াপ স্পেস ব্যবহার করে না। এর পরিবর্তে, এটি র‍্যামের মধ্যে থাকা একটি সংকুচিত মেমরি ব্লক, ZRAM ব্যবহার করে।

মেমরি ম্যাপড ফাইল (mmap)

অ্যান্ড্রয়েড ফাইল-ব্যাকড এবং অ্যানোনিমাস উভয় মেমরিকে একটি প্রসেসের অ্যাড্রেস স্পেসে ম্যাপ করার জন্য mmap ব্যবহার করে।

ফাইল-সমর্থিত মেমরির ক্ষেত্রে, পেজগুলিকে আরও শ্রেণীবদ্ধ করা হয়:

• ক্লিন মেমোরি : ফাইল থেকে ম্যাপ করা এমন পেজ যা পরিবর্তিত হয়নি। সিস্টেমের আরও মেমোরির প্রয়োজন হলে, কার্নেল সহজেই এই পেজগুলো বাদ দিয়ে দিতে পারে, কারণ পরবর্তীতে স্টোরেজে থাকা ফাইল থেকে এগুলো সরাসরি পুনরায় লোড করা যায়।
• ডার্টি মেমোরি (Dirty Memory) : প্রসেস দ্বারা পরিবর্তিত পেজসমূহ। এগুলো ড্রপ করা যায় না; এগুলো অ্যানোনিমাস মেমোরির (anonymous memory) মতো আচরণ করে এবং অবশ্যই র‍্যামে (RAM) রাখতে হবে অথবা জেডর‍্যামে (ZRAM) স্থানান্তর করতে হবে।

অ্যান্ড্রয়েড এমন ফাইল ফরম্যাট (যেমন DEX) পছন্দ করে যা মেমরি ম্যাপিংয়ের জন্য উপযুক্ত, যার ফলে সিস্টেম চাপের মুখে সহজেই পরিষ্কার মেমরি পুনরুদ্ধার করতে পারে। যেহেতু অ্যানোনিমাস এবং ডার্টি মেমরি সহজে বাদ দেওয়া যায় না, তাই উচ্চ প্রাইভেট ডার্টি/অ্যানন মেমরিই সিস্টেম থ্র্যাশিং এবং লো মেমরি কিলার (LMK) হস্তক্ষেপের প্রধান কারণ। যদি আপনার অ্যাপ্লিকেশন প্রচুর পরিমাণে প্রাইভেট ডার্টি মেমরি ব্যবহার করে, তবে আপনি সরাসরি পারফরম্যান্সের আকস্মিক অবনতিতে অবদান রাখছেন।

জাইগোট প্রক্রিয়া মডেল

অ্যান্ড্রয়েড জাইগোট (Zygote) নামক একটি প্রক্রিয়া ব্যবহার করে নতুন অ্যাপ্লিকেশন চালু করার খরচ কমিয়ে আনে।

1. জাইগোট বুট করার সময় চালু হয় এবং সাধারণ ফ্রেমওয়ার্ক ক্লাস ও রিসোর্সসমূহকে তার মেমরিতে আগে থেকেই লোড করে নেয়। কার্নেলের দৃষ্টিকোণ থেকে, এটি একটি বেনামী ডার্টি মেমরি (anonymous dirty memory) হয়ে ওঠে, কিন্তু এটি শুধুমাত্র জাইগোট প্রসেসের জন্যই স্বতন্ত্র।
2. যখন কোনো নতুন অ্যাপ্লিকেশন চালু হয়, তখন সিস্টেম জাইগোট প্রসেসটি ফোর্ক করে ।
3. নতুন চাইল্ড প্রসেসটি কপি-অন-রাইট (COW) সিম্যান্টিকস সহ একটি শেয়ার্ড ম্যাপিং ব্যবহার করে জাইগোটের মেমরি উত্তরাধিকার সূত্রে লাভ করে।

যতক্ষণ পর্যন্ত চাইল্ড প্রসেসটি শুধুমাত্র জাইগোট (Zygote) থেকে উত্তরাধিকারসূত্রে প্রাপ্ত মেমরি পড়ে, ততক্ষণ পর্যন্ত ফিজিক্যাল মেমরি পেজগুলো সমস্ত প্রসেসের মধ্যে শেয়ার করা থাকে। যখন একটি চাইল্ড প্রসেস কোনো শেয়ার করা পেজ পরিবর্তন করে, তখন কার্নেল স্বচ্ছভাবে প্রসেসটির জন্য সেই পেজটির একটি প্রাইভেট কপি তৈরি করে। এই মডেলটি অনেক প্রসেসকে তাদের মেমরির একটি বড় অংশ—বিশেষ করে ফ্রেমওয়ার্ক কোড এবং রিসোর্স—শেয়ার করার সুযোগ দেয়, যা সিস্টেমের সামগ্রিক মেমরি ফুটপ্রিন্ট উল্লেখযোগ্যভাবে হ্রাস করে।

আরএসএস, পিএসএস এবং ইউএসএস

যেহেতু প্রসেসগুলোর মধ্যে মেমরি ব্যাপকভাবে ভাগ করা হয়—প্রধানত জাইগোট মডেলের মাধ্যমে—তাই একটি প্রসেসের মেমরি ব্যবহারের হিসাব রাখার তিনটি প্রধান উপায় রয়েছে:

• আরএসএস (রেসিডেন্ট সেট সাইজ) : প্রসেসটির র‍্যামে থাকা মোট পেজের সংখ্যা। এটি ব্যবহারের পরিমাণকে বাড়িয়ে দেখায়, কারণ এটি শেয়ার করা পেজগুলোকে একাধিকবার গণনা করে (যে প্রতিটি প্রসেস সেগুলো শেয়ার করে, তার জন্য একবার করে)।
• PSS (প্রোপোরশনাল সেট সাইজ) : কোনো প্রসেসের নিজস্ব মেমোরির মোট পরিমাণ, এবং এর সাথে শেয়ার্ড মেমোরিতে থাকা তার আনুপাতিক অংশ। যদি একটি পেজ ৫টি প্রসেস দ্বারা শেয়ার করা হয়, তবে প্রতিটি প্রসেসকে সেই পেজের ১/৫ অংশের জন্য চার্জ করা হয়।
• ইউএসএস (ইউনিক সেট সাইজ) : প্রসেসটির জন্য নির্দিষ্ট মেমরির পরিমাণ। প্রসেসটি বন্ধ করে দিলে এই মেমরিটুকু সিস্টেমে ফেরত দেওয়া হবে।

দ্রষ্টব্য: এই মেট্রিকগুলোর (RSS, PSS, বা USS) কোনোটিতেই সেইসব পেজ অন্তর্ভুক্ত নয় যেগুলো কম্প্রেস করে ZRAM-এ সোয়াপ করা হয়েছে, অথবা যেগুলো কার্নেল দ্বারা রিক্লেইম করা হয়েছে। অ্যান্ড্রয়েডে মেমরি ব্যবহারের মেট্রিকগুলো সাধারণত শুধু রেসিডেন্ট মেমরিকেই নির্দেশ করে।

কখন কোন মেট্রিক ব্যবহার করতে হবে?

সঠিক স্মৃতি পরিমাপক নির্বাচন করা নির্ভর করে আপনি কী পরিমাপ করতে চাইছেন এবং কোন পরিবেশে তা পরিমাপ করছেন তার উপর।

মেট্রিক	সেরা	মূল শক্তি	প্রধান অসুবিধা
পিএসএস	সিস্টেম-ব্যাপী মেমরি স্ন্যাপশট	শেয়ার্ড মেমোরির সঠিক অনুপাত নির্ধারণ করে। PSS-এর যোগফল মোট ব্যবহৃত মেমোরির সমান।	অন্যান্য চলমান প্রসেসের উপর ভিত্তি করে এটি ওঠানামা করে। সময়ের সাথে সাথে কোনো নির্দিষ্ট অ্যাপের তুলনা করার জন্য এটি ভালো নয়।
আরএসএস	সময়ের সাথে সাথে একটি নির্দিষ্ট অ্যাপ ট্র্যাক করা, ফিল্ড টেলিমেট্রি	স্থিতিশীল, অন্যান্য প্রক্রিয়ার উপর নির্ভরশীল নয়। দ্রুত এবং সস্তায় সংগ্রহ করা যায়।	মোট ব্যবহারের পরিমাণকে বাড়িয়ে দেখায়, কারণ এটি শেয়ার্ড মেমরিকে একাধিকবার গণনা করে।
ইউএসএস	একটি প্রক্রিয়া বন্ধ করার প্রভাব মূল্যায়ন করা	অ্যাপটি বন্ধ করে দিলে ঠিক কী পরিমাণ মেমরি খালি হবে তা দেখায়।	শেয়ার্ড মেমোরি সম্পূর্ণরূপে উপেক্ষা করে।

পিএসএস (আনুপাতিক সেট আকার)

• এর জন্য সর্বোত্তম: একটি নির্দিষ্ট সময়ে কোনো নির্দিষ্ট ডিভাইসের সম্পূর্ণ সিস্টেম মেমরির স্ন্যাপশট নেওয়া।
• কারণ: PSS-এর একটি দরকারি গাণিতিক বৈশিষ্ট্য হলো, সিস্টেমে চলমান সমস্ত প্রসেসের PSS-এর যোগফল প্রসেসগুলো দ্বারা ব্যবহৃত মোট মেমরির সমান হয়। এটি দ্বৈত গণনা ছাড়াই শেয়ার্ড মেমরিকে নিখুঁতভাবে বন্টন করে।
• কখন পরিহার করবেন: দুটি ভিন্ন স্ন্যাপশট, ভিন্ন ভিন্ন সময় বা ভিন্ন ভিন্ন ডিভাইসের মধ্যে একটি নির্দিষ্ট প্রসেস তুলনা করার জন্য আপনার PSS ব্যবহার করা উচিত নয়। যেহেতু PSS নির্ভর করে বর্তমানে অন্য কতগুলো প্রসেস আপনার প্রসেসের সাথে পেজ শেয়ার করছে তার উপর, তাই আপনার অ্যাপের প্রকৃত আচরণ সম্পূর্ণ অপরিবর্তিত থাকলেও এর PSS ওঠানামা করতে পারে।

আরএসএস (রেসিডেন্ট সেট সাইজ)

• এর জন্য সর্বোত্তম: সময়ের সাথে সাথে, বিভিন্ন ক্রিটিক্যাল ইউজার জার্নি (CUJ) জুড়ে কোনো একটি অ্যাপের মেমরি ব্যবহার ট্র্যাক করতে, অথবা অ্যাপের বিভিন্ন ভার্সনের মধ্যে তুলনা করতে। ফিল্ড টেলিমেট্রির জন্যও এটি সবচেয়ে বাস্তবসম্মত পছন্দ।
• কারণ: PSS-এর চেয়ে RSS বেশি স্থিতিশীল। অন্যান্য অ্যাপ কী করছে তা নির্বিশেষে, এটি আপনার প্রসেসে ম্যাপ করা মেমরি সম্পর্কে তথ্য দেয়। তাছাড়া, RSS সংগ্রহ করা সাশ্রয়ী। PSS বা USS পরিমাপ করার জন্য জটিল কার্নেল মেমরি ম্যানেজমেন্ট কাঠামো স্ক্যান করতে হয় এবং লক অর্জন করতে হয়, যা খুব ঘন ঘন সংগ্রহ করা হলে সিস্টেমের পারফরম্যান্সে সমস্যা (যেমন UI জ্যাঙ্ক) সৃষ্টি করতে পারে।
• ফিল্ড পরিমাপের সর্বোত্তম পদ্ধতি: বাস্তব জগতে থাকা ডিভাইস থেকে ডেটা সংগ্রহ করার সময়, সাধারণত অ্যানোনিমাস RSS + সোয়াপ (ZRAM) পরিমাপ করাই সবচেয়ে ভালো।
  • কেন শুধু অ্যানোনিমাস? ফাইল-ব্যাকড পেজ (যেমন কোড, অ্যাপ রিসোর্স, ফন্ট বা অন্যান্য মেমরি-ম্যাপড ফাইল) সিস্টেম-ব্যাপী পেজক্যাশের চাপের কারণে কার্নেল দ্বারা যেকোনো সময় সরিয়ে দেওয়া হতে পারে। কোনো নির্দিষ্ট অ্যাপ ট্র্যাক করার জন্য মেট্রিক্সে ফাইল পেজ অন্তর্ভুক্ত করলে, অপারেটিং সিস্টেমের মেমরি ব্যবস্থাপনার সিদ্ধান্ত থেকে এমন কিছু তথ্য চলে আসে যা অন্য অ্যাপ বা সিস্টেমের মেমরি চাপের কারণে হতে পারে। অন্যদিকে, অ্যানোনিমাস মেমরি (যেমন জাভা এবং নেটিভ হিপস) সরাসরি আপনার অ্যাপ দ্বারা নিয়ন্ত্রিত হয়।
  • সোয়াপ কেন যোগ করবেন? মেমোরির উপর চাপ পড়লে, অপারেটিং সিস্টেম অ্যানোনিমাস পেজগুলোকে কম্প্রেস করে ZRAM (সোয়াপ)-এ সরিয়ে দেয়। আপনি যদি শুধুমাত্র রেসিডেন্ট অ্যানোনিমাস মেমোরি পরিমাপ করেন, তাহলে আপনার মেট্রিক্সে মেমোরি ব্যবহারে একটি ভুল "হ্রাস" দেখা যেতে পারে, কারণ সিস্টেম চাপের মধ্যে থাকায় আপনার পেজগুলোকে সোয়াপ আউট করে দিয়েছে। সোয়াপড মেমোরি যোগ করলে এটি নিশ্চিত হয় যে আপনার অ্যাপ দ্বারা বরাদ্দ করা সমস্ত অ্যানোনিমাস মেমোরির হিসাব রাখা হয়েছে, তা বর্তমানে RAM-এ থাকুক বা ZRAM-এ।

ইউএসএস (অনন্য সেট আকার)

• এর জন্য সর্বোত্তম: কোনো প্রসেস বন্ধ করার ফলে সিস্টেমে তার তাৎক্ষণিক প্রভাব নির্ধারণ করা।
• কারণ: USS নির্ভুলভাবে সেই সঠিক পরিমাণ মেমরিকে উপস্থাপন করে যা প্রসেসটি বন্ধ করে দিলে (উদাহরণস্বরূপ, লো মেমরি কিলার ডেমন, lmkd দ্বারা) তাৎক্ষণিকভাবে পুনরুদ্ধার করে সিস্টেমে ফেরত দেওয়া হবে।
• ব্যবহারবিধি: দীর্ঘস্থায়ী প্রসেস বা ব্যাকগ্রাউন্ড সার্ভিস মূল্যায়ন করার ক্ষেত্রে এই মেট্রিকটি অত্যন্ত মূল্যবান। আপনি যদি কোনো ব্যাকগ্রাউন্ড প্রসেসের সিস্টেম-ব্যাপী খরচ মূল্যায়ন করেন, তাহলে USS আপনাকে স্পষ্টভাবে বলে দেবে যে শুধুমাত্র সেই নির্দিষ্ট প্রসেসটিকে সচল রাখার জন্য সিস্টেমটি ঠিক কতটা মেমরি উৎসর্গ করছে।

---

↑ উপরে | সরঞ্জাম →