क्विक आकलन टूल

जब आपको मेमोरी के इस्तेमाल की जांच करनी हो, तो हाई-लेवल असेसमेंट टूल से शुरुआत करें. इससे यह पता चलता है कि मेमोरी की कौनसी कैटगरी सबसे अहम हैं.

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 बूट इमेज. यह जानने के लिए कि "यह ऐप्लिकेशन कितनी मेमोरी का इस्तेमाल कर रहा है", यह सबसे सही मेट्रिक है.
  • प्राइवेट डर्टी: यह ऐसी रैम होती है जिसका इस्तेमाल सिर्फ़ आपकी प्रोसेस करती है और जिसमें बदलाव किया गया है (या यह ऐसी मेमोरी है जिसका नाम नहीं है). लीक का पता लगाने के लिए, यह सबसे अहम संख्या है. ऐसा इसलिए, क्योंकि इस मेमोरी को हटाया नहीं जा सकता.
  • प्राइवेट क्लीन: ऐसी रैम जिसका इस्तेमाल सिर्फ़ आपकी प्रोसेस कर रही है. हालांकि, यह स्टोरेज में मौजूद किसी फ़ाइल (जैसे, DEX फ़ाइल) की ऐसी कॉपी होती है जिसमें कोई बदलाव नहीं किया गया है. अगर मेमोरी कम है, तो ओएस इसे बंद कर सकता है.
  • SwapPss: ऐसी मेमोरी जिसे कंप्रेस करके ZRAM में स्वैप किया गया है. ऐसा तब हो सकता है, जब सिस्टम में मेमोरी कम हो या Android रनटाइम ने बैकग्राउंड में चल रही प्रोसेस की पहचान की हो. ऐसा इसलिए किया जाता है, ताकि इस्तेमाल न किए जा रहे या इनऐक्टिव पेजों को ZRAM में ले जाकर, मेमोरी को कंपैक्ट किया जा सके. dumpsys के उदाहरण में, करीब-करीब सभी Native Heap और Dalvik Heap को ZRAM में ले जाया गया है.
  • ऐप्लिकेशन की खास जानकारी: इसमें ज़्यादा जानकारी वाली लाइनों को आसानी से समझ में आने वाली कैटगरी में बांटकर, बेहतर तरीके से कैटगरी बनाई जाती है.
  • Objects: यह लीक हुए Activities और ViewRootImpl इंस्टेंस को ट्रैक करने के लिए काम का है. अगर ऐप्लिकेशन से बाहर निकलकर GC को फ़ोर्स किया जाता है, तो Activities की संख्या 0 पर वापस आ जानी चाहिए.

मेमोरी बजट सेक्शन

Android 18 और इसके बाद के वर्शन में, dumpsys meminfo किसी ऐप्लिकेशन को डंप करते समय मेमोरी बजट सेक्शन भी प्रिंट करता है. यह सेक्शन, प्रोसेस और पूरे ऐप्लिकेशन (पैकेज) के memcg के आंकड़े पढ़ता है. इसलिए, आपको cgroup फ़ाइलें खुद ढूंढने की ज़रूरत नहीं पड़ती. यहां MemoryLab के सैंपल के तौर पर मिले ऐप्लिकेशन का वह सेक्शन दिया गया है जो फ़ोरग्राउंड में है. यह सेक्शन, Allocate Java Memory (10MB) पर तीन बार टैप करने के बाद दिखता है:

 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) को चार्ज की गई मेमोरी. यह वह संख्या है जो मेमोरी बजट को सीमित करती है. सैंपल में, 10 एमबी के तीन Java ऐलोकेशन के बाद,यह करीब 36, 700 केबी बढ़ गया. यह कुल पीएसएस के मुताबिक है. पैकेज का कुल साइज़, प्रोसेस के कुल साइज़ से ज़्यादा होता है. ऐसा तब भी होता है, जब सिंगल-प्रोसेस ऐप्लिकेशन के लिए, पहले से कैश मेमोरी में सेव किए गए फ़ाइल पेजों को अब तक वापस नहीं लिया गया हो.
  • सीमा: फ़िलहाल लागू होने वाली, फिर से दावा करने की थ्रेशोल्ड (memory.high) या अगर कोई थ्रेशोल्ड नहीं है, तो none. सैंपल में, पैकेज के लिए सिस्टम मेमोरी की सीमा तय की गई है. हालांकि, प्रोसेस के लिए कोई सीमा तय नहीं की गई है.
  • Limit Source: इससे पता चलता है कि सीमा कहां से तय की गई है. 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. जावा मेमोरी असाइन करें: ऐप्लिकेशन में, जावा मेमोरी असाइन करें (10 एमबी) बटन को तीन बार टैप करें.

  4. बदलाव देखें: meminfo -s को फिर से चलाएं. आपको Java हीप की वैल्यू में करीब 30,000 केबी (30 एमबी) की बढ़ोतरी दिखेगी.

  5. नेटिव मेमोरी असाइन करें: नेटिव मेमोरी असाइन करें (1 जीबी, जिसे कंप्रेस नहीं किया जा सकता) बटन पर एक बार टैप करें.

  6. बदलाव देखें: meminfo -s को फिर से चलाएं. नेटिव हीप की वैल्यू में अब काफ़ी बढ़ोतरी (~10,00,000 केबी) दिखनी चाहिए.

  7. memcg से तुलना करना (Android 18 और इसके बाद के वर्शन): meminfo -s आउटपुट के आखिर में मौजूद मेमोरी बजट सेक्शन देखें. हर बार मेमोरी ऐलोकेट होने के बाद, TOTAL PSS के साथ-साथ Current Usage भी बढ़ता है. ऐसा इसलिए होता है, क्योंकि Java और नेटिव ऐलोकेशन, दोनों को ऐप्लिकेशन के memcg से चार्ज किया जाता है.

ग्लोबल व्यू

पूरे सिस्टम में मेमोरी के इस्तेमाल की जानकारी देखने के लिए, यह कमांड चलाएं:

adb shell dumpsys meminfo

इससे रैम के इस्तेमाल की खास जानकारी मिलती है. इसमें कुल रैम, खाली रैम, और पीएसएस के हिसाब से क्रम में लगाई गई प्रोसेस की सूची शामिल होती है.

सिस्टम की मुख्य मेट्रिक

  • ZRAM: रैम में कंप्रेस किया गया स्वैप.
  • डीएमए-बीयूएफ़: ग्राफ़िक्स और शेयर किए गए मेमोरी बफ़र. Android के नए वर्शन, यूज़र इंटरफ़ेस (यूआई) रेंडर करने के लिए, डीएमए-बीयूएफ़ का बड़े पैमाने पर इस्तेमाल करते हैं. अगर DMA-BUF का कुल साइज़ बहुत ज़्यादा है, तो /sys/kernel/debug/dma_buf/bufinfo का इस्तेमाल करके, ग्राफ़िक-हैवी प्रोसेस की जांच करें.
  • लॉस्ट रैम: ऐसी मेमोरी जिसका हिसाब कर्नल या किसी प्रोसेस में नहीं रखा जाता. उदाहरण के लिए, हार्डवेयर के लिए रिज़र्व की गई मेमोरी.

memcg के आंकड़े

हर ऐप्लिकेशन प्रोसेस का अपना मेमोरी कंट्रोल ग्रुप (memcg) होता है. साथ ही, कर्नल उस मेमोरी का कुल हिसाब रखता है जो उसे चार्ज की जाती है. यह जानने के लिए कि यह हिसाब आरएसएस और पीएसएस से कैसे अलग है, 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 की पैरंट डायरेक्ट्री, पूरे ऐप्लिकेशन (इसके यूआईडी) से जुड़ी होती है. इसकी फ़ाइलों में, ऐप्लिकेशन की चल रही सभी प्रोसेस की मेमोरी शामिल होती है. साथ ही, इसमें ऐप्लिकेशन की उन पिछली प्रोसेस से बची हुई कैश मेमोरी में सेव की गई फ़ाइल के पेज भी शामिल होते हैं जो बंद हो चुकी हैं और जिन्हें अब तक वापस नहीं लिया गया है:

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

अगर आपको अनुमति से जुड़ी कोई गड़बड़ी मिलती है, तो adb root चलाएं और फिर से कोशिश करें. कुछ डिवाइसों पर, इन फ़ाइलों को सिर्फ़ रूट के तौर पर पढ़ा जा सकता है.

MemoryLab के सैंपल के तौर पर मिले ऐप्लिकेशन की मदद से, इन फ़ाइलों के बारे में सिलसिलेवार तरीके से जानने के लिए, हैंड्स-ऑन एक्सरसाइज़: memcg को एक्सप्लोर करना देखें.

showmap

किसी प्रोसेस की मेमोरी मैपिंग के बारे में ज़्यादा जानकारी पाने के लिए, 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 Clean Memory: MemoryLab ऐप्लिकेशन में, Mmap Clean Anon Memory (10MB) बटन पर एक बार टैप करें.

  2. प्रोसेस आईडी पाना: ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में उसका पीआईडी दिखता है. इस निर्देश की मदद से भी इसे ढूंढा जा सकता है:

    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] लेबल वाली एक ऐसी मैपिंग दिखनी चाहिए जिसकी पहचान ज़ाहिर न की गई हो. साथ ही, उसका वर्चुअल साइज़ ठीक 10240 केबी होना चाहिए. ध्यान दें कि इस मैप के लिए, प्राइवेट डर्टी वैल्यू 0 हो सकती है. यह "क्लीन" एनॉनिमस मेमोरी है, क्योंकि हमने वर्चुअल स्पेस को रिज़र्व करने के लिए mmap का इस्तेमाल किया है. हालांकि, हमने अब तक इसमें कुछ भी नहीं लिखा है. इसलिए, असल में कोई फ़िज़िकल रैम इस्तेमाल नहीं की गई है.

  5. नेटिव हीप की तुलना: इसकी तुलना [anon:scudo:primary] मैपिंग से करें, जो meminfo एक्सरसाइज़ के पांचवें चरण के बाद चलाने पर, showmap में दिखती. नेटिव ऐलोकेशन के लिए इस्तेमाल की गई 1 जीबी मेमोरी, असल में हर पेज पर डेटा सेव करती है. इसलिए, वे पेज "डर्टी" होते हैं और प्राइवेट डर्टी कॉलम में ज़्यादा दिखेंगे.

  6. प्रो-टिप (बड़े ऑब्जेक्ट): meminfo एक्सरसाइज़ से Java Heap ऐलोकेशन पर ध्यान दें. ये 10 एमबी के बाइट कलेक्शन हैं. इसलिए, ये showmap में [anon:dalvik-free list large object space] के तौर पर दिख सकते हैं. Android रनटाइम (एआरटी), 12 केबी से बड़े ऑब्जेक्ट को एक अलग लार्ज ऑब्जेक्ट स्पेस (एलओएस) में रखता है. इससे मुख्य हीप में फ़्रैगमेंटेशन से बचा जा सकता है.

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)

  • पीएसएस (प्रोपोर्शनल सेट साइज़): शेयर की गई मेमोरी को प्रोसेस के बीच, अनुपात के हिसाब से बांटा जाता है.
  • यूएसएस (यूनीक सेट साइज़): सिर्फ़ इस प्रोसेस के लिए इस्तेमाल की गई मेमोरी (प्राइवेट क्लीन + प्राइवेट डर्टी के बराबर).
  • आरएसएस (रेज़िडेंट सेट साइज़): इस्तेमाल की गई कुल फ़िज़िकल मेमोरी. इसमें शेयर किए गए सभी पेज शामिल हैं. इसमें मेमोरी की गिनती ज़्यादा हो सकती है.

यह ज़रूरी क्यों है:

  • स्टेबल ऐप्लिकेशन: कम से कम, औसत, और ज़्यादा से ज़्यादा वैल्यू एक-दूसरे के करीब होती हैं.
  • मेमोरी लीक: ज़्यादा से ज़्यादा वैल्यू, कम से कम वैल्यू से काफ़ी ज़्यादा है. साथ ही, सैंपल की संख्या बढ़ने के साथ-साथ औसत वैल्यू भी बढ़ती जाती है.
  • इस्तेमाल में अचानक बढ़ोतरी: ज़्यादा से ज़्यादा इस्तेमाल, औसत इस्तेमाल से काफ़ी ज़्यादा है. इससे पता चलता है कि इमेज प्रोसेसिंग जैसे कुछ समय के लिए होने वाले भारी-भरकम ऑपरेशन की वजह से, ओओएम की समस्या हो सकती है. ऐसा तब होता है, जब ये ऑपरेशन गलत समय पर होते हैं.

प्रोसेस की स्थितियां

procstats, कई राज्यों में ऐप्लिकेशन ट्रैक करता है. अक्सर, इन राज्यों के नाम के लिए शॉर्ट फ़ॉर्म का इस्तेमाल किया जाता है:

  • Persist: सिस्टम की ऐसी ज़रूरी प्रोसेस जो हमेशा चलती रहती हैं.
  • सबसे ऊपर: ऐप्लिकेशन फ़िलहाल फ़ोरग्राउंड में है और उपयोगकर्ता को दिख रहा है.
  • ImpFg (ज़रूरी फ़ोरग्राउंड): बैकग्राउंड में चल रही ज़रूरी प्रोसेस (जैसे, आईएमई) या फ़ोरग्राउंड सेवा वाले ऐप्लिकेशन.
  • ImpBg (ज़रूरी बैकग्राउंड): बैकग्राउंड में चल रही ऐसी प्रोसेस जिन्हें सिस्टम के लिए ज़रूरी माना जाता है.
  • Fgs / BFgs: फ़ोरग्राउंड सेवाएं या बाउंड फ़ोरग्राउंड सेवाएं.
  • Service / ServRst: बैकग्राउंड में चलने वाली सेवाएं या फ़िलहाल रीस्टार्ट हो रही सेवाएं.
  • कैश मेमोरी में सेव किए गए / LastAct: ऐसे ऐप्लिकेशन जो बैकग्राउंड में कैश मेमोरी में सेव किए गए हैं, ताकि उन्हें तुरंत रीस्टार्ट किया जा सके. सिस्टम के लिए, इन्हें बंद करना सुरक्षित होता है.

डिवाइस की मेमोरी की स्थिति और रन टाइम के आंकड़े

procstats यह भी ट्रैक करता है कि पूरे डिवाइस ने मेमोरी प्रेशर में कितना समय बिताया. रन टाइम के आंकड़े सेक्शन ढूंढें:

Run time Stats:
  SOff/Norm: +1h10m15s
   SOn/Norm: +15m20s
        Low: +2m10s
       Crit: +45s
  • SOff / SOn: स्क्रीन बंद होने और स्क्रीन चालू होने के बीच का अंतर.
  • Norm / Mod / Low / Crit: मेमोरी प्रेशर लेवल (सामान्य, मॉडरेट, कम, गंभीर).

अगर कोई डिवाइस कम या बहुत कम मेमोरी वाली स्थितियों में ज़्यादा समय बिताता है, तो वह धीमा काम करेगा. ऐसा इसलिए होता है, क्योंकि कर्नेल तेज़ी से मेमोरी को वापस लेता है और लो मेमोरी किलर (एलएमके) बैकग्राउंड में चल रही प्रोसेस को बंद करना शुरू कर देता है. इसके बाद, हर पैकेज के आंकड़े देखकर यह पता लगाया जा सकता है कि डिवाइस पर ज़्यादा लोड होने पर, किन ऐप्लिकेशन ने मेमोरी का ज़्यादा इस्तेमाल किया.

← कॉन्सेप्ट | ↑ ऊपर | Java →