ज़्यादातर मामलों में, हर Android ऐप्लिकेशन अपनी Linux प्रोसेस में चलता है. यह प्रोसेस, ऐप्लिकेशन के लिए तब बनाई जाती है, जब उसके कुछ कोड को चलाने की ज़रूरत होती है. यह तब तक चलती रहती है, जब तक सिस्टम को अन्य ऐप्लिकेशन के इस्तेमाल के लिए अपनी मेमोरी वापस पाने की ज़रूरत नहीं पड़ जाती और इस प्रोसेस की ज़रूरत नहीं रह जाती.
Android की एक असामान्य और बुनियादी सुविधा यह है कि ऐप्लिकेशन प्रोसेस का जीवनकाल, ऐप्लिकेशन से सीधे तौर पर कंट्रोल नहीं किया जाता. इसके बजाय, सिस्टम यह तय करता है कि ऐप्लिकेशन के कौनसे हिस्से चल रहे हैं, ये उपयोगकर्ता के लिए कितने ज़रूरी हैं, और सिस्टम में कुल कितनी मेमोरी उपलब्ध है.
यह ज़रूरी है कि ऐप्लिकेशन डेवलपर यह समझें कि ऐप्लिकेशन के अलग-अलग कॉम्पोनेंट (खास तौर पर Activity, Service, और BroadcastReceiver) से, ऐप्लिकेशन की प्रोसेस के लाइफ़टाइम पर क्या असर पड़ता है. इन कॉम्पोनेंट का सही तरीके से इस्तेमाल न करने पर, हो सकता है कि सिस्टम ऐप्लिकेशन की प्रोसेस को बंद कर दे, जबकि वह कोई अहम काम कर रहा हो.
प्रोसेस लाइफ़साइकल बग का एक सामान्य उदाहरण, ऐसा BroadcastReceiver है जो अपने BroadcastReceiver.onReceive()
मैथड में Intent मिलने पर, एक थ्रेड शुरू करता है और फिर फ़ंक्शन से वापस आता है. जब यह वापस आ जाता है, तो सिस्टम BroadcastReceiver को अब चालू नहीं मानता. साथ ही, जब तक उसमें ऐप्लिकेशन के अन्य कॉम्पोनेंट चालू नहीं होते, तब तक उसकी होस्टिंग की प्रोसेस की ज़रूरत नहीं होती.
इसलिए, सिस्टम किसी भी समय प्रोसेस को बंद करके, मेमोरी वापस पा सकता है. ऐसा करने पर, वह प्रोसेस में चल रही स्पॉन की गई थ्रेड को बंद कर देता है. इस समस्या को हल करने के लिए, आम तौर पर BroadcastReceiver से JobService शेड्यूल किया जाता है, ताकि सिस्टम को पता चले कि प्रोसेस में कोई काम चल रहा है.
मेमोरी कम होने पर, Android यह तय करता है कि किन प्रोसेस को बंद करना है. इसके लिए, वह हर प्रोसेस को अहमियत के हिसाब से क्रम में रखता है. यह क्रम, उनमें चल रहे कॉम्पोनेंट और उन कॉम्पोनेंट की स्थिति के आधार पर तय किया जाता है. अहमियत के हिसाब से, ये प्रोसेस इस तरह की होती हैं:
- फ़ोरग्राउंड प्रोसेस वह प्रोसेस होती है जो उपयोगकर्ता फ़िलहाल कर रहा है. ऐप्लिकेशन के अलग-अलग कॉम्पोनेंट की वजह से, उसमें मौजूद प्रोसेस को अलग-अलग तरीकों से फ़ोरग्राउंड माना जा सकता है. किसी प्रोसेस को फ़ोरग्राउंड में तब माना जाता है, जब इनमें से कोई एक शर्त पूरी होती है:
- यह उस स्क्रीन के सबसे ऊपर
Activityचला रहा है जिससे उपयोगकर्ता इंटरैक्ट कर रहा है (इसकेonResume()तरीके को कॉल किया गया है). - इसमें एक
BroadcastReceiverहै जो फ़िलहाल चल रहा है (इसकाBroadcastReceiver.onReceive()तरीका लागू किया जा रहा है). - इसमें एक
Serviceहै, जो फ़िलहाल अपने किसी कॉलबैक (Service.onCreate(),Service.onStart()याService.onDestroy()) में कोड को लागू कर रहा है.
- यह उस स्क्रीन के सबसे ऊपर
- दिखने वाली प्रोसेस वह काम कर रही है जिसके बारे में उपयोगकर्ता को फ़िलहाल पता है. इसलिए, इसे बंद करने से उपयोगकर्ता अनुभव पर काफ़ी बुरा असर पड़ता है. किसी प्रोसेस को इन स्थितियों में दिखने वाला माना जाता है:
- यह
Activityचला रहा है, जो उपयोगकर्ता को स्क्रीन पर दिख रहा है, लेकिन फ़ोरग्राउंड में नहीं दिख रहा है (इसकेonPause()मेथड को कॉल किया गया है). उदाहरण के लिए, ऐसा तब हो सकता है, जब फ़ोरग्राउंडActivityको डायलॉग के तौर पर दिखाया गया हो, ताकि उसके पीछे पिछलाActivityदिख सके. - इसमें
Serviceहै, जोService.startForeground()के ज़रिए, फ़ोरग्राउंड सेवा के तौर पर काम कर रहा है. यह सेवा, सिस्टम से कहती है कि वह इस सेवा को ऐसे इस्तेमाल करे जिसकी उपयोगकर्ता को जानकारी हो या जिसे वह देख सकता हो. - यह किसी ऐसी सेवा को होस्ट कर रहा हो जिसका इस्तेमाल सिस्टम, उपयोगकर्ता को बताई गई किसी सुविधा के लिए कर रहा हो. जैसे, लाइव वॉलपेपर या इनपुट के तरीके से जुड़ी सेवा.
सिस्टम में चल रही इन प्रोसेस की संख्या, फ़ोरग्राउंड प्रोसेस की तुलना में कम होती है. हालांकि, इन पर अब भी काफ़ी हद तक कंट्रोल होता है. इन प्रोसेस को बहुत ज़रूरी माना जाता है और इन्हें तब तक बंद नहीं किया जाता, जब तक कि सभी फ़ोरग्राउंड प्रोसेस को चालू रखने के लिए ऐसा करना ज़रूरी न हो.
- यह
- सेवा प्रोसेस वह प्रोसेस होती है जिसमें
Serviceहोता है और जिसेstartService()तरीके से शुरू किया गया है. हालांकि, ये प्रोसेस उपयोगकर्ता को सीधे तौर पर नहीं दिखती हैं, लेकिन आम तौर पर ये ऐसी चीज़ें करती हैं जिनमें उपयोगकर्ता की दिलचस्पी होती है. जैसे, बैकग्राउंड में नेटवर्क डेटा अपलोड या डाउनलोड करना. इसलिए, सिस्टम ऐसी प्रोसेस को तब तक चलाता रहता है, जब तक कि फ़ोरग्राउंड और दिखने वाली सभी प्रोसेस को बनाए रखने के लिए ज़रूरत के मुताबिक मेमोरी उपलब्ध हो.अगर कोई सेवा 30 मिनट या उससे ज़्यादा समय से चल रही है, तो हो सकता है कि उसे कैश मेमोरी में सेव की गई सूची में भेज दिया जाए.
लंबे समय तक चलने वाली प्रोसेस,
setForegroundकी मदद से बनाई जा सकती हैं. अगर यह एक ऐसी प्रोसेस है जिसे समय-समय पर पूरा करना ज़रूरी है, तो इसेAlarmManagerकी मदद से शेड्यूल किया जा सकता है. ज़्यादा जानकारी के लिए, लंबे समय तक काम करने वाले वर्कर के लिए सहायता लेख पढ़ें. इससे उन स्थितियों से बचने में मदद मिलती है जहां लंबे समय तक चलने वाली सेवाएं, ज़्यादा रिसोर्स का इस्तेमाल करती हैं. उदाहरण के लिए, मेमोरी लीक करके, सिस्टम को उपयोगकर्ता को बेहतर अनुभव देने से रोकती हैं. - कैश मेमोरी में सेव की गई प्रोसेस ऐसी प्रोसेस होती है जिसकी फ़िलहाल ज़रूरत नहीं होती. इसलिए, जब मेमोरी जैसे संसाधनों की ज़रूरत कहीं और पड़ती है, तो सिस्टम ज़रूरत के हिसाब से उसे बंद कर सकता है. आम तौर पर काम करने वाले सिस्टम में, संसाधन मैनेजमेंट में सिर्फ़ ये प्रोसेस शामिल होती हैं.
अच्छी तरह से काम करने वाले सिस्टम में, कैश मेमोरी में सेव की गई कई प्रोसेस हमेशा उपलब्ध होती हैं. इससे, एक ऐप्लिकेशन से दूसरे ऐप्लिकेशन पर बेहतर तरीके से स्विच किया जा सकता है. साथ ही, ज़रूरत के हिसाब से कैश मेमोरी में सेव किए गए ऐप्लिकेशन को नियमित तौर पर बंद किया जा सकता है. सिर्फ़ बहुत ही गंभीर स्थितियों में, सिस्टम इस स्थिति तक पहुंचता है जहां कैश मेमोरी में सेव सभी प्रोसेस बंद कर दी जाती हैं और उसे सेवा प्रोसेस बंद करनी पड़ती हैं.
कैश मेमोरी में सेव की गई प्रोसेस को सिस्टम कभी भी बंद कर सकता है. इसलिए, ऐप्लिकेशन को कैश मेमोरी में सेव होने के दौरान, सभी काम बंद कर देने चाहिए. अगर ऐप्लिकेशन को उपयोगकर्ता के लिए ज़रूरी काम करना है, तो ऐप्लिकेशन को ऊपर दिए गए किसी एक एपीआई का इस्तेमाल करके, काम को चालू प्रोसेस की स्थिति से चलाना चाहिए.
कैश मेमोरी में सेव की गई प्रोसेस में अक्सर एक या एक से ज़्यादा
Activityइंस्टेंस होते हैं, जो फ़िलहाल उपयोगकर्ता को नहीं दिखते. इनकेonStop()तरीके को कॉल किया गया है और वह रिटर्न हो गया है. अगर सिस्टम ऐसी प्रोसेस को बंद करता है, तो ऐप्लिकेशन पर वापस आने पर उपयोगकर्ता के अनुभव पर इसका असर नहीं पड़ता. ऐसा तब होता है, जब ऐप्लिकेशन केActivityलाइफ़साइकल को सही तरीके से लागू किया गया हो. साथ ही, जब उससे जुड़ी गतिविधि को नई प्रोसेस में फिर से बनाया गया हो, तो पहले से सेव की गई स्थिति को वापस लाया जा सकता है. ध्यान रखें कि अगर सिस्टम किसी प्रोसेस को बंद कर देता है, तोonDestroy()को कॉल किए जाने की कोई गारंटी नहीं है. ज़्यादा जानकारी के लिए,Activityदेखें.Android 13 में, ऐप्लिकेशन प्रोसेस को तब तक सीमित या कोई भी समय नहीं मिल सकता, जब तक वह ऊपर बताई गई लाइफ़साइकल की किसी एक स्थिति में नहीं आ जाती.
कैश मेमोरी में सेव की गई प्रोसेस को एक सूची में रखा जाता है. इस सूची के लिए, क्रम तय करने की सटीक नीति, प्लैटफ़ॉर्म को लागू करने से जुड़ी जानकारी है. आम तौर पर, यह अन्य प्रोसेस से पहले, ज़्यादा काम की प्रोसेस को बनाए रखने की कोशिश करता है. जैसे, उपयोगकर्ता के होम ऐप्लिकेशन को होस्ट करने वाली प्रोसेस या उपयोगकर्ता की पिछली गतिविधि. प्रोसेस को बंद करने के लिए, दूसरी नीतियां भी लागू की जा सकती हैं. जैसे, प्रोसेस की संख्या पर तय सीमा सेट करना या किसी प्रोसेस को लगातार कैश मेमोरी में सेव रहने की समयसीमा तय करना.
सिस्टम में ऐसी प्रोसेस हमेशा कम ही होती हैं. इन्हें आखिरी विकल्प के तौर पर ही बंद किया जाता है. ऐसा तब किया जाता है, जब मेमोरी इतनी कम हो जाती है कि ये प्रोसेस भी नहीं चल पाती हैं. आम तौर पर, ऐसा होने पर डिवाइस, मेमोरी पेजिंग की स्थिति में पहुंच जाता है. इसलिए, यूज़र इंटरफ़ेस को रिस्पॉन्सिव बनाए रखने के लिए, यह कार्रवाई ज़रूरी है.
किसी प्रोसेस को कैटगरी में बांटने का तरीका तय करते समय, सिस्टम अपने फ़ैसले को प्रोसेस में मौजूद सभी कॉम्पोनेंट के बीच सबसे अहम लेवल पर आधारित करता है.
इनमें से हर कॉम्पोनेंट, प्रोसेस और ऐप्लिकेशन के पूरे लाइफ़साइकल में कैसे योगदान देता है, इस बारे में ज़्यादा जानने के लिए, Activity, Service, और
BroadcastReceiver दस्तावेज़ देखें.
किसी प्रोसेस की प्राथमिकता को बढ़ाया भी जा सकता है. ऐसा, उस प्रोसेस पर निर्भर रहने वाली अन्य प्रोसेस के आधार पर किया जाता है. उदाहरण के लिए, अगर प्रोसेस A को Context.BIND_AUTO_CREATE फ़्लैग के साथ Service से बंधा है या प्रोसेस B में ContentProvider का इस्तेमाल किया जा रहा है, तो प्रोसेस B की कैटगरी हमेशा कम से कम प्रोसेस A की कैटगरी के बराबर ही ज़रूरी होती है.