अलग-अलग प्रोसेस के बीच मेमोरी का बंटवारा

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

इस पेज पर, Android के सिस्टम और उपयोगकर्ता ऐप्लिकेशन के लिए मेमोरी बांटने के तरीके की बुनियादी जानकारी दी गई है. इसमें यह भी बताया गया है कि मेमोरी कम होने पर, ऑपरेटिंग सिस्टम कैसे काम करता है.

मेमोरी के टाइप

Android डिवाइस में तीन अलग-अलग तरह की मेमोरी होती हैं: रैम, zRAM, और स्टोरेज. ध्यान दें कि सीपीयू और जीपीयू, दोनों एक ही रैम को ऐक्सेस करते हैं.

अलग-अलग तरह की पुरानी तस्वीरें

पहली इमेज. मेमोरी के टाइप - रैम, zRAM, और स्टोरेज

  • रैम, सबसे तेज़ मेमोरी होती है. हालांकि, आम तौर पर इसका साइज़ सीमित होता है. आम तौर पर, हाई-एंड डिवाइस में सबसे ज़्यादा रैम होती है.

  • zRAM, रैम का एक ऐसा पार्टिशन है जिसका इस्तेमाल स्वैप स्पेस के लिए किया जाता है. zRAM में कुछ भी रखने पर, वह कंप्रेस हो जाता है. इसके बाद, zRAM से कॉपी करने पर वह डीकंप्रेस हो जाता है. रैम का यह हिस्सा, zRAM में पेज ले जाने या उससे पेज हटाने पर, साइज़ में बढ़ता या घटता है. डिवाइस बनाने वाली कंपनियां, ज़्यादा से ज़्यादा साइज़ सेट कर सकती हैं.

  • स्टोरेज में, लगातार सेव रहने वाला सारा डेटा होता है. जैसे, फ़ाइल सिस्टम और सभी ऐप्लिकेशन, लाइब्रेरी, और प्लैटफ़ॉर्म के लिए शामिल ऑब्जेक्ट कोड. स्टोरेज की क्षमता, अन्य दो तरह की मेमोरी से कहीं ज़्यादा होती है. Android में, स्टोरेज का इस्तेमाल स्वैप स्पेस के लिए नहीं किया जाता. ऐसा इसलिए, क्योंकि बार-बार लिखने से इस मेमोरी पर असर पड़ सकता है और स्टोरेज मीडियम की लाइफ़ कम हो सकती है. हालांकि, Linux के अन्य वर्शन में, स्टोरेज का इस्तेमाल स्वैप स्पेस के लिए किया जाता है.

मेमोरी पेज

रैम को पेजों में बांटा जाता है. आम तौर पर, हर पेज 4 केबी मेमोरी का होता है.

पेजों को खाली या इस्तेमाल किया गया माना जाता है. खाली पेज, इस्तेमाल न की गई रैम होती है. इस्तेमाल किए गए पेज, रैम होती है जिसका इस्तेमाल सिस्टम, सक्रिय तौर पर कर रहा होता है. इन्हें इन कैटगरी में बांटा जाता है:

  • कैश्ड: स्टोरेज में मौजूद किसी फ़ाइल से बैकअप ली गई मेमोरी (उदाहरण के लिए, कोड या मेमोरी-मैप्ड फ़ाइलें). कैश्ड मेमोरी दो तरह की होती है:
    • प्राइवेट: किसी एक प्रोसेस के पास होती है और शेयर नहीं की जाती
      • क्लीन: स्टोरेज में मौजूद किसी फ़ाइल की बिना बदलाव वाली कॉपी. खाली मेमोरी बढ़ाने के लिए, इसे kswapd से मिटाया जा सकता है
      • डर्टी: स्टोरेज में मौजूद किसी फ़ाइल की बदलाव वाली कॉपी. खाली मेमोरी बढ़ाने के लिए, इसे kswapd से zRAM में ले जाया जा सकता है या कंप्रेस किया जा सकता है
    • शेयर की गई: एक से ज़्यादा प्रोसेस इस्तेमाल करती हैं
      • क्लीन: स्टोरेज में मौजूद किसी फ़ाइल की बिना बदलाव वाली कॉपी. खाली मेमोरी बढ़ाने के लिए, इसे kswapd से मिटाया जा सकता है
      • डर्टी: स्टोरेज में मौजूद किसी फ़ाइल की बदलाव वाली कॉपी. खाली मेमोरी बढ़ाने के लिए, इसे स्टोरेज में मौजूद फ़ाइल में वापस लिखा जा सकता है kswapd. इसके अलावा, msync() या munmap()का इस्तेमाल करके, खाली मेमोरी बढ़ाई जा सकती है
  • एनॉनिमस: स्टोरेज में मौजूद किसी फ़ाइल से बैकअप नहीं ली गई मेमोरी (उदाहरण के लिए, mmap() से बांटी गई मेमोरी जिसमें MAP_ANONYMOUS फ़्लैग सेट है)
    • डर्टी: खाली मेमोरी बढ़ाने के लिए, इसे kswapd से zRAM में ले जाया जा सकता है या कंप्रेस किया जा सकता है

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

मेमोरी कम होने की स्थिति को मैनेज करना

Android में, मेमोरी कम होने की स्थितियों से निपटने के लिए दो मुख्य तरीके हैं: कर्नेल स्वैप डीमन और लो-मेमोरी किलर.

कर्नेल स्वैप डीमन

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

kswapd , क्लीन पेजों को मिटाकर उन्हें वापस पा सकता है, क्योंकि इनका बैकअप स्टोरेज में होता है और इनमें बदलाव नहीं किया गया होता है. अगर कोई प्रोसेस, मिटाए गए क्लीन पेज को ऐक्सेस करने की कोशिश करती है, तो सिस्टम उस पेज को स्टोरेज से रैम में कॉपी कर लेता है. इस ऑपरेशन को डिमांड पेजिंग कहा जाता है.

स्टोरेज में मौजूद डेटा मिटाकर पेज को क्लीन किया गया

दूसरी इमेज. स्टोरेज से बैकअप लिया गया क्लीन पेज मिटाया गया

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

अगर खाली मेमोरी की मात्रा, किसी तय थ्रेशोल्ड से कम हो जाती है, तो सिस्टम प्रोसेस को खत्म करना शुरू कर देता है.

डर्टी पेज को zRAM में ले जाया गया और कंप्रेस किया गया

तीसरी इमेज. डर्टी पेज को zRAM में ले जाकर कंप्रेस किया गया

लो-मेमोरी किलर

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

एलएमके, यह तय करने के लिए कि किस प्रोसेस को खत्म करना है, "आउट ऑफ़ मेमोरी" स्कोर का इस्तेमाल करता है. इसे oom_adj_score कहा जाता है. इससे, चल रही प्रोसेस को प्राथमिकता दी जाती है. ज़्यादा स्कोर वाली प्रोसेस को सबसे पहले खत्म किया जाता है. बैकग्राउंड में चल रहे ऐप्लिकेशन को सबसे पहले खत्म किया जाता है. वहीं, सिस्टम की प्रोसेस को सबसे आखिर में खत्म किया जाता है. यहां दी गई टेबल में, एलएमके स्कोरिंग की कैटगरी, ज़्यादा से कम स्कोर के क्रम में दी गई हैं. पहली लाइन में, सबसे ज़्यादा स्कोर वाली कैटगरी में मौजूद आइटम को सबसे पहले खत्म किया जाएगा:

Android प्रोसेस, सबसे ऊपर ज़्यादा स्कोर

चौथी इमेज. Android की प्रोसेस. इनमें सबसे ऊपर ज़्यादा स्कोर वाली और सबसे नीचे कम स्कोर वाली प्रोसेस दिखाई गई हैं

यहां दी गई टेबल में मौजूद अलग-अलग कैटगरी के बारे में बताया गया है:

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

  • पिछला ऐप्लिकेशन: हाल ही में इस्तेमाल किया गया बैकग्राउंड में चल रहा ऐप्लिकेशन. पिछले ऐप्लिकेशन को बैकग्राउंड में चल रहे ऐप्लिकेशन की तुलना में ज़्यादा प्राथमिकता (कम स्कोर) मिलती है, क्योंकि इस बात की ज़्यादा संभावना होती है कि उपयोगकर्ता, बैकग्राउंड में चल रहे किसी ऐप्लिकेशन के बजाय, पिछले ऐप्लिकेशन पर स्विच करेगा.

  • होम ऐप्लिकेशन: यह लॉन्चर ऐप्लिकेशन होता है. इसे खत्म करने पर, वॉलपेपर गायब हो जाएगा.

  • सेवाएं: सेवाएं, ऐप्लिकेशन से शुरू होती हैं. इनमें सिंक करना या क्लाउड पर अपलोड करना शामिल हो सकता है.

  • परसेप्टिबल ऐप्लिकेशन: फ़ोरग्राउंड में नहीं चल रहे ऐसे ऐप्लिकेशन जो किसी न किसी तरह से उपयोगकर्ता को दिखते हैं. जैसे, खोज की प्रोसेस चलाना, जिसमें छोटा यूज़र इंटरफ़ेस दिखता है या संगीत सुनना.

  • फ़ोरग्राउंड ऐप्लिकेशन: वह ऐप्लिकेशन जिसका इस्तेमाल फ़िलहाल किया जा रहा है. फ़ोरग्राउंड में चल रहे ऐप्लिकेशन को खत्म करने पर, ऐसा लगता है कि ऐप्लिकेशन क्रैश हो गया है. इससे उपयोगकर्ता को लग सकता है कि डिवाइस में कोई गड़बड़ी है.

  • परसिस्टेंट (सेवाएं): ये डिवाइस के लिए मुख्य सेवाएं होती हैं. जैसे, टेलीफ़ोनी और वाई-फ़ाई.

  • सिस्टम: सिस्टम की प्रोसेस. इन प्रोसेस को खत्म करने पर, ऐसा लग सकता है कि फ़ोन रीबूट हो रहा है.

  • नेटिव: सिस्टम की बहुत लो-लेवल प्रोसेस. उदाहरण के लिए, kswapd.

डिवाइस बनाने वाली कंपनियां, एलएमके के काम करने के तरीके में बदलाव कर सकती हैं.

मेमोरी फ़ुटप्रिंट का हिसाब लगाना

कर्नेल, सिस्टम में मौजूद सभी मेमोरी पेजों को ट्रैक करता है.

अलग-अलग प्रोसेस के लिए इस्तेमाल किए गए पेज

पांचवीं इमेज. अलग-अलग प्रोसेस से इस्तेमाल किए गए पेज

यह तय करते समय कि कोई ऐप्लिकेशन कितनी मेमोरी इस्तेमाल कर रहा है, सिस्टम को शेयर किए गए पेजों का हिसाब रखना होता है. एक ही सेवा या लाइब्रेरी को ऐक्सेस करने वाले ऐप्लिकेशन, मेमोरी पेज शेयर करेंगे. उदाहरण के लिए, Google Play services और कोई गेम ऐप्लिकेशन, जगह की जानकारी वाली सेवा शेयर कर सकते हैं. इससे यह तय करना मुश्किल हो जाता है कि सेवा के लिए कितनी मेमोरी है और हर ऐप्लिकेशन के लिए कितनी.

दो ऐप्लिकेशन से शेयर किए गए पेज

छठी इमेज. दो ऐप्लिकेशन से शेयर किए गए पेज (बीच में)

किसी ऐप्लिकेशन के मेमोरी फ़ुटप्रिंट का पता लगाने के लिए, इनमें से किसी भी मेट्रिक का इस्तेमाल किया जा सकता है:

  • रेसिडेंट सेट साइज़ (आरएसएस): ऐप्लिकेशन से इस्तेमाल किए गए शेयर किए गए और शेयर नहीं किए गए पेजों की संख्या
  • प्रपोर्शनल सेट साइज़ (पीएसएस): ऐप्लिकेशन से इस्तेमाल किए गए शेयर नहीं किए गए पेजों की संख्या और शेयर किए गए पेजों का बराबर बंटवारा. उदाहरण के लिए, अगर तीन प्रोसेस, 3 एमबी शेयर कर रही हैं, तो हर प्रोसेस को पीएसएस में 1 एमबी मिलेगा
  • यूनीक सेट साइज़ (यूएसएस): ऐप्लिकेशन से इस्तेमाल किए गए शेयर नहीं किए गए पेजों की संख्या. इसमें शेयर किए गए पेज शामिल नहीं होते

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

ज़्यादा मेमोरी इस्तेमाल करने वाली क्रिटिकल यूज़र जर्नी (सीयूजे) की पहचान करना

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

  • कॉम्प्लेक्स मीडिया या बड़े बिटमैप लोड करना और उनमें बदलाव करना.
  • WebView इंस्टेंस को होस्ट करना.

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

अन्य संसाधन