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

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

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

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

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

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

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

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

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

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

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

अपनी ज़रूरत की हर चीज़ को रैम में फ़िट करने के लिए, 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) और उसके बाद वाले वर्शन पर उपलब्ध हैं. साथ ही, इनके बारे में ज़्यादा जानकारी मिलती है मेमोरी अलर्ट.