মৌলিক ধারণা

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

পারফর্ম্যান্স ক্লিফ

মেমরি ব্যবহার করা ভাল বা খারাপ কিছু নয়; আপনি কীসের জন্য মেমরি ব্যবহার করছেন সেটাই আসল কথা। তবে, ডিভাইসে উপলভ্য মেমরির সীমা যত কাছাকাছি আসে, তত "পারফর্ম্যান্সের গ্রাফ নিচের দিকে নামতে থাকে।"

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

Android স্ট্যাক

Android স্ট্যাকের প্রতিটি লেয়ারের নিজস্ব মেমরি ভিউ আছে:

1. অ্যাপ্লিকেশন (Java/Kotlin): ডেভেলপাররা মূলত Java হিপে বরাদ্দ করা Java অবজেক্ট দেখতে পান।
2. Android Runtime (ART): কার্নেল থেকে ভার্চুয়াল মেমরি পেজ ব্যবহার করে ART, Java/Kotlin হিপ ম্যানেজ করে। আগে Dalvik নামে পরিচিত ছিল (এই শব্দগুলি কখনও কখনও একে অপরের পরিবর্তে ব্যবহার করা হয়)।
3. Linux কার্নেল: কার্নেল ফিজিক্যাল ও ভার্চুয়াল পৃষ্ঠার হিসেবে মেমরি দেখে। সাধারণত, এগুলি ৪ কেবি হয়, তবে Android-এ ১৬ কেবি পেজ সাইজও কাজ করে। কার্নেল "Java অবজেক্ট" সম্পর্কে কিছুই জানে না।

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

মেমরির ধরন: বেনামী বনাম ফাইল-ব্যাকড

OS কীভাবে মেমরি রিক্লেম করে তা জানার আগে, আপনাকে Linux-এ মেমরি পেজের দুটি মৌলিক বিভাগ বুঝতে হবে:

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

মনে রাখবেন: Android-এ প্রথাগত ডিস্ক সোয়াপ স্পেস ব্যবহার করা হয় না। পরিবর্তে, এটি ZRAM ব্যবহার করে, যা RAM-এর মধ্যে মেমরির একটি কম্প্রেস করা ব্লক।

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

Android, ফাইল-ব্যাকড ও অ্যানোনিমাস মেমরি, উভয়কেই প্রসেসের অ্যাড্রেস স্পেসে ম্যাপ করতে mmap ব্যবহার করে।

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

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

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

Zygote প্রসেস মডেল

Android, Zygote নামক একটি প্রসেস ব্যবহার করে নতুন অ্যাপ্লিকেশন শুরু করার খরচ কম করে।

1. বুট করার সময় Zygote চালু হয় এবং সাধারণ ফ্রেমওয়ার্ক ক্লাস ও রিসোর্স এর মেমরিতে প্রিলোড করে। কার্নেলের দৃষ্টিকোণ থেকে, এটি অজ্ঞাত ডার্টি মেমরি হয়ে যায়, তবে এটি Zygote প্রসেসের ক্ষেত্রে অনন্য।
2. নতুন অ্যাপ্লিকেশন শুরু হলে, সিস্টেম Zygote প্রসেস ফর্ক করে।
3. নতুন চাইল্ড প্রসেস কপি-অন-রাইট (COW) সিম্যান্টিক্স সহ শেয়ার করা ম্যাপিং ব্যবহার করে Zygote-এর মেমরি ইনহেরিট করে।

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

RSS, PSS, USS এবং memcg

প্রসেসের মধ্যে মেমরি ব্যাপকভাবে শেয়ার করা হয়—প্রাথমিকভাবে Zygote মডেলের মাধ্যমে—প্রসেসের মেমরির ব্যবহার হিসেব করার একাধিক উপায় আছে। RSS, PSS, এবং USS সেইসব পৃষ্ঠা গণনা করে যেগুলি কোনও প্রসেসের অ্যাড্রেস স্পেসে ম্যাপ করা হয়েছে:

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

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

memcg: কার্নেলের নিজস্ব অ্যাকাউন্টিং

কার্নেল প্রতিটি প্রসেসের ব্যবহার করা মেমরির মোট পরিমাণও ট্র্যাক করে, সেই মেমরি ম্যাপ করা হোক বা না হোক। Android-এ, প্রতিটি অ্যাপ প্রসেস তার নিজস্ব মেমরি কন্ট্রোল গ্রুপের (memcg) অন্তর্গত, যা সম্পূর্ণ অ্যাপের জন্য একটি memcg-এর মধ্যে নেস্ট করা থাকে (Android memcg হায়ারার্কি দেখুন)। যখনই মেমরির কোনও পৃষ্ঠা বরাদ্দ করা হয়, কার্নেল সেটিকে সেই প্রসেসের memcg-তে চার্জ করে যেটি এটি বরাদ্দ করেছে। memcg-এর memory.current ফাইলে মোট চার্জের পরিমাণ উল্লেখ করা আছে।

memcg অ্যাকাউন্টিং RSS, PSS ও USS-এর থেকে কয়েকটি গুরুত্বপূর্ণ উপায়ে আলাদা:

• প্রতিটি পৃষ্ঠার জন্য ঠিক একবার চার্জ করা হয়, সেই প্রসেসের memcg-তে যা প্রথমবার এটিকে মেমরিতে নিয়ে আসে। অন্য প্রসেস পরে একই পৃষ্ঠা ম্যাপ করলেও চার্জ থেকে যায়। Zygote যে পৃষ্ঠাগুলি প্রিলোড করে সেগুলি Zygote-এ চার্জ করা হয়, আপনার অ্যাপে নয়। আপনার অ্যাপ যখন এই পৃষ্ঠাগুলির একটিতে লেখে, তখন ব্যক্তিগত কপি আপনার অ্যাপে চার্জ করা হয়।
• এতে এমন মেমরি অন্তর্ভুক্ত থাকে যা পৃষ্ঠা-সারণী মেট্রিক দেখতে পারে না। memory.current আপনার অ্যাপ ম্যাপ না করেই যেসব ফাইল পৃষ্ঠা পড়ে সেগুলি গণনা করে (যেমন, read বা pread-এর মাধ্যমে পড়া ডেটাবেস পৃষ্ঠা)।
• এটি আলাদাভাবে ট্র্যাক সোয়াপ করে। ZRAM-এ কম্প্রেস করা মেমরি memory.current থেকে বেরিয়ে memory.swap.current-এ চলে যায়, যাতে আপনি অনুমান না করেই দুটিই দেখতে পান।
• এটি পড়তে কম খরচ হয়। কাউন্টার সবসময় আপ-টু-ডেট থাকে এবং সেগুলি রিড করলে আপনার অ্যাপের অ্যাড্রেস স্পেস লক বা স্ক্যান হয় না।
• এটি সিস্টেমের সীমা। Android অ্যাপের ক্ষেত্রে যে মেমরি সীমা ও মেমরি বাজেট প্রয়োগ করে, তা memcg চার্জের উপর কাজ করে।

গ্রাফিক্স মেমরি, যেমন হার্ডওয়্যার বিটম্যাপের পিছনে থাকা বাফার, সাধারণত আপনার অ্যাপের memcg-তে চার্জ করা হয় না।

মনে রাখবেন: Android 17 QPR2 (API লেভেল ৩৭.২) এবং তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইসে memcg মেট্রিক্স কাজ করে। আগের ভার্সনে, ডিভাইস অনুযায়ী, প্রসেস-প্রতি memcg ফাইল না থাকতে পারে বা অন্যভাবে সাজানো থাকতে পারে।

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

সঠিক মেমরি মেট্রিক বেছে নেওয়া নির্ভর করে আপনি কী পরিমাপ করার চেষ্টা করছেন এবং কোন পরিবেশে আপনি এটি পরিমাপ করছেন তার উপর। Android 17 QPR2 (API লেভেল ৩৭.২) এবং তার পরবর্তী যেকোনও ভার্সনে রান করা ডিভাইসে, আপনার নিজের অ্যাপ ট্র্যাক করার সময় memcg দিয়ে শুরু করুন।

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

memcg (মেমরি কন্ট্রোল গ্রুপ চার্জ)

• এর জন্য সবচেয়ে ভাল: Android 17 QPR2 বা তার পরবর্তী যেকোনও ভার্সন রান করছে এমন ডিভাইসে, সময়ের সাথে সাথে, ক্রিটিকাল ইউজার জার্নি (CUJ) জুড়ে বা অ্যাপের বিভিন্ন ভার্সনের মধ্যে, কোনও নির্দিষ্ট অ্যাপের মেমরির ব্যবহার ট্র্যাক করা। এছাড়াও, আপনি যখন মেমরি বাজেট ক্যালিব্রেট করেন, তখন এই মেট্রিকটি দেখতে হবে, কারণ এটিই হল সেই সংখ্যা যা বাজেট সীমিত করে।
• কেন: RSS-এর মতো, memcg চার্জ পরিবর্তন হয় না যখন অন্য অ্যাপ আপনার অ্যাপের সাথে পৃষ্ঠা শেয়ার করা শুরু বা বন্ধ করে দেয়। RSS-এর মতো, এটি কখনও কোনও পৃষ্ঠা দুবার গণনা করে না, তাই আপনি আপনার অ্যাপের সবকটি চলমান প্রসেসের চার্জ যোগ করতে পারবেন। পুরো-অ্যাপ memcg সেই যোগফলের চেয়ে বেশি হতে পারে, কারণ কার্নেল সেগুলি আবার দাবি না করা পর্যন্ত এটি বন্ধ হয়ে যাওয়া প্রসেস থেকে ক্যাশে করা ফাইল পেজ রাখে। এটি RSS, PSS এবং USS-এর মিস করা মেমরিও গণনা করে, যেমন আনম্যাপ করা ফাইল ক্যাশে। এটি পড়া সস্তা, কারণ কার্নেল কাউন্টার আপডেট করে যখন এটি পৃষ্ঠা চার্জ করে।
• এটি কীভাবে পড়বেন: কোনও প্রসেসের memcg ডিরেক্টরিতে memory.current, memory.swap.current এবং memory.stat পড়ুন (memcg পরিসংখ্যান দেখুন)। Android 18 এবং এর পরবর্তী যেকোনও ভার্সনে, dumpsys meminfo-ও সেগুলি প্রিন্ট করে। আপনার অ্যাপের মধ্যে থেকে, MemoryBudgetManager ব্যবহার করুন।
• ফিল্ড পরিমাপের পেশাদার পদ্ধতি: RSS-এ ব্যাখ্যা করা একই কারণে, বেনামী মেমরি + সোয়াপ ট্র্যাক করুন: memory.stat-এর anon ফিল্ড এবং memory.swap.current। memory.stat-এর file ফিল্ডে এমন ফাইল পৃষ্ঠা অন্তর্ভুক্ত থাকে যা আপনার অ্যাপ একবার পড়ে এবং কার্নেল এখনও রিক্লেম করেনি, তাই আপনার অ্যাপ সেই মেমরি ব্যবহার করা বন্ধ করার পরে কিছুক্ষণের জন্য memory.current বেশি থাকতে পারে।
• কখন সতর্ক হতে হবে: যেহেতু পৃষ্ঠাগুলি প্রথমে স্পর্শ করা প্রসেসের জন্য চার্জ করা হয়, তাই আপনার অ্যাপকে একটি শেয়ার করা ফাইল পৃষ্ঠার (যেমন একটি ফন্ট বা একটি শেয়ার করা লাইব্রেরি) জন্য চার্জ করা হয় যা অন্য কোনও প্রসেসের আগে এটি পড়ে। বিপরীতভাবে, আপনার অ্যাপ ব্যবহার করে এমন পৃষ্ঠাগুলির জন্য অন্য একটি প্রসেস চার্জ করা হতে পারে। ফাইল-ব্যাকড মেমরির জন্য ডিভাইস এবং রানের মধ্যে ছোট পার্থক্য আশা করুন এবং তুলনা করার সময় anon এবং সোয়াপের উপর নির্ভর করুন।

PSS (প্রোপোরশনাল সেট সাইজ)

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

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

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

USS (ইউনিক সেট সাইজ)

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

---

↑ উপরে | টুল →