অ্যাপ মেমরি বাজেট সেট করা

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

সম্প্রতি ব্যবহার করা হয়নি এমন মেমরি পেজ সরিয়ে দেওয়ার জন্য মেমরি এভিকশন ও সোয়াপ ব্যবহার করে বাজেট ব্যালেন্স করা হয়, যাতে অ্যাপের মেমরি ফুটপ্রিন্ট বর্তমান ওয়ার্কিং সেটের উপর ফোকাস করতে পারে। কোনও অ্যাপ তার ঘোষিত বাজেট অতিক্রম করলে, অপারেটিং সিস্টেম বিশেষভাবে সেই অ্যাপে রিক্লেম টার্গেট করে:

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

যতক্ষণ পর্যন্ত ওয়ার্কিং সেট বাজেটের সীমা অতিক্রম না করে, ততক্ষণ অ্যাপটি ভালভাবে কাজ করবে এবং সেট করা বাজেটের থেকে বেশি মেমরি ব্যবহার করবে না। অপারেটিং সিস্টেম অব্যবহৃত মেমরি খালি করে এবং ইনঅ্যাক্টিভ হিপ পেজ সোয়্যাপে কম্প্রেস করে যাতে প্রসেস বন্ধ না করেই মেমরি অ্যালোকেশন সীমাবদ্ধ থাকে।

কোনও অ্যাপ তার বাজেট অতিক্রম করলে কী হয়

মেমরি বাজেট অতিক্রম করলে সিস্টেম আপনার অ্যাপ বন্ধ বা ক্র্যাশ করে না। পরিবর্তে, যখন কোনও অ্যাপ তার বাজেটের চেয়ে বেশি মেমরি ব্যবহার করে, তখন OS এমন মেমরি খুঁজে বের করে যা অ্যাপটি কিছু সময়ের জন্য ব্যবহার করেনি এবং আবার প্রয়োজন না হওয়া পর্যন্ত নিরাপদে সরিয়ে রাখে। এটি নতুন অ্যাপ মেমরি অ্যালোকেশনের জন্য জায়গা করে দেয় এবং সামগ্রিকভাবে অ্যাপের মেমরি ব্যবহার বাজেটের মধ্যে রাখে।

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

OS কীভাবে মেমরি ট্র্যাক করে এবং ফিরিয়ে আনে তা জানতে, মেমরি আর্কিটেকচার গাইড দেখুন:

• মেমরি রিক্লেম ও সোয়াপ: OS কীভাবে আপনার অ্যাপে ব্যক্তিগত অজ্ঞাত হিপ ও ফাইল-ব্যাক করা পৃষ্ঠা চার্জ করে এবং বাজেট শেষ হয়ে গেলে কোল্ড পৃষ্ঠা রিক্লেম করে তা ব্যাখ্যা করে।
• মৌলিক ধারণা: শেয়ার করা Zygote মেমরি কেন আপনার অ্যাপের বাজেট থেকে বাদ দেওয়া হয়েছে এবং কীভাবে রেসিডেন্ট বাজেট ফিল্ড টেলিমেট্রিতে বেনামী RSS + সোয়াপ-এর সাথে সম্পর্কিত তা ব্যাখ্যা করে।
• বিটম্যাপ ও মেমরি: GPU-ব্যাকড হার্ডওয়্যার বিটম্যাপ ও DMA-BUF অ্যালোকেশন কীভাবে আপনার অ্যাপের হিপ ও মেমরি বাজেটের বাইরে হিসেব করা হয় তা ব্যাখ্যা করে।

Android ম্যানিফেস্টে বাজেট ঘোষণা করা

আপনার AndroidManifest.xml-এ মেমরি বাজেট ঘোষণা করা হল বাজেট নির্ধারণের প্রাথমিক এবং প্রস্তাবিত পদ্ধতি। এটির জন্য কোনও রানটাইম কোডের প্রয়োজন হয় না, প্রসেস শুরু হওয়ার সাথে সাথেই কার্যকর হয় এবং অপারেটিং সিস্টেমের জন্য স্পষ্ট চুক্তি প্রদান করে।

Android 17 QPR2 (API লেভেল ৩৭.২) এবং তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইসে <memory-budget> ঘোষণা কার্যকর হয়। Android-এর পুরনো ভার্সনে, প্ল্যাটফর্ম ম্যানিফেস্ট পার্সার নিরাপদে অপরিচিত XML এলিমেন্ট উপেক্ষা করে, যাতে আপনি ব্যাকওয়ার্ড কম্প্যাটিবিলিটি প্রভাবিত না করেই <memory-budget> গ্রহণ করতে পারেন।

বেসলাইন বাজেট ঘোষণা করুন

বেশিরভাগ অ্যাপের ক্ষেত্রে, অ্যাপ্লিকেশনের জন্য একটি বাজেট নির্ধারণ করাই যথেষ্ট। <application> ট্যাগের মধ্যে সরাসরি <memory-budget> এলিমেন্ট ঘোষণা করুন:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.simpleapp">

    <application
        android:label="@string/app_name">

        <!-- Baseline budget for the application -->
        <memory-budget android:maxMb="256" />

    </application>
</manifest>

এটি প্যাকেজের সমস্ত প্রসেস এবং স্টেট জুড়ে ২৫৬ এমবি রেসিডেন্ট মেমরি বাজেট সেট করে। অ্যাপের মেমরি ফুটপ্রিন্ট ২৫৬ এমবি-র বেশি হলে, অপারেটিং সিস্টেম ইনঅ্যাক্টিভ মেমরি পেজ এভিকশন ও সোয়াপ ব্যবহার করে ট্রিম করে।

প্রসেস স্টেট অনুযায়ী বাজেট পরিবর্তন করুন

ব্যবহারকারীর কাছে দৃশ্যমানতার উপর নির্ভর করে কোনও অ্যাপের বিভিন্ন পরিমাণ মেমরির প্রয়োজন হয়:

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

এইসব স্ট্যাটাস ম্যাচ করার জন্য আপনি একাধিক <memory-budget> ক্লজ ঘোষণা করতে পারবেন:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.simpleapp">

    <application
        android:label="@string/app_name">

        <!-- Default budget for visible foreground UI -->
        <memory-budget android:maxMb="200" />

        <!-- Tighter budget when playing audio in background -->
        <memory-budget
            android:maxMb="120"
            android:state="perceptible" />

        <!-- Minimal budget when fully in background -->
        <memory-budget
            android:maxMb="48"
            android:state="background" />

    </application>
</manifest>

android:state ছাড়া বেস ক্লজ প্রয়োজন নেই; আপনি যদি শুধু রাজ্য-নির্দিষ্ট ক্লজ উল্লেখ করেন (যেমন, android:state="background"), তাহলে অন্যান্য রাজ্যের ক্ষেত্রে অ্যাপ বাজেটের কোনও সীমাবদ্ধতা থাকবে না। অন্তর্ভুক্ত করা হলে, android:state ছাড়া একটি ক্লজ অনির্দিষ্ট অবস্থার (যেমন ফোরগ্রাউন্ড) জন্য ডিফল্ট ফলব্যাক হিসেবে কাজ করে, যা অ্যাপ perceptible বা background অবস্থায় ট্রানজিশন করলে পরবর্তী আরও বেশি সীমাবদ্ধ ক্লজ ওভাররাইড করে।

প্রতিটি স্টেটের জন্য বাজেটের সাইজ নির্ধারণ করার সময়, পিক রেসিডেন্ট মেমরির (RSS হাই-ওয়াটার মার্ক) পরিবর্তে সেই স্টেটের অ্যাক্টিভ ওয়ার্কিং সেটকে টার্গেট করুন:

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

ধাপে ধাপে ওয়ার্কফ্লোর জন্য, আপনার ওয়ার্কিং সেট পরিমাপ করুন এবং বাজেট ক্যালিব্রেট করুন দেখুন।

বাজেটের অবস্থা কীভাবে প্রসেসের অবস্থার সাথে ম্যাপ করা হয়

প্ল্যাটফর্মটি RunningAppProcessInfo.importance-এর উপর ভিত্তি করে রানটাইম প্রসেস স্টেটে ম্যানিফেস্ট বাজেট স্টেট ম্যাপ করে, যা অ্যাক্টিভিটি ম্যানেজার প্রসেসের নিজস্ব অ্যাক্টিভ কম্পোনেন্ট এবং অন্যান্য অ্যাপ থেকে আসা যেকোনও সার্ভিস বাইন্ডিং বা কন্টেন্ট প্রোভাইডার কোয়েরি থেকে গণনা করে:

• foreground: অ্যাক্টিভ, দৃশ্যমান ব্যবহারকারীর ইন্টার‍্যাকশন, যেমন আবার শুরু করা অ্যাক্টিভিটি হোস্ট করা, স্ক্রিন বন্ধ হয়ে গেলে টপ অ্যাপের স্ট্যাটাস বজায় রাখা, অথবা টপ ফোরগ্রাউন্ড অ্যাপের মাধ্যমে অ্যাক্টিভভাবে বাউন্ড বা কোয়েরি করা কোনও পরিষেবা বা কন্টেন্ট প্রোভাইডার হোস্ট করা।
• perceptible: দৃশ্যমান উইন্ডো ছাড়াই ব্যবহারকারীর কাছে বোধগম্য ওয়ার্কলোড, যেমন অ্যাক্টিভ মিডিয়া প্লেব্যাক, ধাপে ধাপে নেভিগেশন, ক্যামেরা বা মাইক্রোফোন ক্যাপচার, অ্যাক্টিভ ব্যাকগ্রাউন্ড ডাউনলোড, ডেটা সিঙ্ক ফোরগ্রাউন্ড সার্ভিস বা ফোরগ্রাউন্ড ক্লায়েন্ট দ্বারা আবদ্ধ পরিষেবা, যেমন BIND_NOT_FOREGROUND (BIND ফ্ল্যাগ সহ ইনহেরিটেন্স কন্ট্রোল করা দেখুন)। ইন্টার্নাল প্ল্যাটফর্ম মেট্রিক এইসব ওয়ার্কলোডের কিছু অংশকে PROCESS_STATE_IMPORTANT_FOREGROUND হিসেবে লেবেল করতে পারে, তবে সেই ইন্টার্নাল কনস্ট্যান্ট কোনও দৃশ্যমান উইন্ডোকে চিহ্নিত করে না এবং perceptible বাজেট দ্বারা পরিচালিত হয়।
• background: এমন কাজ যা ব্যবহারকারী অবিলম্বে বুঝতে পারেন না, যেমন ব্যাকগ্রাউন্ড জব, অ্যালার্ম ও সম্প্রচার রিসিভার।

রানটাইম গুরুত্বের লেভেল কীভাবে ম্যানিফেস্ট স্ট্যাটাসে ম্যাপ করা হয় তা নিম্নলিখিত সারণীতে দেখানো হয়েছে:

ক্লায়েন্ট বাইন্ডিং কীভাবে কোনও পরিষেবা বা প্রোভাইডার হোস্ট প্রসেসকে উন্নত করে এবং ক্লায়েন্ট আনবাইন্ড বা অফ-স্ক্রিনে চলে যাওয়ার পরে কীভাবে প্রসেসটি আবার background বা cached-এ ফিরে আসে সেই সম্পর্কে বিস্তারিত জানতে, পরিষেবা বাইন্ডিং ও প্রসেস স্টেট দেখুন।

কোনও প্রসেস কোনও অ্যাক্টিভ কম্পোনেন্ট ছাড়া ক্যাশে করা অবস্থায় (IMPORTANCE_CACHED) প্রবেশ করলে, প্ল্যাটফর্মটি তার অ্যাক্টিভ মেমরি বাজেট রিলিজ করে এবং স্ট্যান্ডার্ড ক্যাশে করা-প্রসেস রিক্লেমেশনের মাধ্যমে তার মেমরি ম্যানেজ করে।

আপনার অ্যাপের প্রসেস স্টেট ও বাজেট পরীক্ষা করুন

ডেভেলপমেন্টের সময় আপনার অ্যাপের অ্যাক্টিভ প্রসেস স্টেট ও গুরুত্ব পরীক্ষা করার একটি উপায় হল ADB ব্যবহার করে অ্যাক্টিভিটি ম্যানেজার কোয়েরি করা:

adb shell dumpsys activity processes <package-name>

নিম্নলিখিত সংক্ষিপ্ত উদাহরণে ফোরগ্রাউন্ড সার্ভিস চালাচ্ছে এমন অ্যাপের জন্য প্রসেস রেকর্ড ও OOM কন্ট্রোল এন্ট্রি দেখানো হয়েছে:

ACTIVITY MANAGER RUNNING PROCESSES (dumpsys activity processes)
  All known processes:
  *APP* UID 10123 ProcessRecord{edf056c 3919:com.example.app/u0a123}
    pid=3919
    oom adj: max=1001 curRaw=200 setRaw=200 cur=200 set=200
    curProcState=4 mRepProcState=4 setProcState=4 lastStateTime=-42s360ms
    hasStartedServices=true
    mHasForegroundServices=true forcingToImportant=null
...
  Process OOM control (48 total):
    Proc #22: prcp  F/S/FGS  ---NFU-TI  t: 0 3919:com.example.app/u0a123 (fg-service)
        oom: max=1001 curRaw=200 setRaw=200 cur=200 set=200
        state: cur=FGS  set=FGS  lastRss=0.00 lastCachedRss=0.00

এই আউটপুটে:

• curProcState=4 এবং state: cur=FGS থেকে বোঝা যায় যে প্রসেসটি ফোরগ্রাউন্ড সার্ভিস স্টেটে রয়েছে। আপনার অ্যাপ কোনও অ্যাক্টিভ দৃশ্যমান অ্যাক্টিভিটি হোস্ট করলে, এটি TOP হিসেবে দেখা যায়। এটি কোনও গুরুত্বপূর্ণ ফোরগ্রাউন্ড কম্পোনেন্ট (যেমন, ডাউনলোড বা সিঙ্ক) রান করলে, এটি IMPF হিসেবে দেখা যায়।
• প্রসেস OOM কন্ট্রোল টেবিলে, prcp থেকে বোঝা যায় যে প্রসেসটি পারসেপ্টিবেল প্রায়োরিটি টিয়ারের অধীনে মূল্যায়ন করা হয়েছে, যা perceptible বাজেটের সাথে সম্পর্কিত।

আপনার অ্যাপের বর্তমান রেসিডেন্ট মেমরির ব্যবহার পরীক্ষা করতে:

adb shell dumpsys meminfo <package-name>

মাল্টি-প্রসেস অ্যাপ

আপনার অ্যাপ্লিকেশন যদি একাধিক প্রসেস জুড়ে তার কাজ ভাগ করে, তাহলে <processes>-এর মধ্যে <process> ট্যাগ ব্যবহার করে ডেডিকেটেড প্রসেস বাজেট কনফিগার করুন।

যেমন, একটি স্ট্রিমিং মিউজিক অ্যাপ (com.example.radio) বিবেচনা করুন:

1. প্রধান প্রসেস: দৃশ্যমান UI এবং অডিও প্লেব্যাক ইঞ্জিন হোস্ট করে (MediaSessionService mediaPlayback ফোরগ্রাউন্ড পরিষেবার সাথে)। দেখা গেলে, প্রসেসটি ১৮০ এমবি ফোরগ্রাউন্ড বাজেটের অধীনে কাজ করে। মিউজিক চলাকালীন ব্যবহারকারী অ্যাপ থেকে বেরিয়ে গেলে, প্রসেসটি perceptible অবস্থায় প্রবেশ করে, যেখানে প্লেব্যাক ইঞ্জিন এবং অডিও বাফারের জন্য ৬৪ এমবি বাজেট যথেষ্ট।
2. সিঙ্ক প্রসেস (:sync): ব্যাকগ্রাউন্ড মেটাডেটা সিঙ্ক্রোনাইজেশন ও ডাউনলোড ইন্ডেক্সিংয়ের জন্য ডেডিকেটেড প্রসেস চলছে। এই প্রসেসটি শুধুমাত্র ব্যাকগ্রাউন্ডে অ্যাক্টিভ থাকে বলে, আপনাকে আলাদা করে state="background"; একটি বাজেট প্রয়োগ করার কথা ঘোষণা করতে হয় না।

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.radio">

    <application
        android:label="@string/app_name">

        <!-- Package baseline: main process with UI and audio playback -->
        <memory-budget android:maxMb="180" />

        <!-- Tighter budget when audio plays in the background -->
        <memory-budget
            android:maxMb="64"
            android:state="perceptible" />

        <processes>
            <!-- Dedicated background sync process -->
            <process android:process=":sync">
                <memory-budget android:maxMb="32" />
            </process>
        </processes>

        <service
            android:name=".playback.AudioPlayerService"
            android:foregroundServiceType="mediaPlayback"
            android:exported="false" />

        <service
            android:name=".sync.PlaylistSyncService"
            android:process=":sync"
            android:exported="false" />

    </application>
</manifest>

আপনার ম্যানিফেস্টে <processes> ব্লক ঘোষণা করার সময়, শুধুমাত্র <memory-budget> ঘোষণা করা প্রসেসের জন্য <process> এন্ট্রি তালিকাভুক্ত করুন। আপনি যদি শুধুমাত্র নির্দিষ্ট সাবপ্রসেসের জন্য বাজেট সেট করতে চান এবং অ্যাপের বাকি অংশ ডিভাইসের সিস্টেম সীমাতে রাখতে চান, তাহলে আপনি সরাসরি <application>-এর অধীনে <memory-budget> এলিমেন্ট বাদ দিতে পারেন।

যেকোনও সাবপ্রসেসে মেমরির ব্যবহার তার প্রসেস বাজেট এবং এনক্লোজিং প্যাকেজ বাজেট, উভয়ের বিরুদ্ধেই গণনা করা হয়। রানটাইমে কোনও প্রসেস মেমরি প্রেসার অনুভব করে যদি এটি তার প্রসেস বাজেট বা প্যাকেজ বাজেট লঙ্ঘন করে, যে থ্রেশহোল্ডে প্রথমে পৌঁছানো হয়।

হাই-ডেনসিটি ডিসপ্লের জন্য স্কেল বাজেট

যেসব অ্যাপ্লিকেশনের মেমরি ফুটপ্রিন্ট ডিসপ্লেতে একবারে কতগুলি পিক্সেল আঁকতে হবে তার সাথে উল্লেখযোগ্যভাবে স্কেল করে—যেমন স্ক্রিনের সাইজ অনুযায়ী বিটম্যাপ ক্যাশে করা ফটো গ্যালারি অ্যাপ—Android ডিসপ্লে স্পেসিফিকেশন সহ বাজেটকে ডাইনামিকভাবে স্কেল করার জন্য দুটি বিকল্প মেকানিজম প্রদান করে:

• ডিসপ্লে ডেনসিটি বাকেট (android:additionalMbPerDensity) অনুযায়ী স্কেল করা: ডিসপ্লের ডেনসিটি অনুপাতের বর্গক্ষেত্রের সাথে আনুপাতিকভাবে মেগাবাইট যোগ করে, যা mdpi (1.0x / 160 dpi)-এর সাথে সম্পর্কিত, কারণ 2D রাস্টার ড্রয়েবল এবং UI অ্যাসেট প্রস্থ ও উচ্চতা জুড়ে স্কেল করে:

  <!-- Baseline 180MB + 16MB multiplied by (density ratio)^2 -->
  <memory-budget
      android:maxMb="180"
      android:additionalMbPerDensity="16" />
  

  mdpi ডিসপ্লেতে (১.০x), বাজেট হল ১৮০ + ১৬ × ১^২ = ১৯৬ এমবি। xxhdpi ডিসপ্লেতে (3.0x), বাজেট স্কেল হল ১৮০ + ১৬ × ৩^২ = ৩২৪ এমবি।

• ফিজিক্যাল ডিসপ্লে রেজোলিউশন অনুযায়ী স্কেল করা (android:additionalBytesPerDisplayPixel): ফিজিক্যাল ডিসপ্লে পিক্সেল (প্রস্থ × উচ্চতা) অনুযায়ী সরাসরি বাইট যোগ করে। এটি সেইসব অ্যাপ্লিকেশনের জন্য আদর্শ যেগুলি ফুল-স্ক্রিন গ্রাফিক্স সারফেস, রেন্ডার বাফার বা ফুল-রেজোলিউশন ফটো ক্যাশে বরাদ্দ করে, যেখানে মেমরি খরচ সরাসরি UI ডেনসিটি বাকেটের পরিবর্তে র-ডিসপ্লে পিক্সেল কাউন্টের সাথে স্কেল করে:

  <!-- Baseline 128MB + 16 bytes per physical display pixel -->
  <!-- For example, a 4-byte RGBA full-screen buffer with double or quadruple buffering -->
  <memory-budget
      android:maxMb="128"
      android:additionalBytesPerDisplayPixel="16" />
  

  1080p ডিসপ্লেতে (১০৮০ × ২৪০০ ≈ ২.৫৯M পিক্সেল), এটি বেসলাইন বাজেটে ≈ ৪১.৪ এমবি যোগ করে। ১৪৪০p ডিসপ্লেতে (১৪৪০ × ৩১২০ ≈ ৪.৪৯M পিক্সেল), এটি ≈ ৭১.৮ এমবি যোগ করে।

এই দুটি অ্যাট্রিবিউট বিকল্প হিসেবে ব্যবহার করা যায়। আপনার অ্যাপের প্রাথমিক স্কেলিং ফ্যাক্টরের সাথে মেলে এমন অ্যাট্রিবিউট বেছে নিন এবং একই ক্লজে দুটিকে একত্রিত করা এড়িয়ে চলুন।

ডিভাইস ফর্ম ফ্যাক্টরের জন্য বিশেষীকরণ

ফোন, ট্যাবলেট ও Wear OS-এ APK শিপিং করার সময়, বিভিন্ন হার্ডওয়্যার টার্গেটের জন্য বাজেট অ্যাডজাস্ট করতে android:feature অ্যাট্রিবিউট ব্যবহার করুন।

Wear OS স্মার্টওয়াচে, RAM সীমিত এবং অ্যাপের UI ও ফিচার সেট অনেক সহজ। আপনি watch ফিচারের জন্য আরও কম বাজেট ঘোষণা করতে পারেন:

<!-- General phone and tablet baseline -->
<memory-budget android:maxMb="180" />

<!-- Wear OS override: simpler UI and constrained hardware -->
<memory-budget
    android:maxMb="48"
    android:feature="watch" />

সমাধানের নিয়ম: শেষ প্রযোজ্য ধারা কার্যকর হয়

কোনও অ্যাপ্লিকেশন বা প্রসেসের জন্য একাধিক <memory-budget> এলিমেন্ট নির্ধারণ করার সময়, ম্যানিফেস্টে সেগুলি যেভাবে উল্লেখ করা হয়েছে সেই ক্রম অনুযায়ী সিস্টেম সেগুলি মূল্যায়ন করে। শেষ প্রযোজ্য বাজেট ক্লজটি এনফোর্স করা হয়।

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

XML অ্যাট্রিবিউট রেফারেন্স

সব মেমরি সাইজ অ্যাট্রিবিউট মেগাবাইটে (এমবি) প্রকাশ করা হয় এবং Linux cgroup memory.current চার্জে ম্যাপ করা হয় (যা Zygote-এর মতো শেয়ার করা মেমরি বাদ দেয়)।

আপনার ওয়ার্কিং সেট পরিমাপ করুন এবং বাজেট ক্যালিব্রেট করুন

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

ওয়ার্কিং সেট বনাম রেসিডেন্ট মেমরি বোঝা

বাজেট ছাড়া, আপনার অ্যাপের রেসিডেন্ট ফুটপ্রিন্ট (memory.current) দুই ধরনের মেমরি ধরে রাখে:

• ওয়ার্কিং সেট: Java, Kotlin ও নেটিভ হিপ এবং হট ফাইল-ব্যাকড পৃষ্ঠা (DEX কোড, নেটিভ লাইব্রেরি ও অ্যাসেট) যা বর্তমান ব্যবহারকারীর ফ্লো বারবার টাচ করে
• কোল্ড স্ল্যাক: আগের স্ক্রিন থেকে বিটম্যাপ ক্যাশে, এক-বার স্টার্টআপ বাফার, অ্যালোকেশন বার্স্টের পরে হিপ স্ল্যাক বাকি থাকা এবং ফাইল পেজ যা একবার পড়া হয়েছে এবং আর কখনও স্পর্শ করা হয়নি

আপনার আনকনস্ট্রেইন্ড পিক বাজেটের মাধ্যমে কখনও কোল্ড স্ল্যাক রিক্লেম করা যায় না। আপনার ওয়ার্কিং সেটের থেকে কম বাজেট থাকলে, কার্নেল হিপ পৃষ্ঠা সোয়াপ আউট করে এবং কোড পৃষ্ঠা বের করে দেয়, যার ফলে আপনার অ্যাপে অবিলম্বে আবার সমস্যা দেখা দেয়। এই ওয়ার্কিং-সেট রিফল্ট সিপিইউ টাইম ও ব্যাটারি খরচ করে এবং UI থ্রেডে চলে এলে, ফ্রেমও খরচ করে।

আপনি যা খুঁজছেন তা হল নি: সর্বনিম্ন বাজেট যেখানে রিক্লেম শুধুমাত্র কোল্ড স্ল্যাক সরিয়ে দেয়, তাই রিফল্ট, সিপিইউ টাইম এবং ফ্রেম টাইম বাজেট ছাড়াই যেখানে ছিল সেখানেই থাকে।

আপনার টেস্ট এনভায়রনমেন্ট প্রস্তুত করা

প্রোডাকশনের মতো কাজ করে এমন একটি রিপিটেবল টেস্ট সেট-আপ করুন:

• আপনি যে R8-অপ্টিমাইজ করা, নন-ডিবাগেবল রিলিজ বিল্ড শিপ করেন, সেটি ক্যালিব্রেট করুন। ডিবাগ বিল্ট বেশি মেমরি ব্যবহার করে, তাই ডিবাগ বিল্টে টিউন করা বাজেট রিলিজের জন্য খুব বেশি।
• Android 17 QPR2 (API লেভেল ৩৭.২) বা তার পরবর্তী যেকোনও ভার্সন চলছে এমন ডিভাইস বা এমুলেটরে পরীক্ষা করুন। Google Play ছাড়া userdebug বিল্ড বা এমুলেটর ইমেজ সবচেয়ে ভালো, কারণ কিছু ডিভাইস আপনাকে adb root চালানোর পরে নিম্নলিখিত বিভাগে শুধুমাত্র cgroup ফাইল পড়তে দেয়।
• Jetpack Macrobenchmark, UI Automator বা adb shell input-এর মাধ্যমে ৩০ থেকে ৬০ সেকেন্ডের ইউজার ফ্লো স্ক্রিপ্ট করুন, আপনি বাজেট করার পরিকল্পনা করছেন এমন প্রতিটি অবস্থার জন্য একবার। কোনও অ্যাপ কাজ না করলে, তার ওয়ার্কিং সেট সম্পর্কে কিছুই জানা যায় না।
  • foreground: ঘন তালিকা ও মিডিয়া গ্রিড স্ক্রল করুন, আপনার প্রধান গন্তব্যের মধ্যে ঘুরে বেড়ান, মেনু ও ডায়ালগ খুলুন এবং অ্যানিমেশন চালান
  • perceptible: কোনও কাজ (যেমন, অডিও প্লেব্যাক বা ডাউনলোড) চলাকালীন দৃশ্যমান উইন্ডো থেকে বেরিয়ে আসুন, ১০ থেকে ১৫ সেকেন্ডের জন্য এটি চলতে দিন এবং তারপরে অ্যাপে ফিরে আসুন
  • background: অ্যাপের কোনও দৃশ্যমান UI না থাকলে, সিঙ্ক, WorkManager জব (যেমন, adb shell cmd jobscheduler run -f <package-name> <job-id>-এর সাথে), শুরু করা পরিষেবা বা ব্রডকাস্ট রিসিভার ট্রিগার করা

ব্যাকগ্রাউন্ডে কাজ চলাকালীন background বাজেট পরিমাপ করুন। প্রসেসটি ক্যাশ করা হয়ে গেলে, প্ল্যাটফর্মটি তার বাজেট রিলিজ করে (কীভাবে বাজেট স্টেট প্রসেস স্টেটে ম্যাপ করে দেখুন), তাই একটি নিষ্ক্রিয় ক্যাশ করা প্রসেস আপনাকে আপনার background বাজেট সম্পর্কে কিছু বলে না।

আপনার বেসলাইন পরিমাপ করুন

বাজেট নেই এমন রান দিয়ে শুরু করুন, যাতে আপনি বুঝতে পারেন যে স্বাভাবিক রান কেমন হয়। <memory-budget> ঘোষণা ছাড়া একটি বিল্ড ব্যবহার করুন এবং প্রতিটি রান একটি নতুন প্রসেস (adb shell am force-stop <package-name>) থেকে শুরু করুন।

প্রতিটি অ্যাপ প্রসেসের নিজস্ব cgroup v2 মেমরি কন্ট্রোলার আছে। /proc/<PID>/cgroup-এর 0:: লাইন থেকে এর পাথ দেখুন, নিজে পাথ তৈরি করবেন না, কারণ cgroup লেআউট ডিভাইস অনুযায়ী আলাদা হতে পারে। প্রতিটি ডিভাইস কমান্ডকে adb shell-এ সিঙ্গেল কোট স্ট্রিং হিসেবে পাস করুন যাতে ডিভাইস শেল কোট দেখতে পায়:

PID=$(adb shell pidof -s <package-name>)
CG=/sys/fs/cgroup$(adb shell "sed -n 's/^0:://p' /proc/$PID/cgroup")
adb shell "cat $CG/memory.current $CG/memory.swap.current"
adb shell "grep -E '^(anon|file|workingset_refault_.*) ' $CG/memory.stat"

এইসব ফাইল রিড করা সস্তা এবং আপনার অ্যাপে কোনও সমস্যা তৈরি করে না, তাই রান করার সময় আপনি প্রতি সেকেন্ডে এগুলি স্যাম্পেল করতে পারবেন:

• memory.current: প্রসেসে চার্জ করা রেসিডেন্ট মেমরি, বাইটে। এটি হল সেই সংখ্যা যা <memory-budget> সীমিত করে।
• memory.swap.current: zRAM সোয়াপে কম্প্রেস করা মেমরি, বাইটে
• anon এবং file memory.stat-এ: রেসিডেন্ট অ্যানোনিমাস এবং ফাইল-ব্যাকড মেমরি, বাইটে
• memory.stat-এ workingset_refault_anon এবং workingset_refault_file: আপনার অ্যাপের আবার প্রয়োজন হয়েছে এমন সোয়্যাপ-আউট বা উচ্ছেদ করা পৃষ্ঠার রানিং কাউন্ট। এইসব কাউন্টার হল আপনার প্রধান চিহ্ন যে বাজেট খুব কঠোর।

adb shell am memory-limiter manual <PID> 120MB
adb shell am memory-limiter manual <PID> none

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.BAKLAVA &&
    Build.VERSION.SDK_INT_FULL >= Build.VERSION_CODES_FULL.CINNAMON_BUN_2
) {
    val budgetManager = context.getSystemService(MemoryBudgetManager::class.java)
}

// Query current memory charged to this process and the package UID
val processUsageBytes = budgetManager.processCurrentUsageBytes
val packageUsageBytes = budgetManager.packageCurrentUsageBytes

// Query effective budgets (returns LIMIT_IS_DISABLED if unconstrained)
val processBudgetBytes = budgetManager.processBudgetBytes
val packageBudgetBytes = budgetManager.packageBudgetBytes

// Set a tighter dynamic budget on the current process (e.g., 96 MB)
try {
    budgetManager.processBudgetBytes = 96L * 1024L * 1024L
} catch (e: IllegalArgumentException) {
    // Thrown if the budget is <= 0 or exceeds the manifest ceiling or system limit
    Log.e(TAG, "Requested budget exceeds manifest or system ceiling", e)
}

// Clear the dynamic process budget to restore the manifest limit (or unconstrained baseline)
budgetManager.clearProcessBudget()

val cleanupThread = HandlerThread("MemoryBudgetCleanup").apply { start() }

val listener = MemoryBudgetManager.OnOverBudgetListener { budgetBytes ->
    Log.w(TAG, "Process exceeded memory budget of $budgetBytes bytes")
    // Proactively evict thread-safe caches on the background Looper
    imageTileCache.evictAll()
}

// Register on a background Looper before tightening a dynamic budget
budgetManager.registerProcessOverBudgetListener(cleanupThread.looper, listener)

// When done (for example, in onStop)
budgetManager.unregisterProcessOverBudgetListener(listener)

find_library(android-lib android)
target_link_libraries(my_native_engine PRIVATE ${android-lib})

#include <android/memory_budget_manager.h>

// Query current memory usage
int64_t process_usage = AMemoryBudgetManager_getProcessCurrentUsageBytes();
int64_t package_usage = AMemoryBudgetManager_getPackageCurrentUsageBytes();

// Query current budget
int64_t process_budget = 0;
AMemoryBudgetResult result = AMemoryBudgetManager_getProcessBudget(&process_budget);
if (result == AMEMORY_BUDGET_RESULT_SUCCESS) {
    // Current budget available in process_budget
} else if (result == AMEMORY_BUDGET_RESULT_LIMIT_IS_DISABLED) {
    // No budget is currently active
}

// Set a tighter process budget (e.g. 160MB)
AMemoryBudgetResult result = AMemoryBudgetManager_setProcessBudget(160LL * 1024 * 1024);
if (result != AMEMORY_BUDGET_RESULT_SUCCESS) {
    const char* error_msg = AMemoryBudgetManager_resultToString(result);
    // Handle error (e.g. AMEMORY_BUDGET_RESULT_ERROR_EXCEEDS_MANIFEST_LIMIT)
}

// Clear the dynamic budget to resume manifest limits (or unconstrained baseline)
AMemoryBudgetManager_clearProcessBudget();

void onMemoryPressure(int32_t event_mask, const AMemoryBudgetEvents* events, void* userdata) {
    // High-yield eviction of unused native textures or geometry caches
    purgeNativeTextureCaches();
}

// Register watcher on a background worker ALooper with a 1000ms debounce interval
AMemoryBudgetManagerWatcher* watcher = AMemoryBudgetManager_Watcher_create(
    background_looper,
    AMEMORY_BUDGET_MANAGER_EVENT_PROCESS,
    1000 /* debounce_ms */,
    &onMemoryPressure,
    NULL /* userdata */
);

// When done:
AMemoryBudgetManager_Watcher_destroy(watcher);

<manifest ... >
    <application ... >
        <!-- Manifest ceiling accommodates the heaviest editing workload -->
        <memory-budget android:maxMb="256" />
    </application>
</manifest>

package com.example.imageeditor.ui

import android.app.Activity
import android.app.MemoryBudgetManager
import android.graphics.Bitmap
import android.os.Bundle
import android.os.HandlerThread
import android.util.Log
import android.util.LruCache

class ImageEditorActivity : Activity() {

    private lateinit var budgetManager: MemoryBudgetManager
    private lateinit var cleanupThread: HandlerThread

    // Thread-safe in-memory cache for rendered preview tiles (32MB limit)
    private val previewCache = object : LruCache<String, Bitmap>(32 * 1024 * 1024) {
        override fun sizeOf(key: String, value: Bitmap): Int = value.byteCount
    }

    private val overBudgetListener = MemoryBudgetManager.OnOverBudgetListener { budgetBytes ->
        Log.w(TAG, "Process memory pressure detected (budget: ${budgetBytes / 1048576}MB). Evicting preview cache.")
        previewCache.evictAll()
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        budgetManager = getSystemService(MemoryBudgetManager::class.java)
        cleanupThread = HandlerThread("MemoryBudgetCleanup").apply { start() }
    }

    override fun onStart() {
        super.onStart()
        // Register listener on a background Looper before tightening the budget
        budgetManager.registerProcessOverBudgetListener(cleanupThread.looper, overBudgetListener)
        // Constrain memory during lightweight gallery browsing
        applyGalleryBudget()
    }

    override fun onStop() {
        super.onStop()
        budgetManager.unregisterProcessOverBudgetListener(overBudgetListener)
    }

    override fun onDestroy() {
        cleanupThread.quitSafely()
        super.onDestroy()
    }

    /**
     * Called when the user enters the high-resolution editing canvas.
     * Clears the dynamic budget, restoring the full 256MB manifest ceiling.
     */
    fun enterEditingCanvas() {
        // Clear the tighter dynamic budget to restore the full manifest ceiling (256MB)
        budgetManager.clearProcessBudget()
        Log.i(TAG, "Restored manifest budget ceiling (256MB) for editing canvas")
    }

    /**
     * Called when the user exits the editor back to the thumbnail gallery.
     * Re-applies the tighter dynamic budget.
     */
    fun exitToGallery() {
        previewCache.trimToSize(8 * 1024 * 1024)
        applyGalleryBudget()
    }

    private fun applyGalleryBudget() {
        try {
            // Dynamically tighten budget to 96MB for the lightweight gallery view
            budgetManager.processBudgetBytes = 96L * 1024L * 1024L
            Log.i(TAG, "Tighter dynamic budget applied for gallery: 96MB")
        } catch (e: IllegalArgumentException) {
            Log.e(TAG, "Could not apply dynamic budget", e)
        }
    }

    companion object {
        private const val TAG = "ImageEditor"
    }
}

#include <android/memory_budget_manager.h>
#include <android/looper.h>
#include <android/log.h>

#define LOG_TAG "Native3DEngineMemory"
#define LOGI(...) __android_log_print(ANDROID_LOG_INFO, LOG_TAG, __VA_ARGS__)
#define LOGW(...) __android_log_print(ANDROID_LOG_WARN, LOG_TAG, __VA_ARGS__)

class MemoryGovernor {
public:
    MemoryGovernor() : mWatcher(nullptr) {}

    ~MemoryGovernor() {
        stopMonitoring();
    }

    // Configures process budget based on user graphics quality settings
    bool setQualityBudget(int qualityLevel) {
        int64_t targetBytes = 0;
        switch (qualityLevel) {
            case 0: // Low (budget: 128MB)
                targetBytes = 128LL * 1024 * 1024;
                break;
            case 1: // Medium (budget: 256MB)
                targetBytes = 256LL * 1024 * 1024;
                break;
            case 2: // High (budget: 512MB)
                targetBytes = 512LL * 1024 * 1024;
                break;
            default:
                // Clear dynamic override and restore manifest limit
                AMemoryBudgetManager_clearProcessBudget();
                return true;
        }

        AMemoryBudgetResult result = AMemoryBudgetManager_setProcessBudget(targetBytes);
        if (result != AMEMORY_BUDGET_RESULT_SUCCESS) {
            LOGW("Could not set quality budget: %s", AMemoryBudgetManager_resultToString(result));
            return false;
        }
        return true;
    }

    // Call on a background worker ALooper before tightening the budget with setQualityBudget
    bool startMonitoring(ALooper* backgroundLooper) {
        if (!backgroundLooper) return false;

        // Monitor process budget events, debounced to at most once every 1000ms
        mWatcher = AMemoryBudgetManager_Watcher_create(
            backgroundLooper,
            AMEMORY_BUDGET_MANAGER_EVENT_PROCESS,
            1000,
            &MemoryGovernor::onPressureEvent,
            this
        );
        return mWatcher != nullptr;
    }

    void stopMonitoring() {
        if (mWatcher) {
            AMemoryBudgetManager_Watcher_destroy(mWatcher);
            mWatcher = nullptr;
        }
    }

    void unloadUnusedTextures() {
        LOGW("Memory pressure callback triggered. Purging cached texture mipmaps...");
        // Fast, idempotent, high-yield eviction without allocating memory
    }

private:
    static void onPressureEvent(
        int32_t event_mask,
        const AMemoryBudgetEvents* events,
        void* userdata
    ) {
        auto* governor = static_cast<MemoryGovernor*>(userdata);
        governor->unloadUnusedTextures();
    }

    AMemoryBudgetManagerWatcher* mWatcher;
};