मेमोरी मैनेज करने की खास जानकारी

Android Runtime (ART) और Dalvik वर्चुअल मशीन, मेमोरी मैनेज करने के लिए पेजिंग और मेमोरी-मैपिंग (mmapping) का इस्तेमाल करती हैं. इसका मतलब है कि ऐप्लिकेशन में बदलाव करता है—भले ही, नए ऑब्जेक्ट या मैप किए गए पेजों को छूने पर—यह रैम में रहता है और पेज को बाहर नहीं किया जा सकता. किसी ऐप्लिकेशन से मेमोरी को रिलीज़ करने का बस एक तरीका है ऑब्जेक्ट का रेफ़रंस ऐप्लिकेशन में होता है, जिससे गार्बेज कलेक्टर. इसका एक अपवाद है: किसी भी फ़ाइल बिना कोई बदलाव किए, जैसे कि कोड, हो सकता है कि सिस्टम उस मेमोरी का इस्तेमाल किसी दूसरी जगह पर करे, तो उसे रैम से बाहर रखा जा सकता है.

इस पेज पर बताया गया है कि Android, ऐप्लिकेशन की प्रोसेस और मेमोरी को कैसे मैनेज करता है तय करना. मेमोरी को बेहतर तरीके से मैनेज करने के तरीके के बारे में ज़्यादा जानें अपने ऐप्लिकेशन में, देखें अपने ऐप्लिकेशन की मेमोरी मैनेज करना.

कचरा इकट्ठा करना

मैनेज किया जा रहा मेमोरी एनवायरमेंट, जैसे कि ART या Delvik वर्चुअल मशीन, हर मेमोरी का बंटवारा ट्रैक करता है. जब यह पता चलता है कि प्रोग्राम में किसी मेमोरी का इस्तेमाल नहीं किया जा रहा है, तो प्रोग्रामर के किसी भी तरह के हस्तक्षेप के बिना, उसे ढेर में वापस भेज दिया जाता है. इस्तेमाल न की गई मेमोरी को फिर से पाने का तरीका मैनेज की जा रही मेमोरी वाले एनवायरमेंट में को कचरा इकट्ठा करना कहते हैं. कचरा इकट्ठा करने के दो लक्ष्य हैं: किसी ऐसे प्रोग्राम में डेटा ऑब्जेक्ट खोजना जिसे आने वाले समय में ऐक्सेस न किया जा सके; और उन ऑब्जेक्ट के ज़रिए इस्तेमाल किए गए संसाधनों पर फिर से दावा करें.

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

हीप जनरेट करने के हर तरीके की अपनी ऊपरी सीमा होती है मेमोरी है, जिसे वहां मौजूद ऑब्जेक्ट इस्तेमाल कर सकते हैं. जब भी कोई जनरेशन शुरू होती है उसे भरने के लिए, सिस्टम कूड़ा इकट्ठा करने की प्रोसेस शुरू करता है इवेंट के तौर पर सेव किया जा सकता है. कचरा इकट्ठा करने की अवधि यह इस बात पर निर्भर करता है कि कौनसे ऑब्जेक्ट इकट्ठा किए जा रहे हैं और हर जनरेशन में कितने ऐक्टिव ऑब्जेक्ट हैं.

भले ही कचरा इकट्ठा करना बहुत तेज़ी से हो, लेकिन यह अब भी आपके ऐप्लिकेशन की परफ़ॉर्मेंस पर असर डाल सकता है. आम तौर पर, आपके पास यह कंट्रोल नहीं होता है जब आपके कोड में से कोई गार्बेज कलेक्शन इवेंट होता है. सिस्टम में, गै़रबेज कलेक्शन कब करना है, यह तय करने के लिए शर्तों का एक सेट होता है. शर्तें पूरी होने के बाद, सिस्टम, प्रोसेस को पूरा करना बंद कर देता है और कचरा इकट्ठा करना शुरू करता है. अगर आपने कचरा इकट्ठा करने का काम, किसी इंटेंसिव प्रोसेसिंग लूप के बीच में होता है जैसे, ऐनिमेशन या संगीत वीडियो चलने के दौरान, प्रोसेस होने में लगने वाला समय बढ़ सकता है. इस बढ़ोतरी से आपके ऐप्लिकेशन में, कोड को एक्ज़ीक्यूट किया जा सकता है बेहतर और आसान फ़्रेम रेंडरिंग के लिए, कम से कम 16 मि॰से॰ का थ्रेशोल्ड.

इसके अलावा, आपका कोड फ़्लो ऐसे काम कर सकता है जो गारबेज कलेक्शन इवेंट को ज़बरदस्ती लागू करें या उन्हें सामान्य से ज़्यादा समय तक चलाने के लिए कहें. उदाहरण के लिए, अगर आपने ऐल्फ़ा ब्लेंडिंग ऐनिमेशन के हर फ़्रेम के दौरान, for-loop के सबसे अंदरूनी हिस्से में कई ऑब्जेक्ट को ऐलोकेट किया है, तो हो सकता है कि आपने अपनी मेमोरी हेप को कई ऑब्जेक्ट से भर दिया हो. ऐसे में, गै़रबेज कलेक्टर कई गै़रबेज कलेक्शन इवेंट चलाता है. इससे आपके ऐप्लिकेशन की परफ़ॉर्मेंस खराब हो सकती है.

कचरा इकट्ठा करने के बारे में ज़्यादा जानने के लिए, यहां देखें कचरा इकट्ठा करना.

यादें शेयर करना

रैम में ज़रूरी चीज़ों को फ़िट करने के लिए, Android सभी प्रोसेस के बीच रैम पेजों को शेयर करने की कोशिश करता है. यह ऐसा करने के लिए ये तरीके उपलब्ध हैं:

• हर ऐप्लिकेशन की प्रोसेस को Zygote नाम की मौजूदा प्रोसेस से अलग कर दिया जाता है. Zygote प्रोसेस तब शुरू होती है, जब सिस्टम सामान्य रूप से चालू और लोड होता है फ़्रेमवर्क कोड और संसाधन (जैसे कि गतिविधि की थीम). ऐप्लिकेशन की नई प्रोसेस शुरू करने के लिए, सिस्टम फिर से ज़ायगोट प्रोसेस को शुरू करता है, नई प्रक्रिया में ऐप्लिकेशन के कोड को लोड करता है और चलाता है. इससे आपको फ़्रेमवर्क कोड और संसाधन, जो ऐप्लिकेशन की सभी प्रोसेस के साथ शेयर किए जाएंगे.
• ज़्यादातर स्टैटिक डेटा को प्रोसेस में बदल दिया जाता है. इस तकनीक की मदद से, डेटा को प्रोसेस के बीच शेयर किया जा सकता है. साथ ही, ज़रूरत पड़ने पर उसे पेज के हिसाब से बांटा जा सकता है. स्टैटिक डेटा के उदाहरण में यह शामिल है: Delvik कोड (इसे पहले से लिंक किए गए .odex में रखकर) फ़ाइल (सीधे तौर पर करना), ऐप्लिकेशन के संसाधन (संसाधन टेबल को जिसे ज़ूम किया जा सकता है और ज़िप को संरेखित किया जा सकता है APK की एंट्री) और ट्रेडिशनल प्रोजेक्ट .so फ़ाइलों में नेटिव कोड जैसे एलिमेंट शामिल हैं.
• कई जगहों पर, Android एक ही डाइनैमिक रणनीति इस्तेमाल करता है अलग-अलग प्रोसेस में रैम शेयर की गई मेमोरी का क्षेत्र (ashmem या gralloc के साथ). उदाहरण के लिए, विंडो सरफ़ेस, 'शेयर किए गए' टैब का इस्तेमाल करते हैं ऐप्लिकेशन और स्क्रीन कंपोज़िटर के बीच मेमोरी, और कर्सर बफ़र, कॉन्टेंट देने वाले और क्लाइंट के तौर पर शामिल होते हैं.

शेयर की गई मेमोरी का बहुत ज़्यादा इस्तेमाल होने की वजह से, यह पता करना आपके ऐप्लिकेशन के लिए कितनी मेमोरी का इस्तेमाल हो रहा है देखभाल. रैम के इस्तेमाल की जांच करना लेख में, ऐप्लिकेशन के लिए इस्तेमाल की गई मेमोरी का पता लगाने के तरीकों के बारे में बताया गया है.

ऐप्लिकेशन की मेमोरी तय करना और उस पर फिर से दावा करना

डाल्विक हीप में एक वर्चुअल मेमोरी रेंज होती है. यह हीप का लॉजिकल साइज़, जो ज़रूरत के हिसाब से बढ़ सकता है लेकिन सिर्फ़ उस सीमा तक जिसे सिस्टम तय करता है हर ऐप्लिकेशन के लिए अलग-अलग वैल्यू होती हैं.

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

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

ऐप्लिकेशन की मेमोरी पर पाबंदी लगाना

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

कुछ मामलों में, हो सकता है कि आप ताकि यह पता लगाया जा सके कि आपको कितना हीप स्पेस मौजूदा डिवाइस पर उपलब्ध हों—उदाहरण के लिए, यह तय कर सकते हैं कि कितना डेटा सुरक्षित रखा जाए कैश मेमोरी. आप getMemoryClass(). यह तरीका, एक पूर्णांक लौटाता है जो आपके ऐप्लिकेशन के हीप के लिए उपलब्ध मेगाबाइट.

ऐप्लिकेशन के बीच स्विच करें

जब उपयोगकर्ता एक ऐप्लिकेशन से दूसरे ऐप्लिकेशन पर स्विच करते हैं, Android ऐसे ऐप्लिकेशन रखता है जो फ़ोरग्राउंड नहीं हैं—जो उपयोगकर्ता को नहीं दिख रहे हैं या फ़ोरग्राउंड सेवा, जैसे कि म्यूज़िक प्लेबैक— कैश मेमोरी में सेव करें. उदाहरण के लिए, जब कोई उपयोगकर्ता पहली बार किसी ऐप्लिकेशन को लॉन्च करता है, इसके लिए एक प्रोसेस बनाई जाती है; हालांकि, जब उपयोगकर्ता को ऐप्लिकेशन से बाहर निकला जाता है, तो वह प्रोसेस बंद नहीं होती. सिस्टम, प्रोसेस को कैश मेमोरी में सेव रखता है. अगर आपने जब उपयोगकर्ता बाद में ऐप्लिकेशन पर वापस लौटता है, तो सिस्टम प्रोसेस का दोबारा इस्तेमाल करता है. इससे ऐसा होता है इससे ऐप्लिकेशन के बीच तेज़ी से स्विच किया जा सकता है.

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

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

फ़ोरग्राउंड में नहीं चलने के दौरान, प्रोसेस को कैश मेमोरी में कैसे सेव किया जाता है और Android यह कैसे तय करता है कि किन प्रोसेस को बंद किया जा सकता है, इस बारे में ज़्यादा जानने के लिए, प्रोसेस और थ्रेड गाइड देखें.

मेमोरी स्ट्रेस टेस्ट

हालांकि, ज़्यादा कीमत वाले डिवाइसों पर मेमोरी स्ट्रेस की समस्याएं कम होती हैं, लेकिन उनसे अब भी समस्याएं हो सकती हैं कम रैम वाले डिवाइसों का इस्तेमाल करने वाले लोगों के लिए. जैसे, Android (Go वर्शन) इस्तेमाल करने वाले डिवाइस. इस बात को समझना ज़रूरी है कि इस मेमोरी-स्ट्रेस एनवायरमेंट को फिर से तैयार करें, ताकि आप ऐप्लिकेशन की पुष्टि करने के लिए इंस्ट्रुमेंटेशन टेस्ट लिख सकें और कम मेमोरी वाले डिवाइसों पर आपके उपयोगकर्ताओं के अनुभव को बेहतर बनाने के लिए किया जा सकता है.

तनावपूर्ण ऐप्लिकेशन टेस्ट

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

    adb push stressapptest /data/local/tmp/
    adb shell chmod 777 /data/local/tmp/stressapptest
    adb shell /data/local/tmp/stressapptest -s 20 -M 990

  

stressapptest देखें टूल इंस्टॉल करने, सामान्य तर्क, और गड़बड़ियों को ठीक करने के बारे में ज़्यादा जानकारी के लिए दस्तावेज़ जानकारी.

स्ट्रेसएप्टेस्ट के ऑब्ज़र्वेशन

stressapptest जैसे टूल का इस्तेमाल, तय की गई मेमोरी से ज़्यादा मेमोरी का अनुरोध करने के लिए किया जा सकता है उपलब्ध हैं. इस तरह के अनुरोध से कई तरह की चेतावनियां मिल सकती हैं, जिनके बारे में आपको विकास के पक्ष में है. डिवाइस में कम मेमोरी उपलब्ध होने की वजह से, ये तीन मुख्य चेतावनियां मिल सकती हैं:

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