मेमोरी का इस्तेमाल (बिना सोर्स फ़ाइल वाली आरएसएस मेमोरी + स्वैप मेमोरी)

मेमोरी का इस्तेमाल (बिना सोर्स फ़ाइल वाली आरएसएस मेमोरी और स्वैप मेमोरी) एक ऐसी मेट्रिक है जिससे आपके ऐप्लिकेशन की मेमोरी के इस्तेमाल के बारे में पता चलता है.

बिना सोर्स फ़ाइल वाली मेमोरी, स्टोरेज पर मौजूद किसी फ़ाइल से जुड़ी नहीं होती. जैसे, हीप एलोकेशन और mmap-एलोकेट की गई मेमोरी. इससे आपके ऐप्लिकेशन के डाइनैमिक मेमोरी के बंटवारे को कैप्चर किया जाता है. इसमें Java या Kotlin हीप, अनमैनेज्ड नेटिव हीप के बंटवारे (जहां Android 8.0 (एपीआई लेवल 26) और इसके बाद के वर्शन पर बिटमैप पिक्सल डेटा मौजूद होता है) और थ्रेड एक्ज़ीक्यूशन स्टैक शामिल हैं. ओएस, मेमोरी पर ज़्यादा दबाव पड़ने पर फ़ाइल-बैक की गई मेमोरी को कम कर सकता है. हालांकि, वह ऐनॉनमस मेमोरी को कम नहीं कर सकता.

रेज़िडेंट सेट साइज़ (आरएसएस) से पता चलता है कि किसी प्रोसेस के लिए, फ़िज़िकल रैम में कितने मेमोरी पेज (शेयर किए गए और शेयर नहीं किए गए, दोनों) इस्तेमाल किए गए हैं. किसी पेज को "शेयर किया गया" तब माना जाता है, जब उसे एक से ज़्यादा प्रोसेस (जैसे कि एक ही लाइब्रेरी को ऐक्सेस करने वाले ऐप्लिकेशन) ऐक्सेस करती हैं.

बिना सोर्स फ़ाइल वाली मेमोरी के लिए, सिस्टम मेमोरी पर दबाव पड़ने पर पेजों को स्वैप स्पेस (या Android पर zRAM) में लिख सकता है. ज़रूरत पड़ने पर, सिस्टम इन पेजों को स्वैप से वापस पढ़ सकता है.

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

अगर आपके ऐप्लिकेशन की मेमोरी का इस्तेमाल ज़्यादा है, तो इस पेज पर दिए गए दिशा-निर्देशों का इस्तेमाल करके, समस्या की जांच करें और उसे ठीक करें.

संसाधन

मेमोरी के बहुत ज़्यादा इस्तेमाल की समस्या का पता लगाना

मेमोरी का ज़्यादा इस्तेमाल करने की वजह का पता लगाने के लिए, डेवलपर सेटिंग, Android Studio या Perfetto में जाकर, Record heap dump की मदद से हीप डंप कैप्चर किया जा सकता है. हमारा सुझाव है कि आप अपने ऐप्लिकेशन के मुख्य उपयोगकर्ता फ़्लो को टेस्ट करने के बाद, स्थानीय तौर पर हीप डंप कैप्चर करें.

हमारा सुझाव है कि आप खास तौर पर, उपयोगकर्ता के इन चरणों की जांच करें:

• वेबव्यू और इन-ऐप्लिकेशन ब्राउज़र सेशन
• मीडिया फ़ाइलें दिखाने के लिए इनफ़ाइनाइट स्क्रोलिंग का इस्तेमाल करना
• ऐसेट बनाने और उनमें बदलाव करने के फ़्लो

मेमोरी लीक की संभावित समस्याओं की जांच करने के लिए, उपयोगकर्ता के अनुभव से जुड़े टेस्ट को स्थानीय तौर पर चलाएं. साथ ही, अलग-अलग प्रोसेस की स्थितियों (दिखने वाली, फ़ोरग्राउंड सेवा, और कैश मेमोरी में सेव की गई) के लिए हीप डंप इकट्ठा करें. इससे यह पुष्टि की जा सकेगी कि ऐप्लिकेशन को बैकग्राउंड में ले जाने के बाद, मेमोरी खाली हो जाती है या नहीं. इन प्रोसेस की स्थितियों का onTrimMemory कॉलबैक से क्या संबंध है, यह जानने के लिए इवेंट के जवाब में मेमोरी खाली करने से जुड़ी गाइड पढ़ें.

अगर Android Studio Profiler का इस्तेमाल करके मेमोरी से जुड़ी समस्याओं को डीबग किया जा रहा है, तो LeakCanary इंटिग्रेशन का इस्तेमाल करके, लीक और डुप्लीकेट बिटमैप का पता लगाने की प्रोसेस को आसान बनाया जा सकता है. इससे इमेज के इस्तेमाल को ऑप्टिमाइज़ करने में मदद मिलती है.

हीप डंप इकट्ठा करने के बाद, हमारा सुझाव है कि आप Android प्रोफ़ाइलर स्किल का इस्तेमाल करें. इससे आपको, ज़्यादा मेमोरी के इस्तेमाल की संभावित वजहों का पता लगाने और उनका विश्लेषण करने में मदद मिलेगी.

android skills add android-profiler

यहां एक उदाहरण दिया गया है कि एआई की स्किल किस तरह से जवाब दे सकती हैं:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

ढेर डंप की व्याख्या करने के लिए अतिरिक्त संसाधन

यहां दिए गए संसाधनों में, हीप डंप की व्याख्या करने और मेमोरी के इस्तेमाल को डीबग करने के बारे में ज़्यादा जानकारी दी गई है:

• मैन्युअल तरीके से विश्लेषण करना: Perfetto Heap Dump Explorer के दिशा-निर्देशों का इस्तेमाल करके, Perfetto यूज़र इंटरफ़ेस (यूआई) में हीप डंप विज़ुअलाइज़ेशन को नेविगेट करने और समझने का तरीका जानें.
• Java/Kotlin के लिए मेमोरी का बंटवारा: Android Runtime (ART) हीप डंप का विश्लेषण करने के बारे में सिलसिलेवार तरीके से जानने के लिए, अपने पहले ART हीप डंप को विज़ुअलाइज़ करना लेख पढ़ें.
• नेटिव मेमोरी का बंटवारा: नेटिव (C/C++) मेमोरी प्रोफ़ाइलें इकट्ठा करने और उनका विश्लेषण करने का तरीका जानने के लिए, Perfetto Native Profiling का दस्तावेज़ देखें.
• सीएलआई की मदद से जांच करना: किसी डिवाइस पर आपके ऐप्लिकेशन की मेमोरी के इस्तेमाल की जानकारी तुरंत पाने के लिए, adb dumpsys meminfo का इस्तेमाल करें.

मेमोरी के इस्तेमाल को बेहतर बनाना

अपने ऐप्लिकेशन की मेमोरी के इस्तेमाल को बेहतर बनाने के बारे में ज़्यादा जानने के लिए, इन सेक्शन को देखें:

• अपने ऐप्लिकेशन के कोड और संसाधन के फ़ुटप्रिंट को कम करें
• उपलब्ध मेमोरी और मेमोरी के इस्तेमाल पर नज़र रखना
• मेमोरी का कम इस्तेमाल करने वाले कोड कंस्ट्रक्ट का इस्तेमाल करना

मेमोरी से जुड़ी समस्याओं को ठीक करने के बारे में पूरी जानकारी के लिए, अपने ऐप्लिकेशन की मेमोरी मैनेज करना गाइड देखें.