जब ऐप्लिकेशन का कोई कॉम्पोनेंट शुरू होता है और ऐप्लिकेशन में कोई दूसरा कॉम्पोनेंट नहीं होता है चालू है, तो Android सिस्टम लागू करता है. डिफ़ॉल्ट रूप से, एक ही ऐप्लिकेशन के सभी कॉम्पोनेंट एक ही प्रोसेस और थ्रेड में चलते हैं, को मुख्य थ्रेड कहते हैं.
अगर कोई ऐप्लिकेशन कॉम्पोनेंट शुरू होता है और पहले से ही कोई प्रोसेस चल रही है उस ऐप्लिकेशन के लिए है, क्योंकि ऐप्लिकेशन का एक दूसरा घटक पहले ही शुरू हो चुका है, इसलिए वह घटक उसी प्रोसेस के अंदर शुरू होता है और एक्ज़ीक्यूशन के उसी थ्रेड का इस्तेमाल करता है. हालांकि, अब आपके पास अलग-अलग प्रक्रियाओं में चलाने के लिए आपके ऐप्लिकेशन के अलग-अलग घटक मौजूद हैं, और आप अतिरिक्त थ्रेड का इस्तेमाल किया जा सकता है.
इस दस्तावेज़ में बताया गया है कि किसी Android ऐप्लिकेशन में प्रोसेस और थ्रेड कैसे काम करते हैं.
प्रक्रियाएं
डिफ़ॉल्ट रूप से, किसी ऐप्लिकेशन के सभी कॉम्पोनेंट एक ही प्रोसेस में चलते हैं. साथ ही, ज़्यादातर ऐप्लिकेशन इसे मत बदलो. हालांकि, अगर आपको लगता है कि आपको यह तय करने की ज़रूरत है कि तो मेनिफ़ेस्ट फ़ाइल में जाकर ऐसा किया जा सकता है.
हर तरह के कॉम्पोनेंट एलिमेंट के लिए मेनिफ़ेस्ट एंट्री—<activity>
, <service>
, <receiver>
, और <provider>
—ऐसे android:process
एट्रिब्यूट के साथ काम करता है जो
प्रोसेस करता है जिसमें कॉम्पोनेंट काम करता है. आप इस एट्रिब्यूट को सेट कर सकते हैं, ताकि हर कॉम्पोनेंट काम कर सके
वह भी प्रोसेस में शामिल हो, ताकि कुछ कॉम्पोनेंट पहले से मौजूद हों और कुछ नहीं.
इन्हें भी सेट किया जा सकता है
android:process
ताकि अलग-अलग ऐप्लिकेशन के कॉम्पोनेंट एक ही
प्रक्रिया में शामिल हैं, बशर्ते ऐप्लिकेशन एक ही Linux उपयोगकर्ता आईडी शेयर करें और
एक ही प्रमाणपत्र.
<application>
एलिमेंट में android:process
एट्रिब्यूट भी काम करता है, जिसका इस्तेमाल
डिफ़ॉल्ट वैल्यू है जो सभी कॉम्पोनेंट पर लागू होती है.
ऐसा हो सकता है कि Android कभी भी किसी प्रोसेस को बंद कर दे, जब संसाधन उन प्रोसेस की ज़रूरत पड़ सकती है जो उपयोगकर्ता को तुरंत सेवा दे रही हैं. आवेदन करने का टूल शट डाउन की प्रोसेस में चल रहे कॉम्पोनेंट की वजह से, वे पूरी तरह खत्म हो जाते हैं. प्रोसेस शुरू की गई फिर से सबमिट करना होगा, जब उनके लिए काम करने की ज़रूरत होगी.
यह तय करते समय कि किन प्रोसेस को बंद करना है, Android सिस्टम यह ध्यान में रखता है कि उपयोगकर्ता है. उदाहरण के लिए, यह ऐसी गतिविधियों को होस्ट करने की प्रोसेस को पूरी तरह बंद कर देता है जो अब स्क्रीन पर, किसी प्रोसेस को होस्ट करने वाली प्रोसेस की तुलना में. फ़ैसला लेने के लिए कि इसलिए, यह उस प्रोसेस में चल रहे कॉम्पोनेंट की स्थिति पर निर्भर करता है.
प्रोसेस की लाइफ़साइकल और ऐप्लिकेशन की स्थितियों के साथ इसके संबंध के बारे में जानकारी दी गई है प्रोसेस और ऐप्लिकेशन का लाइफ़साइकल.
थ्रेड
जब कोई ऐप्लिकेशन लॉन्च होता है, तो सिस्टम उस ऐप्लिकेशन को चलाने के लिए एक थ्रेड बनाता है,
को मुख्य थ्रेड कहा जाता है. यह थ्रेड बहुत अहम है, क्योंकि यह इन इवेंट को भेजने का काम
सही यूज़र इंटरफ़ेस विजेट, जिसमें ड्रॉइंग इवेंट भी शामिल हों. यह भी है
करीब-करीब हमेशा वह थ्रेड जिसमें आपका ऐप्लिकेशन कॉम्पोनेंट से इंटरैक्ट करता है
'Android यूज़र इंटरफ़ेस (यूआई) टूलकिट' के android.widget
से और
android.view
पैकेज.
इस वजह से, कभी-कभी मुख्य थ्रेड
इसे यूज़र इंटरफ़ेस (यूआई) थ्रेड कहा जाता है. हालांकि, विशेष परिस्थितियों में, ऐप्लिकेशन का मुख्य
शायद थ्रेड यूज़र इंटरफ़ेस (यूआई) थ्रेड न हो. ज़्यादा जानकारी के लिए, Thread की वैल्यू देखें
एनोटेशन.
सिस्टम, कॉम्पोनेंट के हर इंस्टेंस के लिए अलग थ्रेड नहीं बनाता. सभी
समान प्रक्रिया में चलने वाले कॉम्पोनेंट, यूज़र इंटरफ़ेस (यूआई) थ्रेड में इंस्टैंशिएट किए जाते हैं और
हर कॉम्पोनेंट को उस थ्रेड से भेजा जाता है. इस वजह से, सिस्टम को नुकसान पहुंचाने वाले तरीके
कॉलबैक—जैसे कि onKeyDown()
या लाइफ़साइकल कॉलबैक मेथड को रिपोर्ट करने के लिए कहा जाता है, तो यह प्रोसेस हमेशा यूज़र इंटरफ़ेस (यूआई) थ्रेड में चलती है.
उदाहरण के लिए, जब उपयोगकर्ता स्क्रीन पर किसी बटन को छूता है, तो आपके ऐप्लिकेशन का यूज़र इंटरफ़ेस (यूआई) थ्रेड, टच इवेंट को विजेट पर जोड़ा जाता है, जिससे इसकी दबाई गई स्थिति सेट हो जाती है और एक अमान्य अनुरोध इवेंट सूची. यूज़र इंटरफ़ेस (यूआई) थ्रेड, अनुरोध को खत्म करता है और विजेट को फिर से खोलने के लिए सूचना देता है वह भी ऐसा कर सकता है.
जब तक आप अपने ऐप्लिकेशन को ठीक से लागू नहीं करते, तब तक यह सिंगल-थ्रेड मॉडल जब आपका ऐप्लिकेशन, उपयोगकर्ता इंटरैक्शन की वजह से बहुत ज़्यादा काम करता है, तो यह ऐप्लिकेशन को खराब परफ़ॉर्मेंस दे सकता है. यूज़र इंटरफ़ेस (यूआई) थ्रेड में लंबे ऑपरेशन करना, जैसे कि नेटवर्क का ऐक्सेस या डेटाबेस क्वेरी, पूरे यूज़र इंटरफ़ेस (यूआई) को ब्लॉक करता है. थ्रेड के ब्लॉक होने पर, कोई भी इवेंट भेजा नहीं जा सकता, जिसमें ड्रॉइंग इवेंट भी शामिल हैं.
उपयोगकर्ता के नज़रिये से, ऐप्स हैंग दिखता है. अगर यूज़र इंटरफ़ेस (यूआई) थ्रेड कुछ सेकंड से ज़्यादा समय के लिए ब्लॉक रहती है, तो इससे भी खराब बात यह है कि उपयोगकर्ता को "अनुभव जवाब दे रहा है" (ANR) डायलॉग. इसके बाद, उपयोगकर्ता आपके ऐप्लिकेशन को बंद कर सकता है या उसे अनइंस्टॉल भी कर सकता है इसे.
ध्यान रखें कि 'Android यूज़र इंटरफ़ेस (यूआई) टूलकिट' को थ्रेड से सुरक्षित नहीं किया जा सकता. इसलिए, चालाकी से वर्कर थ्रेड में बनाया गया आपका यूज़र इंटरफ़ेस (यूआई) है. यूज़र इंटरफ़ेस (यूआई) से अपने यूज़र इंटरफ़ेस में सभी बदलाव करें थ्रेड. Android के सिंगल-थ्रेड मॉडल के दो नियम हैं:
- यूज़र इंटरफ़ेस (यूआई) थ्रेड को ब्लॉक न करें.
- यूज़र इंटरफ़ेस (यूआई) थ्रेड के बाहर से, 'Android यूज़र इंटरफ़ेस (यूआई) टूलकिट' को ऐक्सेस न करें.
वर्कर थ्रेड
इस सिंगल-थ्रेड मॉडल की वजह से, यह ज़रूरी है कि आपकी वेबसाइट ऐसा यूज़र इंटरफ़ेस (यूआई) जिसमें यूज़र इंटरफ़ेस (यूआई) थ्रेड को ब्लॉक नहीं किया जाता. अगर आपको कुछ कार्रवाइयां करनी हैं, तो जो तुरंत नहीं दिखते, उनके लिए अलग-अलग बैकग्राउंड में जाएं या worker थ्रेड के लिए. बस यह ध्यान रखें कि आप यूज़र इंटरफ़ेस (यूआई) को सिर्फ़ ऐसे थ्रेड से अपडेट नहीं कर सकते यूज़र इंटरफ़ेस (यूआई) या मुख्य थ्रेड.
इन नियमों का पालन करने में आपकी मदद करने के लिए, Android ऐसे कई तरीके ऑफ़र करता है जिनसे यूज़र इंटरफ़ेस (यूआई) थ्रेड को ऐक्सेस किया जा सकता है. थ्रेड. यहां उन तरीकों की सूची दी गई है जिनसे आपको मदद मिल सकती है:
नीचे दिए गए उदाहरण में View.post(Runnable)
का इस्तेमाल किया गया है:
Kotlin
fun onClick(v: View) { Thread(Runnable { // A potentially time consuming task. val bitmap = processBitMap("image.png") imageView.post { imageView.setImageBitmap(bitmap) } }).start() }
Java
public void onClick(View v) { new Thread(new Runnable() { public void run() { // A potentially time consuming task. final Bitmap bitmap = processBitMap("image.png"); imageView.post(new Runnable() { public void run() { imageView.setImageBitmap(bitmap); } }); } }).start(); }
यह लागू करने की प्रक्रिया थ्रेड का इस्तेमाल नहीं कर सकती, क्योंकि बैकग्राउंड में होने वाली कार्रवाई एक अलग थ्रेड से की जाती है
जबकि ImageView
में हमेशा यूज़र इंटरफ़ेस (यूआई) थ्रेड से बदलाव किया जाता है.
हालांकि, जैसे-जैसे ऑपरेशन की जटिलता बढ़ती जाएगी, इस तरह का कोड जटिल हो सकता है और
बनाए रखने में मुश्किल होती है. वर्कर थ्रेड के साथ ज़्यादा मुश्किल इंटरैक्शन को मैनेज करने के लिए,
अपने वर्कर थ्रेड में Handler
का इस्तेमाल करके
यूज़र इंटरफ़ेस (यूआई) थ्रेड से डिलीवर किए गए मैसेज को प्रोसेस करने के लिए. पूरी जानकारी पाने के लिए,
बैकग्राउंड थ्रेड पर काम शेड्यूल करें और यूज़र इंटरफ़ेस (यूआई) थ्रेड पर वापस बातचीत करें, देखें
बैकग्राउंड में काम के बारे में खास जानकारी.
थ्रेड-सुरक्षित तरीके
कुछ मामलों में, लागू किए गए तरीकों को एक से ज़्यादा थ्रेड से कॉल किया जाता है और इसलिए, इसे थ्रेड-सुरक्षित होने के लिए लिखा जाना चाहिए.
यह मुख्य तौर पर उन तरीकों के लिए सही होता है जिन्हें रिमोट तरीके से कॉल किया जा सकता है, जैसे कि बाउंड सेवा के तरीके. जब किसी
IBinder
में लागू किया गया तरीका उसी प्रोसेस से शुरू होता है जिसमें
IBinder
चालू है. कॉलर के थ्रेड में तरीका लागू किया जाता है.
हालांकि, जब कॉल किसी दूसरी प्रोसेस से शुरू होता है, तो वह तरीका चुने गए थ्रेड में लागू होता है
थ्रेड का पूल होता है जिसे सिस्टम उसी प्रोसेस में बनाए रखता है जिसमें IBinder
.
इसे प्रोसेस के यूज़र इंटरफ़ेस (यूआई) थ्रेड में एक्ज़ीक्यूट नहीं किया जाता है.
उदाहरण के लिए, जबकि किसी सेवा का
onBind()
तरीका को इसके यूज़र इंटरफ़ेस (यूआई) थ्रेड से कॉल किया गया है
सेवा की प्रोसेस या उस ऑब्जेक्ट में लागू किए गए तरीके जिन्हें onBind()
दिखाता है, जैसे कि
रिमोट प्रोसेस कॉल (आरपीसी) वाले तरीकों को लागू करने वाली सब-क्लास, थ्रेड की मदद से कॉल की जाती है
पूल में. किसी सेवा में एक से ज़्यादा क्लाइंट हो सकते हैं. इसलिए, एक से ज़्यादा पूल थ्रेड कनेक्ट हो सकती हैं
एक ही समय पर IBinder
तरीके का इस्तेमाल करें. इसलिए, IBinder
वाले तरीके ऐसा होने चाहिए
थ्रेड-सुरक्षित करने के लिए लागू किया गया.
इसी तरह, कॉन्टेंट देने वाले को अन्य प्रोसेस से जनरेट होने वाले डेटा के अनुरोध मिल सकते हैं.
ContentResolver
और ContentProvider
क्लास, इंटरप्रोसेस कम्यूनिकेशन (आईपीसी) को मैनेज करने के तरीके की जानकारी को छिपा देती हैं,
उन अनुरोधों के जवाब देने वाले ContentProvider
तरीके—
query()
,
insert()
,
delete()
,
update()
,
और getType()
—हैं
कॉन्टेंट देने वाले की प्रोसेस में थ्रेड के पूल से कॉल किया जाता है, न कि यूज़र इंटरफ़ेस (यूआई) से
थ्रेड पर क्लिक करें. क्योंकि इन तरीकों को
साथ ही, उन्हें भी थ्रेड-सुरक्षित मोड में लागू किया जाना चाहिए.
इंटरप्रोसेस कम्यूनिकेशन
Android, आरपीसी का इस्तेमाल करके आईपीसी के लिए एक तरीका उपलब्ध कराता है. इसमें किसी गतिविधि या अन्य ऐप्लिकेशन के ज़रिए किसी तरीके को कॉल किया जाता है में बनाया गया है, लेकिन उसे किसी दूसरी प्रोसेस में रिमोट तरीके से चलाया गया है और कोई भी नतीजा कॉलर है. ऐसा करने पर, मेथड से जुड़ी कॉल और उसके डेटा को ऑपरेटिंग सिस्टम के हिसाब से डिकोड करना पड़ता है उसे समझना, स्थानीय प्रोसेस और पते वाले स्पेस से रिमोट प्रोसेस में भेजना और तय किया जा सकता है और फिर कॉल को फिर से जोड़कर उसे फिर से पेश किया जा सकता है.
रिटर्न वैल्यू इसके बाद की होती हैं विपरीत दिशा में ट्रांसमिट किया जाता है. Android, इन आईपीसी से जुड़े सभी कोड उपलब्ध कराता है लेन-देन की रिपोर्ट तैयार की है, ताकि आप RPC प्रोग्रामिंग इंटरफ़ेस तय करने और लागू करने पर फ़ोकस कर सकें.
आईपीसी लागू करने के लिए, आपके ऐप्लिकेशन को bindService()
का इस्तेमाल करने वाली किसी सेवा से जुड़ना होगा. ज़्यादा जानकारी के लिए, सेवाओं की खास जानकारी देखें.