मेमोरी के इस्तेमाल की निगरानी करना

अपने गेम की मेमोरी फ़ुटप्रिंट को बेहतर तरीके से ऑप्टिमाइज़ करने के लिए, आपको सबसे पहले यह समझना होगा कि Android प्लैटफ़ॉर्म, मेमोरी को कैसे मेज़र करता है. साथ ही, सिस्टम टेलीमेट्री, डाइग्नोस्टिक एपीआई, और प्रोफ़ाइलिंग टूल का इस्तेमाल कैसे किया जाता है. इस गाइड में, नए प्लैटफ़ॉर्म के दिशा-निर्देशों के तहत, आपके गेम के मेमोरी असाइनमेंट को मॉनिटर करने, कैप्चर करने, और उसका विश्लेषण करने के तरीके के बारे में बताया गया है.

आरएसएस और स्वैप मेट्रिक को समझना

अपने गेम की मेमोरी के इस्तेमाल का बेहतर तरीके से विश्लेषण करने और उसे डीबग करने के लिए, आपको उन तकनीकी मेट्रिक के बारे में सटीक जानकारी होनी चाहिए जिनका इस्तेमाल Android प्लैटफ़ॉर्म, मेमोरी के इस्तेमाल को लागू करने के लिए करता है. इस टेलीमेट्री पैरामीटर को कैसे प्रोसेस किया जाता है और इसकी निगरानी कैसे की जाती है, इस बारे में ज़्यादा जानकारी के लिए, Android की ज़रूरी जानकारी - मेमोरी का इस्तेमाल (नाम छिपाकर आरएसएस + स्वैप) दस्तावेज़ देखें.

1. बिना सोर्स फ़ाइल वाली आरएसएस मेमोरी (RssAnon)

रेज़िडेंट सेट साइज़ (आरएसएस) से, किसी प्रोसेस के लिए इस्तेमाल की गई मेमोरी के उस हिस्से का पता चलता है जो डिवाइस की फ़िज़िकल रैम में सेव होता है. आरएसएस को फ़ाइल-बैक मेमोरी और बिना सोर्स फ़ाइल वाली मेमोरी में बांटा जाता है. Android की नीति उल्लंघन ठीक करने से जुड़ी मेट्रिक, सिर्फ़ गुमनाम आरएसएस पर फ़ोकस करती है:

  • इसमें क्या शामिल है: मेमोरी पेज, जिन्हें सीधे तौर पर आपकी गेम प्रोसेस से असाइन किया जाता है. ये स्टोरेज में मौजूद किसी फ़िज़िकल फ़ाइल से लिंक नहीं होते. इन पेजों में Java या Kotlin हीप, थ्रेड एक्ज़ीक्यूशन स्टैक, और सबसे अहम, नेटिव मेमोरी के असाइनमेंट शामिल होते हैं. जैसे, कस्टम C++ इंजन ऐलोकेटर या नेटिव malloc या new का इस्तेमाल करके अनुरोध किए गए मेमोरी ब्लॉक और गेम लॉजिक से गंदे किए गए मेमोरी ब्लॉक. प्रोसेस मेमोरी (आरएसएस) डिक्शनरी में जाकर, इस मेट्रिक के बारे में ज़्यादा जानें.
  • यह क्यों ज़रूरी है: गेम इंजन, फ़िज़िक्स, रेंडरिंग, और लॉजिक को मैनेज करने के लिए, बड़े नेटिव मेमोरी पूल का इस्तेमाल करते हैं. इन पूल में फ़ाइलों का इस्तेमाल नहीं किया जाता. इसलिए, ये पूरी तरह से Anonymous RSS में मौजूद होते हैं. साथ ही, ये आपके गेम के फ़िज़िकल फ़ुಟ್‌प्रिंट का ज़्यादातर हिस्सा बनाते हैं.

2. बिना कंप्रेस किए स्वैप करना (VmSwap)

फ़्लैश स्टोरेज के इस्तेमाल और इंतज़ार के समय से जुड़ी पाबंदियों की वजह से, Android में डिस्क पर आधारित स्वैप स्पेस की सुविधा काम नहीं करती. इसके बजाय, यह zRAM (अनकंप्रेस्ड स्वैप) का इस्तेमाल करता है:

  • इसमें क्या शामिल है: जब फ़िज़िकल रैम पर दबाव बढ़ता है, तो कर्नल का मेमोरी मैनेजमेंट डेमॉन, इस्तेमाल न किए जा रहे गुमनाम पेजों को कंप्रेस करता है. इसके बाद, उन्हें फ़िज़िकल रैम (zRAM) के खास, अनकंप्रेस किए गए हिस्से में ले जाता है.
  • मेट्रिक का हिसाब: सिस्टम, इस मेट्रिक को बिना कंप्रेस किए गए साइज़ (VmSwap) के आधार पर ट्रैक करता है. इससे गेम की फ़िज़िकल मेमोरी की असल ज़रूरत का आकलन किया जाता है. अगर आपका गेम मेमोरी असाइन करता है और सिस्टम उसे zRAM में स्वैप करता है, तो भी उसे आपके गेम के कुल मेमोरी फ़ुटप्रिंट में गिना जाता है.

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

मेमोरी के इस्तेमाल को Android Vitals में प्रोसेस की स्थितियों के हिसाब से बांटा जाता है. गेम डेवलपर के लिए, तीसरे पक्ष के एसडीके या गेम भी उपयोगकर्ता को दिखने वाली सेवाओं या बैकग्राउंड सेवाओं को अचानक ट्रिगर कर सकते हैं.

  • इसमें क्या-क्या शामिल है: फ़ोरग्राउंड, परसेप्टिबल सेवाएं, बैकग्राउंड, और कैश मेमोरी में सेव किया गया डेटा.
  • यह क्यों ज़रूरी है: प्रोसेस की अलग-अलग स्थितियों का, Android OS की मेमोरी मैनेजमेंट पर अलग-अलग असर पड़ता है. ऐसा हो सकता है कि आपको यह पता न हो कि आपका गेम, संवेदनशील प्रोसेस स्टेट के साथ चल रहा है. ऐसा तब होता है, जब तीसरे पक्ष का कोई एसडीके अनजाने में बैकग्राउंड टास्क को ट्रिगर कर देता है. RunningAppProcessInfo का इस्तेमाल करके देखें कि आपका गेम बैकग्राउंड में चल रहा है या नहीं.

ऐप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एपीआई)

Android, सिस्टम एपीआई उपलब्ध कराता है. इनकी मदद से, आपका गेम मेमोरी की कमी की समस्या का डाइनैमिक तरीके से जवाब दे सकता है. साथ ही, रनटाइम के दौरान मेमोरी की परफ़ॉर्मेंस से जुड़ी ज़्यादा जानकारी कैप्चर कर सकता है.

मेमोरी ट्रिम करने से जुड़े इवेंट का जवाब देना

सिस्टम, onTrimMemory का इस्तेमाल करके आपके ऐप्लिकेशन को लाइफ़साइकल इवेंट की सूचना देता है. इससे आपके ऐप्लिकेशन को अपनी मेमोरी के इस्तेमाल को कम करने का अच्छा मौका मिलता है. साथ ही, लो-मेमोरी किलर (एलएमके) से बंद होने से बचने का मौका मिलता है, ताकि अन्य ऐप्लिकेशन मेमोरी का इस्तेमाल कर सकें.

अगर सिस्टम बैकग्राउंड में आपके ऐप्लिकेशन को बंद कर देता है, तो ऐप्लिकेशन को फिर से शुरू करने पर उपयोगकर्ता को कोल्ड स्टार्ट का अनुभव होता है. इसमें समय लगता है. बैकग्राउंड में मेमोरी का इस्तेमाल कम करने से, बैकग्राउंड में चल रहे ऐप्लिकेशन बंद होने की समस्या को रोकने में मदद मिलती है.

ट्रिम इवेंट का जवाब देते समय, मेमोरी के ऐसे बड़े हिस्से को रिलीज़ करें जिन्हें फिर से बनाया जा सकता है और जिनकी तुरंत ज़रूरत नहीं है:

  • उदाहरण: TRIM_MEMORY_UI_HIDDEN के जवाब में, कैश मेमोरी में सेव किए गए बिटमैप (लोकल स्टोरेज से डिकोड किए गए) को ट्रिम या हटाना.

Kotlin

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {
    override fun onTrimMemory(level: Int) {
        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }
        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

Java

public class MainActivity extends AppCompatActivity implements ComponentCallbacks2 {
    public void onTrimMemory(int level) {
        switch (level) {
            if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
                // Release memory related to UI elements, such as bitmap caches.
            }
            if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
                // Release memory related to background processing, such as by
                // closing a database connection.
            }
        }
    }
}

ProfilingManager

Android 15 (एपीआई लेवल 35) में पेश किया गया ProfilingManager एपीआई, ऐप्लिकेशन को प्रोग्राम के हिसाब से तय किए गए स्नैपशॉट (जैसे कि हीप प्रोफ़ाइल, सिस्टम ट्रेस, और Java हीप डंप) को सीधे तौर पर रनटाइम में कैप्चर करने की अनुमति देता है.

डेवलपर, खास सीन पर मैन्युअल तरीके से कैप्चर ट्रिगर कर सकते हैं. इसके अलावा, वे TRIGGER_TYPE_ANOMALY जैसे ऑटोमेटेड ट्रिगर रजिस्टर कर सकते हैं, ताकि गेम प्रोसेस के मेमोरी लिमिटर थ्रेशोल्ड का उल्लंघन करने पर, कैप्चर अपने-आप ट्रिगर हो जाए. हालांकि, गेम डेवलपर को मॉडर्न गेम इंजन की इन अहम सीमाओं का ध्यान रखना चाहिए:

ध्यान दें: Unity या Unreal जैसे मॉडर्न गेम इंजन, कर्नेल से बड़े वर्चुअल मेमोरी ब्लॉक को पहले से ही असाइन करके, एक्ज़ीक्यूशन की परफ़ॉर्मेंस को मैनेज करते हैं. इसके लिए, वे MAP_ANONYMOUS फ़्लैग के साथ mmap का इस्तेमाल करते हैं. इसके बाद, इंजन कस्टम सब-ऐलोकेटर का इस्तेमाल करते हैं. जैसे, Unity का नेटिव मेमोरी मैनेजर या Unreal का BinnedAllocators. इनका इस्तेमाल, मेमोरी ब्लॉक को अंदरूनी तौर पर बांटने और मेमोरी ब्लॉक असाइन करने के लिए किया जाता है.

ApplicationExitInfo

अगर आपका गेम बैकग्राउंड में बंद हो जाता है या अलग-अलग प्रोसेस की मेमोरी की सीमाओं का उल्लंघन करने की वजह से बंद हो जाता है, तो स्टैंडर्ड Java या नेटिव क्रैश डंप मैकेनिज़्म (जैसे कि Firebase Crashlytics) इवेंट को रजिस्टर नहीं करते हैं. इन खातों के बंद होने की जानकारी को क्वेरी करने और लॉग करने के लिए, डेवलपर को गेम शुरू होने पर ApplicationExitInfo एपीआई का इस्तेमाल करना चाहिए.

  • लागू करने का तरीका: शुरू होने पर, ActivityManager.getHistoricalProcessExitReasons() को कॉल करें, ताकि हाल के सेशन के बंद होने की वजहें मिल सकें.
  • यादें बंद होने की मुख्य वजहें:
    • REASON_LOW_MEMORY: इससे पता चलता है कि प्रोसेस को सिस्टम के Low Memory Killer (एलएमके) ने बंद किया था. ऐसा तब होता है, जब डिवाइस की मेमोरी पूरी तरह भरी हो और ओएस को रैम खाली करनी पड़े. इस वजह से गेम बंद होने का मतलब है कि बैकग्राउंड में आपके गेम का फ़ुटप्रिंट इतना बड़ा है कि यह अन्य ऐप्लिकेशन के साथ नहीं चल सकता.
    • REASON_MEMORY_LIMITER (Android 17 (एपीआई लेवल 37) और इसके बाद के वर्शन): इससे पता चलता है कि प्रोसेस को इसलिए बंद किया गया, क्योंकि यह प्लैटफ़ॉर्म के Memory Limiter की ओर से असाइन की गई cgroup मेमोरी की सीमा (RssAnon + VmSwap) से ज़्यादा हो गई थी. ऐसा तब भी हो सकता है, जब डिवाइस में काफ़ी फ़िज़िकल मेमोरी बची हो. इससे पता चलता है कि किसी प्रोसेस की सीमा का सीधे तौर पर उल्लंघन हुआ है.

उपलब्ध टूल इस्तेमाल करना

अपने गेम की मेमोरी के इस्तेमाल का सटीक आकलन करने के लिए, डेवलपमेंट और क्वालिटी अश्योरेंस (QA) के दौरान यहां दिए गए प्लैटफ़ॉर्म टूल का इस्तेमाल करें.

meminfo

यह टूल, मेमोरी के आंकड़े इकट्ठा करता है. इससे यह पता चलता है कि पीएसएस मेमोरी कितनी थी और इसका इस्तेमाल किन कैटगरी के लिए किया गया था.

meminfo के आंकड़े प्रिंट करने के लिए, इनमें से कोई एक तरीका अपनाएं:

  • adb shell dumpsys meminfo package-name कमांड का इस्तेमाल करें.
  • Android Debug API से MemoryInfo कॉल का इस्तेमाल करें.

PrivateDirty आंकड़े से पता चलता है कि प्रोसेस में कितनी रैम है. इसे डिस्क पर पेज नहीं किया जा सकता और न ही इसे किसी अन्य प्रोसेस के साथ शेयर किया जा सकता है. जब यह प्रोसेस बंद हो जाती है, तब इस रकम का ज़्यादातर हिस्सा सिस्टम के लिए उपलब्ध हो जाता है.

मेमोरी ट्रेसपॉइंट

मेमोरी ट्रेसपॉइंट, यह ट्रैक करते हैं कि आपका गेम कितनी आरएसएस मेमोरी का इस्तेमाल कर रहा है. आरएसएस के लिए मेमोरी के इस्तेमाल का हिसाब लगाना, पीएसएस के लिए मेमोरी के इस्तेमाल का हिसाब लगाने से ज़्यादा तेज़ होता है. ऐसा इसलिए है, क्योंकि इसकी गणना तेज़ी से की जा सकती है. साथ ही, आरएसएस से मेमोरी के साइज़ में होने वाले बदलावों के बारे में ज़्यादा सटीक जानकारी मिलती है. इससे मेमोरी के ज़्यादा इस्तेमाल का ज़्यादा सटीक मेज़रमेंट किया जा सकता है. इसलिए, उन पीक को आसानी से देखा जा सकता है जिनकी वजह से गेम में आउट ऑफ़ मेमोरी की समस्या हो सकती है.

Perfetto

Perfetto, डिवाइस पर परफ़ॉर्मेंस और मेमोरी की जानकारी इकट्ठा करने और उसे वेब-आधारित यूज़र इंटरफ़ेस (यूआई) में दिखाने वाले टूल का एक सुइट है. यह लंबे से लंबे ट्रेस को सपोर्ट करता है, ताकि यह देखा जा सके कि समय के साथ आरएसएस में कैसे बदलाव होता है. इसके अलावा, ऑफ़लाइन प्रोसेसिंग के लिए, इससे मिले डेटा पर SQL क्वेरी भी जारी की जा सकती हैं. सिस्टम ट्रेसिंग ऐप्लिकेशन से लंबे समय तक चलने वाले ट्रेस चालू करें. पक्का करें कि ट्रेस के लिए memory:Memory कैटगरी चालू हो. डेवलपमेंट और टेस्टिंग में कस्टम मेमोरी इंस्ट्रूमेंटेशन के लिए, (बीटा) heapprofd API का भी इस्तेमाल किया जा सकता है.

RssAnon की जांच करना और उसे Perfetto में बदलना

अपने गेम की ऐनॉनमस मेमोरी और zRAM स्वैप पर पड़ने वाले असर की जांच करने के लिए, अपनी ट्रेस फ़ाइल को ui.perfetto.dev पर मौजूद वेब-आधारित यूज़र इंटरफ़ेस (यूआई) में लोड करें. इसके बाद, मेमोरी से जुड़ी समस्याओं का पता लगाने के लिए डिज़ाइन की गई इन तकनीकों का इस्तेमाल करें. ज़्यादा जानकारी के लिए, Perfetto की मदद से मेमोरी का विश्लेषण करने से जुड़ी केस स्टडी देखें:

1. टाइमलाइन पर मेमोरी काउंटर को विज़ुअलाइज़ करना

  • अपनी प्रोसेस ढूंढें: नेविगेशन सूची में, अपने गेम के पैकेज या प्रोसेस का नाम खोजें.
  • ट्रैक ग्रुप को बड़ा करें: अपनी प्रोसेस की लाइन पर क्लिक करके, उसके थ्रेड ट्रैक को बड़ा करें. इसके बाद, मेमोरी नाम का सब-ग्रुप ढूंढें.
  • ट्रैक का विश्लेषण करें:
    • mem.rss.anon (बिना सोर्स फ़ाइल वाली आरएसएस मेमोरी): इस लाइन ग्राफ़ में, आपके गेम की बिना मैनेज की गई मेमोरी पूल के लिए इस्तेमाल की जा रही फ़िज़िकल रैम को रीयल-टाइम में दिखाया गया है. सीन लोड होने, यूआई पॉपअप होने या गेमप्ले ट्रांज़िशन के दौरान, इस टाइमलाइन पर नज़र रखें. इससे आपको यह पता चलेगा कि सीपीयू का इस्तेमाल कब ज़्यादा हो रहा है.
    • mem.swap (Compressed Swap or VmSwap): यह ग्राफ़, zRAM में ले जाए गए मेमोरी ब्लॉक के पहले से कंप्रेस किए गए साइज़ को दिखाता है. गेमप्ले के दौरान स्वैप करने की गतिविधि ज़्यादा होने से पता चलता है कि आपका गेम, सीमित मेमोरी वाले डिवाइस पर चल रहा है. साथ ही, सिस्टम बैकग्राउंड ऐसेट को कंप्रेस कर रहा है.

2. एसक्यूएल क्वेरी चलाना (ट्रेस प्रोसेसर) ऑफ़लाइन विश्लेषण के बारे में ज़्यादा जानकारी के लिए, Perfetto यूज़र इंटरफ़ेस (यूआई) कंसोल में सीधे तौर पर एसक्यूएल क्वेरी चलाई जा सकती हैं. इसके अलावा, आंकड़ों के हिसाब से सबसे ज़्यादा वैल्यू का पता लगाने के लिए, स्टैंडअलोन ट्रेस प्रोसेसर Python लाइब्रेरी का इस्तेमाल किया जा सकता है.

  • बिना सोर्स फ़ाइल वाली आरएसएस मेमोरी के सबसे ज़्यादा इस्तेमाल का पता लगाने के लिए:

    SELECT
  max(value) / 1024 / 1024 AS max_rss_anon_mb
FROM counter
JOIN counter_track ON counter.track_id = counter_track.id
WHERE counter_track.name = 'mem.rss.anon'
  AND counter_track.upid IN (
    SELECT upid FROM process WHERE name = 'your.game.package.name'
  );

  • किसी भी टाइमस्टैंप पर RssAnon और VmSwap को एक-दूसरे से जोड़ें:

    SELECT
  ts,
  track.name AS metric_type,
  value / 1024 / 1024 AS size_mb
FROM counter
JOIN counter_track track ON counter.track_id = track.id
WHERE (track.name = 'mem.rss.anon' OR track.name = 'mem.swap')
  AND track.upid IN (
    SELECT upid FROM process WHERE name = 'your.game.package.name'
  )
ORDER BY ts ASC;

Android Studio का इस्तेमाल करके ट्रेस फ़ाइलों की जांच करने के बारे में ज़्यादा जानने के लिए, सिस्टम ट्रेस की जांच करना: प्रोसेस मेमोरी (आरएसएस) लेख पढ़ें. स्क्रिप्टिंग मेमोरी प्रोफ़ाइलों के बारे में ज़्यादा जानने के लिए, नेटिव मेमोरी के इस्तेमाल को रिकॉर्ड करना लेख पढ़ें.

heapprofd

heapprofd, मेमोरी को ट्रैक करने वाला एक टूल है. यह Perfetto का हिस्सा है. यह टूल, मेमोरी लीक का पता लगाने में आपकी मदद कर सकता है. इसके लिए, यह दिखाता है कि malloc का इस्तेमाल करके मेमोरी कहां असाइन की गई थी. heapprofd को Python स्क्रिप्ट का इस्तेमाल करके शुरू किया जा सकता है. साथ ही, इस टूल का ओवरहेड कम होता है. इसलिए, यह MallocDebug जैसे अन्य टूल की तरह परफ़ॉर्मेंस पर असर नहीं डालता.

गड़बड़ी की रिपोर्ट

bugreport एक लॉगिंग टूल है. इससे यह पता लगाया जा सकता है कि आउट ऑफ़ मेमोरी होने की वजह से आपका गेम क्रैश हुआ है या नहीं. इस टूल का आउटपुट, logcat का इस्तेमाल करने के मुकाबले ज़्यादा जानकारी वाला होता है. यह मेमोरी डीबग करने के लिए काम का है. इससे पता चलता है कि आपका गेम आउट ऑफ़ मेमोरी होने की वजह से क्रैश हुआ है या LMK ने उसे बंद कर दिया है.

ज़्यादा जानकारी के लिए, बग रिपोर्ट कैप्चर करना और उन्हें पढ़ना लेख पढ़ें.

गेम इंजन टूल

ओएस के थ्रेशोल्ड और अनुपालन को ट्रैक करने के लिए, प्लैटफ़ॉर्म-लेवल के लॉग और सिस्टम टेलीमेट्री ज़रूरी होती है. वहीं, गेम इंजन के हिसाब से टूल, सीधे तौर पर आपके गेम ऑब्जेक्ट, स्क्रिप्ट के व्यवहार, और ऐक्टिव सीन के क्रम को एट्रिब्यूट करने में मदद करते हैं.

Unity

Unity Engine एनवायरमेंट में, Unity के नेटिव प्रोफ़ाइलिंग टूल और क्लास का इस्तेमाल करके, Android के ऐप्लिकेशन के लिए उपलब्ध कराई गई गुमनाम मेमोरी (ऐप्लिकेशन के लिए उपलब्ध कराई गई मेमोरी) + स्वैप मेमोरी के फ़ुटप्रिंट का अनुमान लगाया जा सकता है. यह अनुमान, रनटाइम के दौरान लगाया जाता है. साथ ही, यह अनुमान काफ़ी सटीक होता है. आम तौर पर, यह अनुमान ओएस-लेवल की सही वैल्यू की तुलना में 10% से कम अंतर दिखाता है.

कॉन्फ़िगरेशन के नियमों और रनटाइम स्क्रिप्ट के साथ-साथ, सिलसिलेवार तरीके से पूरा ट्यूटोरियल देखने के लिए, Unity टूल की मदद से मेमोरी की जांच कैसे करें लेख पढ़ें.

  • Unity profiler API: कोर इंजन मेट्रिक के लिए क्वेरी करके, रनटाइम के दौरान अपने गेम के अनमैनेज्ड मेमोरी फ़ुटप्रिंट का अनुमान लगाया जा सकता है. इसके लिए, कंप्यूटर प्रोग्राम का इस्तेमाल किया जा सकता है:
    • Profiler क्लास का इस्तेमाल करना: Profiler.GetTotalReservedMemoryLong() और Profiler.GetMonoHeapSizeLong() की वैल्यू जोड़कर, कुल मेमोरी के बंटवारे को ट्रैक करें.
    • ProfilerRecorder क्लास का इस्तेमाल करना: मेमोरी कैटगरी को डाइनैमिक तरीके से मॉनिटर करें. भरोसेमंद बेसलाइन का अनुमान लगाने के लिए, रिलीज़ बिल्ड पर कुल रिज़र्व की गई मेमोरी फ़ेच करें. इसके अलावा, डेवलपमेंट बिल्ड पर फ़ाइल-बैक की गई ग्राफ़िक्स मेमोरी कॉम्पोनेंट को हटाने के लिए, इसमें से Gfx रिज़र्व की गई मेमोरी घटाएं.
  • Unity memory profiler: मेमोरी लीक का पता लगाने और उन्हें ऑफ़लाइन डीबग करने के लिए, मेमोरी स्नैपशॉट कैप्चर करें. इसके बाद, डिवाइस पर मौजूद मेमोरी चार्ट की जांच करें. यह चार्ट, 'सभी मेमोरी' सेक्शन में मौजूद होता है. अनुमानित फ़ुटप्रिंट का हिसाब लगाने के लिए, इन कैटगरी के कुल फ़ुटप्रिंट को जोड़ें: ट्रैक नहीं किया गया, Android Runtime, नेटिव, और मैनेज किया गया.
    • zRAM की सीमा: मेमोरी की कमी होने पर, Android कर्नल, इस्तेमाल नहीं किए जा रहे मेमोरी पेजों को स्वैप स्पेस (zRAM) में कंप्रेस कर सकता है. Unity Memory Profiler, ओएस-लेवल के स्वैप पैरामीटर का पता नहीं लगा सकता. इसलिए, मेमोरी का ज़्यादा इस्तेमाल करने वाले सीन के दौरान, आपको फ़ुटप्रिंट में मामूली अंतर दिख सकता है. सटीक वैल्यू की पुष्टि करने के लिए, अपने अनुमानों को Perfetto से क्रॉस-रेफ़रंस करें.