দ্রুত মূল্যায়ন টুল

মেমরির ব্যবহার খতিয়ে দেখার প্রয়োজন হলে, মেমরির কোন বিভাগ সবচেয়ে গুরুত্বপূর্ণ তা শনাক্ত করতে হাই-লেভেল অ্যাসেসমেন্ট টুল দিয়ে শুরু করুন।

dumpsys meminfo

কোনও অ্যাপ্লিকেশনের মেমরি ব্যবহার সম্পর্কে ওভারভিউ পাওয়ার সবচেয়ে সাধারণ উপায় হল dumpsys meminfo। সব মেমরি ম্যাপিং সহ বিস্তারিত ব্রেকডাউন দেখতে, -a ফ্ল্যাগ অন্তর্ভুক্ত করা প্রায়শই সহায়ক হয়:

adb shell dumpsys meminfo -a <package_name_or_pid>

মেমরির উপর চাপ আছে এমন একটি অ্যাপ্লিকেশনের স্যাম্পেল আউটপুট এখানে দেওয়া হল (SwapPss-এর উচ্চ মান লক্ষ্য করুন):

** MEMINFO in pid 4562 [com.android.memorylab] **
                   Pss  Private  Private  SwapPss      Rss     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty    Total     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------   ------
  Native Heap      394      268       64    17440     4264    29416    18128     8040
  Dalvik Heap      165        8        0      672     8196    40949    32757     8192
 Dalvik Other       47       28        0      604     1132
        Stack      112      108        4      312      120
...
        TOTAL    33197      580      788    21920   167776    70365    50885    16232

 App Summary
                       Pss(KB)                        Rss(KB)
                        ------                         ------
           Java Heap:       12                          32608
         Native Heap:      268                           4264
                Code:      724                         125672
               Stack:      108                            120
            Graphics:        0                              0
       Private Other:      256
              System:    31829
             Unknown:                                    5112

           TOTAL PSS:    33197            TOTAL RSS:   167776       TOTAL SWAP PSS:    21920

 Objects
               Views:       15         ViewRootImpl:        1
         AppContexts:        5           Activities:        1
...

ডেটা ব্যাখ্যা করা

  • Pss Total: প্রোপোরশনাল সেট সাইজ। এটি হল Private Dirty-এর যোগফল
    • Private Clean + অন্যান্য প্রসেসের (যেমন Zygote বুট ইমেজ) সাথে শেয়ার করা মেমরির আপনার প্রসেসের ইকুইটেবল শেয়ার। "এই অ্যাপ কতটা মেমরি ব্যবহার করছে" তা জানার জন্য এটিই হল সেরা মেট্রিক।
  • প্রাইভেট ডার্টি: এটি হল RAM যা শুধুমাত্র আপনার প্রসেস ব্যবহার করছে এবং পরিবর্তন করা হয়েছে (বা এটি হল পরিচয় গোপন রাখা মেমরি)। লিক খুঁজে পাওয়ার জন্য এটি সবচেয়ে গুরুত্বপূর্ণ সংখ্যা কারণ এই মেমরি ড্রপ করা যাবে না।
  • প্রাইভেট ক্লিন: RAM যা শুধুমাত্র আপনার প্রসেস ব্যবহার করছে, কিন্তু স্টোরেজে থাকা ফাইলের একটি অপরিবর্তিত কপি (যেমন DEX ফাইল)। মেমরি কম থাকলে OS এটি ড্রপ করতে পারে।
  • SwapPss: মেমরি যা কম্প্রেস করা হয়েছে এবং ZRAM-এ সোয়্যাপ করা হয়েছে। এটি হতে পারে কারণ সিস্টেম মেমরি কম আছে অথবা Android Runtime ব্যাকগ্রাউন্ড প্রসেস শনাক্ত করেছে (তাদের অব্যবহৃত বা নিষ্ক্রিয় পৃষ্ঠা ZRAM-এ সরিয়ে নিয়ে যাওয়া)। dumpsys উদাহরণে, প্রায় সব Native Heap এবং Dalvik Heap ZRAM-এ সরানো হয়েছে।
  • অ্যাপের সারাংশ: বিস্তারিত সারিগুলিকে বোধগম্য বাকেটে একত্রিত করে একটি উচ্চ-স্তরের শ্রেণীকরণ।
  • অবজেক্ট: লিক হওয়া Activities ও ViewRootImpl ইনস্ট্যান্স ট্র্যাক করার জন্য উপযোগী। আপনি অ্যাপ থেকে বেরিয়ে এসে GC-কে জোর করলে, Activities গণনা ০-তে ফিরে আসা উচিত।

মেমরি বাজেট বিভাগ

Android 18 ও তার পরবর্তী ভার্সনে, dumpsys meminfo একটি অ্যাপ ডাম্প করার সময় মেমরি বাজেট বিভাগও প্রিন্ট করে। এই বিভাগটি প্রসেস ও সম্পূর্ণ অ্যাপের (প্যাকেজ) memcg পরিসংখ্যান পড়ে, তাই আপনাকে নিজে cgroup ফাইল খুঁজতে হয় না। এখানে ফোরগ্রাউন্ডে MemoryLab স্যাম্পেল অ্যাপের বিভাগ দেখানো হয়েছে, Java মেমরি (১০এমবি) অ্যালোকেট করুন বিকল্পে তিনবার ট্যাপ করার পরে:

 Memory Budget
                        Process(KB)       Package(KB)
                        -----------       -----------
  Current Usage:              83820             87976
  Limit:                       none           4718592
  Limit Source:                none     MemoryLimiter
  Peak Usage:                 85136             89292
  Swap Used:                      0                 0

  Usage Breakdown
    Anonymous:                81700             81700
    File:                        96              4200
    File Mapped:                 16               616
    Shared Memory:               16                16
    Kernel:                    1580              1632
    Page Tables:                640               640
    Slab:                       439               458

  Pressure & Reclaim
    Throttle Events:              0                 0
    Refaults (Anon):              0                 0
    Refaults (File):              0                 0
  • বর্তমান ব্যবহার: memcg (memory.current)-এ চার্জ করা মেমরি। এটি মেমরি বাজেটের সীমা। স্যাম্পেলে, তিনটি ১০ এমবি জাভা অ্যালোকেশনের পরে এটি প্রায় ৩৬,৭০০ কেবি বেড়েছে, যা মোট PSS-এর সাথে সামঞ্জস্যপূর্ণ। প্যাকেজের মোট সাইজ প্রসেসের মোট সাইজের চেয়ে বেশি, এমনকি সিঙ্গল-প্রসেস অ্যাপের ক্ষেত্রেও, যখন আগে রান করা ক্যাশে ফাইল পেজ এখনও রিক্লেম করা হয়নি।
  • সীমা: রিক্লেম থ্রেশহোল্ড (memory.high) যা বর্তমানে প্রযোজ্য, অথবা none যদি কোনওটি না থাকে। স্যাম্পেলে, প্যাকেজের সিস্টেম মেমরি সীমা আছে এবং প্রসেসের নিজস্ব কোনও সীমা নেই।
  • সীমার সোর্স: সীমা কোথা থেকে আসে। AndroidManifest হল একটি <memory-budget> যা অ্যাপ ম্যানিফেস্টে ঘোষণা করা হয়েছে, MemoryBudgetManager হল একটি বাজেট যা অ্যাপ রান টাইমে সেট করেছে, MemoryLimiter হল একটি সিস্টেম মেমরি সীমা এবং am memory-limiter হল একটি ম্যানুয়াল ওভাররাইড যা adb-এর সাথে সেট করা হয়েছে।
  • সর্বাধিক ব্যবহার: memcg তৈরি হওয়ার পর থেকে সর্বাধিক চার্জ (memory.peak)। এটি কার্নেলে N/A দেখায় যা এটিতে কাজ করে না।
  • সোয়্যাপের ব্যবহার: ZRAM-এ কম্প্রেস করা মেমরি (memory.swap.current)।
  • ব্যবহারের ব্রেকডাউন: memory.stat-এর প্রধান ফিল্ড, যেমন অ্যানোনিমাস ও ফাইল-ব্যাকড মেমরি।
  • Pressure & Reclaim: Throttle Events memcg কতবার তার memory.high সীমা অতিক্রম করেছে তা গণনা করে। রিফল্ট সেইসব পৃষ্ঠা গণনা করে যেগুলি সোয়্যাপ আউট বা সরিয়ে দেওয়া হয়েছে এবং পরে আবার প্রয়োজন হয়েছে। আপনি অ্যাপ ব্যবহার করার সময় এই সংখ্যাগুলি বেড়ে গেলে, অ্যাপের ওয়ার্কিং সেটের তুলনায় সীমা আরও কঠোর হয়।

-a বা -v ফ্ল্যাগ সহ, এই বিভাগে memory.stat এবং memory.events থেকে প্রতিটি র কাউন্টারও তালিকাভুক্ত করা হয়।

হাতে-কলমে অনুশীলন: meminfo-এর মাধ্যমে দ্রুত ট্রায়াজ

এই অনুশীলনে দেখানো হয়েছে যে বিভিন্ন ধরনের বরাদ্দ কীভাবে meminfo-এ দেখানো হয়।

  1. অ্যাপ লঞ্চ করুন:

    adb shell am start -W -n com.android.memorylab/.MainActivity

  2. বেসলাইন মেমরি চেক করা:

    adb shell dumpsys meminfo -s com.android.memorylab

    (-s ফ্ল্যাগ মেমরি বিভাগের একটি সংক্ষিপ্ত, সুনির্দিষ্ট সারাংশ প্রদান করে)।

  3. Java মেমরি বরাদ্দ করুন: অ্যাপে Java মেমরি বরাদ্দ করুন (১০এমবি) বোতামে ৩ বার ট্যাপ করুন।

  4. পরিবর্তন লক্ষ্য করুন: meminfo -s আবার রান করুন। আপনি Java Heap ভ্যালু প্রায় ৩০,০০০ কেবি (৩০ এমবি) বৃদ্ধি পেতে দেখবেন।

  5. নেটিভ মেমরি বরাদ্দ করুন: নেটিভ মেমরি বরাদ্দ করুন (১ জিবি ইনকম্প্রেসিবল) বোতামে একবার ট্যাপ করুন।

  6. পরিবর্তন লক্ষ্য করুন: meminfo -s আবার রান করুন। নেটিভ হিপ ভ্যালু এখন অনেক বেশি (~১,০০০,০০০ কেবি) দেখাতে হবে।

  7. memcg-এর সাথে তুলনা করুন (Android 18 এবং তার পরবর্তী যেকোনও ভার্সন): meminfo -s আউটপুটের শেষে মেমরি বাজেট বিভাগটি দেখুন। প্রতিটি অ্যালোকেশনের পরে মোট PSS-এর সাথে বর্তমান ব্যবহার বৃদ্ধি পায়, কারণ Java এবং নেটিভ অ্যালোকেশন, উভয়কেই অ্যাপের memcg-তে চার্জ করা হয়।

গ্লোবাল ভিউ

পুরো সিস্টেম জুড়ে মেমরির ব্যবহার দেখতে, এটি রান করুন:

adb shell dumpsys meminfo

এটি RAM ব্যবহারের একটি সারসংক্ষেপ প্রদান করে, যার মধ্যে মোট RAM, ফ্রি RAM এবং PSS দ্বারা সাজানো প্রসেসের একটি তালিকা অন্তর্ভুক্ত থাকে।

সিস্টেমের মূল মেট্রিক

  • ZRAM: RAM-এ কম্প্রেস করা সোয়াপ।
  • DMA-BUF: গ্রাফিক্স ও শেয়ার করা মেমরি বাফার। Android-এর আধুনিক ভার্সন UI রেন্ডার করার জন্য DMA-BUF ব্যাপকভাবে ব্যবহার করে। DMA-BUF-এর মোট সংখ্যা খুব বেশি হলে, /sys/kernel/debug/dma_buf/bufinfo ব্যবহার করে গ্রাফিক্স-ভারী প্রসেসগুলি তদন্ত করুন।
  • হারানো RAM: কার্নেল বা কোনও প্রসেসের মাধ্যমে যে মেমরি হিসেব করা হয় না (যেমন, হার্ডওয়্যার-সংরক্ষিত অঞ্চল)।

memcg পরিসংখ্যান

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

/proc/<PID>/cgroup-এর 0:: লাইন থেকে কোনও প্রসেসের memcg পাথ দেখুন নিজেই পাথ তৈরি করার পরিবর্তে, কারণ 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.swap.current: ZRAM-এ কম্প্রেস করা মেমরি, বাইটে।
  • memory.stat: চার্জের ব্রেকডাউন, সাইজের জন্য বাইটে। anon হল বেনামী মেমরি, যেমন Java এবং নেটিভ হিপ। file হল ফাইল-ব্যাকড পেজ ক্যাশে, যেমন কোড এবং রিসোর্স। workingset_refault_anon এবং workingset_refault_file সেইসব পৃষ্ঠা গণনা করে যেগুলি সোয়্যাপ আউট বা এভিক্ট করা হয়েছে এবং তারপরে আবার প্রয়োজন হয়েছে। রিফল্ট কাউন্ট বেড়ে যাওয়ার অর্থ হল প্রসেসটির জন্য মেমরি কম পড়ছে।
  • memory.events: মেমরি লিমিট ইভেন্টের সংখ্যা। high গণনা করে যে কতবার প্রসেসটি তার memory.high সীমা অতিক্রম করার জন্য থ্রটল করা হয়েছে।

প্রসেস memcg-এর পেরেন্ট ডিরেক্টরি সম্পূর্ণ অ্যাপের (এর UID) অন্তর্গত। এর ফাইলের মধ্যে অ্যাপের সব প্রসেস চালানোর মেমরি, সাথে অ্যাপের আগের প্রসেস থেকে ছেড়ে যাওয়া ক্যাশে করা ফাইল পৃষ্ঠা যা বন্ধ হয়ে গেছে এবং এখনও রিক্লেম করা হয়নি:

adb shell "cat $CG/../memory.current"

অনুমতি সংক্রান্ত কোনও সমস্যা হলে, adb root রান করে আবার চেষ্টা করুন। কিছু ডিভাইসে শুধুমাত্র রুট হিসেবে এইসব ফাইল পড়তে পারবেন।

MemoryLab স্যাম্পেল অ্যাপের মাধ্যমে এইসব ফাইলের গাইডেড ওয়াকথ্রু পেতে, হ্যান্ডস-অন এক্সারসাইজ: memcg এক্সপ্লোর করা দেখুন।

ম্যাপ দেখান

কোনও প্রসেসের মেমরি ম্যাপিংয়ের আরও বিস্তারিত ব্রেকডাউন পেতে, showmap ব্যবহার করুন। এই টুল /proc/<pid>/smaps থেকে পড়ে।

adb shell showmap <pid>

showmap প্রসেসে প্রতিটি মেমরি ম্যাপ তালিকাভুক্ত করে। যেসব কী ম্যাপিং খুঁজতে হবে তার মধ্যে এগুলি পড়ে:

  • [anon:scudo:primary] বা [anon:libc_malloc]: নেটিভ হিপ। Android-এর আধুনিক ভার্সন Scudo অ্যালোকেটর ব্যবহার করে।
  • *.art: Java হিপ ইমেজ (যেমন, বুট ইমেজ)।
  • [anon:dalvik-main space]: প্রধান Java হিপ।
  • *.so: শেয়ার করা লাইব্রেরি।
  • *.{oat,dex,odex,vdex}: কম্পাইল করা DEX কোড।

সবচেয়ে বেশি ব্যক্তিগত মেমরি ব্যবহারকারী খুঁজে পেতে আপনি আউটপুট সাজাতে পারেন:

# Sort by private clean + private dirty memory
adb shell showmap <pid> | awk '{print $6+$7, $0}' | sort -rn | head -n 10

স্যাম্পেল আউটপুট:

 virtual                     shared   shared  private  private                   Anon      Shmem     File      Shared   Private
    size      RSS      PSS    clean    dirty    clean    dirty     swap  swapPSS HugePages PmdMapped PmdMapped Hugetlb  Hugetlb    Locked    # object
-------- -------- -------- -------- -------- -------- -------- -------- -------- --------- --------- --------- -------- -------- -------- ---- ------------------------------
2776    18176     5784     2823        0     3008      308     2468     4700     4700         0         0         0        0        0        0   47 [anon:scudo:primary]
560      952      876      657      316        0      560        0       12       12         0         0         0        0        0        0    8 /data/app/.../base.apk
448   393216      448      448        0        0        0      448        0        0         0         0         0        0        0        0    2 [anon:dalvik-main space]
...

হাতে-কলমে অনুশীলন: showmap-এর সাথে ডিপ ডাইভ

নির্দিষ্ট মেমরি ম্যাপিং কীভাবে শনাক্ত করতে হয় এবং ক্লিন ও ডার্টি মেমরির মধ্যে পার্থক্য কীভাবে করতে হয় তা জানুন।

  1. Mmap ক্লিন মেমরি: MemoryLab অ্যাপে একবার Mmap ক্লিন অ্যানন মেমরি (১০এমবি) বোতামে ট্যাপ করুন।

  2. প্রসেস আইডি পান: অ্যাপের UI-তে PID দেখা যায়। এছাড়াও, আপনি এই কমান্ডের সাহায্যে এটি খুঁজে পেতে পারেন:

    adb shell pidof com.android.memorylab

  3. showmap-এর মাধ্যমে পরীক্ষা করা:

    # Replace <PID> with the actual process ID from the previous step
adb shell showmap <PID> | grep "memorylab-clean"

  4. ম্যাপিং শনাক্ত করা: আপনি একটি বেনামী ম্যাপিং দেখতে পাবেন যার লেবেল হল [anon:memorylab-clean] এবং ভার্চুয়াল সাইজ হল ঠিক ১০২৪০ কেবি। মনে রাখবেন যে এই ম্যাপের জন্য প্রাইভেট ডার্টি ভ্যালু সম্ভবত ০। এটি "ক্লিন" অ্যানোনিমাস মেমরি কারণ আমরা ভার্চুয়াল স্পেস রিজার্ভ করার জন্য mmap ব্যবহার করেছি কিন্তু এখনও এতে কিছু লিখিনি (তাই কোনও ফিজিক্যাল RAM আসলে ব্যবহার করা হয়নি)।

  5. নেটিভ হিপ তুলনা: [anon:scudo:primary]-এর সাথে এটির তুলনা করুন ম্যাপিং যা showmap-এ দেখা যেত যদি আপনি meminfo অনুশীলনের ৫ নম্বর ধাপের পরে এটি রান করতেন। কারণ ১ জিবি নেটিভ অ্যালোকেশন আসলে প্রতিটি পৃষ্ঠায় লেখে, সেই পৃষ্ঠাগুলি "ডার্টি" এবং প্রাইভেট ডার্টি কলামে অনেক বেশি দেখাবে।

  6. প্রো-টিপ (বড় অবজেক্ট): meminfo অনুশীলন থেকে Java Heap অ্যালোকেশন লক্ষ্য করুন। যেহেতু এগুলি ১০ এমবি বাইট অ্যারে, তাই সম্ভবত এগুলি showmap-এ [anon:dalvik-free list large object space] হিসেবে দেখা যায়। Android Runtime (ART) ১২ কেবির চেয়ে বড় অবজেক্টকে আলাদা লার্জ অবজেক্ট স্পেসে (LOS) রাখে যাতে মূল হিপে ফ্র্যাগমেন্টেশন এড়ানো যায়।

procstats

meminfo একটি নির্দিষ্ট সময়ের স্ন্যাপশট প্রদান করে, procstats সমস্ত চলমান অ্যাপ্লিকেশনের অবস্থা এবং মেমরি ব্যবহারের পর্যায়ক্রমিক স্যাম্পেলিং করে ঐতিহাসিক ডেটা প্রদান করে। এটি হল দীর্ঘমেয়াদী মেমরি হেলথ মনিটর করার জন্য ব্যবহৃত প্রাথমিক টুল এবং এটি Android সেটিংসে মেমরির ব্যবহার সংক্রান্ত রিপোর্টিং পরিচালনা করে।

# View stats for the last 3 hours
adb shell dumpsys procstats --hours 3

স্ট্যাটাস সম্পর্কে বোঝা

procstats-এর আউটপুট অনেক বেশি হতে পারে। সবচেয়ে গুরুত্বপূর্ণ অংশ হল প্রতিটি প্রসেস স্টেটমেন্টের পাশে বন্ধনীতে থাকা মেট্রিক:

Top: 100% (54MB-64MB-67MB / 49MB-58MB-61MB / 110MB-120MB-130MB over 4)

ফর্ম্যাটটি হল: (% time in state) (minPss-avgPss-maxPss / minUss-avgUss-maxUss / minRss-avgRss-maxRss over samples)

  • Pss (প্রোপোরশনাল সেট সাইজ): শেয়ার করা মেমরি প্রসেসের মধ্যে সমানুপাতিকভাবে ভাগ করা হয়।
  • Uss (ইউনিক সেট সাইজ): শুধুমাত্র এই প্রসেসের মাধ্যমে ব্যবহার করা মেমরি (প্রাইভেট ক্লিন + প্রাইভেট ডার্টি-এর সমতুল্য)।
  • Rss (রেসিডেন্ট সেট সাইজ): ব্যবহৃত মোট ফিজিক্যাল মেমরি, যার মধ্যে সব শেয়ার করা পৃষ্ঠা অন্তর্ভুক্ত (বেশি গণনা করার প্রবণতা থাকে)।

এটি কেন গুরুত্বপূর্ণ:

  • স্টেবল অ্যাপ: সর্বনিম্ন/গড়/সর্বোচ্চ কাছাকাছি।
  • মেমরি লিক: সর্বোচ্চ মান সর্বনিম্ন মানের থেকে অনেক বেশি এবং স্যাম্পলের সংখ্যা বাড়ার সাথে সাথে গড় মান সময়ের সাথে সাথে ধীরে ধীরে বৃদ্ধি পায়।
  • স্পাইকি ব্যবহার: সর্বাধিক ব্যবহার গড়ের চেয়ে অনেক বেশি, যা ক্ষণস্থায়ী ভারী অপারেশন (যেমন ইমেজ প্রসেসিং) নির্দেশ করে, যা ভুল সময়ে হলে OOM হতে পারে।

প্রসেসের স্ট্যাটাস

procstats বেশ কয়েকটি রাজ্যের (প্রায়ই সংক্ষিপ্ত আকারে লেখা হয়) অ্যাপ ট্র্যাক করে:

  • পারসিস্ট: সিস্টেমের গুরুত্বপূর্ণ প্রসেস যা সবসময় চলতে থাকে।
  • টপ: অ্যাপটি বর্তমানে ফোরগ্রাউন্ডে আছে এবং ব্যবহারকারী দেখতে পাচ্ছেন।
  • ImpFg (গুরুত্বপূর্ণ ফোরগ্রাউন্ড): গুরুত্বপূর্ণ ব্যাকগ্রাউন্ড প্রসেস (যেমন IME) বা ফোরগ্রাউন্ড পরিষেবা সহ অ্যাপ।
  • ImpBg (গুরুত্বপূর্ণ ব্যাকগ্রাউন্ড): ব্যাকগ্রাউন্ড প্রসেস যা সিস্টেমের জন্য গুরুত্বপূর্ণ বলে বিবেচনা করা হয়।
  • Fgs / BFgs: ফোরগ্রাউন্ড সার্ভিস বা বাউন্ড ফোরগ্রাউন্ড সার্ভিস।
  • Service / ServRst: ব্যাকগ্রাউন্ড পরিষেবা বা বর্তমানে রিস্টার্ট হচ্ছে এমন পরিষেবা।
  • Cached / LastAct: দ্রুত রিস্টার্ট করার জন্য ব্যাকগ্রাউন্ডে ক্যাশে করা অ্যাপ। সিস্টেমের পক্ষে এগুলি বন্ধ করা নিরাপদ।

ডিভাইসের মেমরি স্ট্যাটাস ও রান টাইম স্ট্যাটাস

procstats-ও ট্র্যাক করে যে পুরো ডিভাইস মেমরি প্রেসারের মধ্যে কতটা সময় কাটিয়েছে। রান টাইম পরিসংখ্যান বিভাগটি দেখুন:

Run time Stats:
  SOff/Norm: +1h10m15s
   SOn/Norm: +15m20s
        Low: +2m10s
       Crit: +45s
  • SOff / SOn: স্ক্রিন বন্ধ বনাম স্ক্রিন চালু।
  • Norm / Mod / Low / Crit: মেমরি প্রেসার লেভেল (স্বাভাবিক, মাঝারি, কম, গুরুতর)।

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

← কনসেপ্ট | ↑ উপরে | Java →