थ्रेड की सुविधा से ऐप्लिकेशन की परफ़ॉर्मेंस बेहतर हुई

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

मुख्य थ्रेड

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

अंदरूनी

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

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

ऐनिमेशन या स्क्रीन अपडेट होने के दौरान, सिस्टम हर 16 मि॰से॰ में ब्लॉक ऑफ़ वर्क 60 पर आसानी से रेंडर होने के लिए फ़्रेम प्रति सेकंड में न दिखाई जाए. सिस्टम इस लक्ष्य तक पहुंच सके, इसके लिए यूज़र इंटरफ़ेस (यूआई)/व्यू हैरारकी मुख्य थ्रेड पर अपडेट होना चाहिए. हालांकि, जब मुख्य थ्रेड की मैसेज सूची में इसमें ऐसे टास्क हैं जो मुख्य थ्रेड के लिए बहुत ज़्यादा या बहुत लंबे हैं अपडेट तेज़ी से पूरा करें, ऐप्लिकेशन इस काम को किसी वर्कर पर ले जाएगा थ्रेड. अगर मुख्य थ्रेड 16 मि॰से॰ के अंदर ब्लॉक को एक्ज़ीक्यूट नहीं कर पाता है, ऐसा हो सकता है कि उपयोगकर्ता को इनपुट में अपने-आप होने वाली गड़बड़ी, रुक-रुककर चलने वाले या यूज़र इंटरफ़ेस (यूआई) के रिस्पॉन्स में समस्या दिखे. अगर मुख्य थ्रेड करीब पांच सेकंड के लिए रुक जाती है, तो सिस्टम दिखता है आवेदन 'रिस्पॉन्स नहीं दिया जा रहा है' (ANR) डायलॉग, जिससे उपयोगकर्ता सीधे ऐप्लिकेशन बंद कर सकते हैं.

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

थ्रेड और यूज़र इंटरफ़ेस (यूआई) ऑब्जेक्ट के रेफ़रंस

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

पहचान फ़ाइलों से जुड़ी समस्याओं को दो अलग-अलग कैटगरी में रखा जाता है: अश्लील पहचान फ़ाइलें और इंप्लिसिट रेफ़रंस शामिल हैं.

एक्सप्लिसिट रेफ़रंस

जो थ्रेड मुख्य नहीं हैं उनके कई टास्क का लक्ष्य, यूज़र इंटरफ़ेस (यूआई) ऑब्जेक्ट अपडेट करना होता है. हालांकि, अगर इनमें से कोई थ्रेड, व्यू हैरारकी में किसी ऑब्जेक्ट को ऐक्सेस करता है, तो ऐप्लिकेशन इंस्टॉल न हो पाने का नतीजा यह हो सकता है: अगर कोई वर्कर थ्रेड वह ऑब्जेक्ट उसी समय शामिल करें जब कोई दूसरा थ्रेड उस ऑब्जेक्ट को रेफ़र कर रहा हो, नतीजे तय नहीं हैं.

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

एक अन्य उदाहरण में, View ऑब्जेक्ट में गतिविधि की जानकारी शामिल है उनका मालिकाना हक उनके पास है. अगर आपने वह गतिविधि खत्म हो जाती है, लेकिन काम का थ्रेड वाला ब्लॉक मौजूद रहता है, में कहा गया है कि—सीधे तौर पर या किसी दूसरे तरीके से—कचरा इकट्ठा करने वाला टूल, गतिविधि को तब तक नहीं चलाया जा सकता, जब तक कि काम के उस ब्लॉक का निष्पादन पूरा नहीं हो जाता.

इस स्थिति की वजह से, उन स्थितियों में समस्या आ सकती है जिनमें थ्रेड वाला काम हो सकता है फ़्लाइट के दौरान कुछ गतिविधि का लाइफ़साइकल इवेंट होता है, जैसे कि स्क्रीन का घुमाव. फ़्लाइट के उड़ान भरने से पहले तक, सिस्टम कचरा इकट्ठा नहीं कर पाएगा काम पूरा होता है. इस वजह से, इसमें दो Activity ऑब्जेक्ट हो सकते हैं कचरा इकट्ठा करने तक मेमोरी.

हमारा सुझाव है कि आप इस तरह की स्थितियों में, अश्लील कॉन्टेंट को शामिल न करें थ्रेड वाले काम के टास्क में यूज़र इंटरफ़ेस (यूआई) ऑब्जेक्ट के रेफ़रंस. ऐसी पहचान फ़ाइलों से बचने से, इस तरह की मेमोरी लीक होने से बचाने में मदद मिलेगी.

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

इंप्लिसिट रेफ़रंस

थ्रेड किए गए ऑब्जेक्ट के साथ एक सामान्य कोड-डिज़ाइन गड़बड़ी को कोड यहां दिया गया है:

class MainActivity : Activity() {
    // ...
    inner class MyAsyncTask : AsyncTask<Unit, Unit, String>() {
        override fun doInBackground(vararg params: Unit): String {...}
        override fun onPostExecute(result: String) {...}
    }
}

public class MainActivity extends Activity {
  // ...
  public class MyAsyncTask extends AsyncTask<Void, Void, String>   {
    @Override protected String doInBackground(Void... params) {...}
    @Override protected void onPostExecute(String result) {...}
  }
}

इस स्निपेट में गलती यह है कि कोड, थ्रेडिंग ऑब्जेक्ट का एलान करता है कुछ गतिविधि (या इनर क्लास) की नॉन-स्टैटिक इनर क्लास के तौर पर MyAsyncTask Kotlin में. इस एलान से, Activity के अंदर का इंप्लिसिट रेफ़रंस बन जाता है इंस्टेंस. इस वजह से, ऑब्जेक्ट में गतिविधि का रेफ़रंस होता है, जब तक थ्रेड वाला काम पूरा होता है, जिसकी वजह से रेफ़र की गई गतिविधि पूरी होने में देरी होती है. वहीं इस वजह से, मेमोरी पर ज़्यादा दबाव पड़ता है.

इस समस्या का एक सीधा समाधान आपकी ओवरलोडेड क्लास को परिभाषित करना होगा. इंस्टेंस या तो स्थिर क्लास के रूप में या अपनी खुद की फ़ाइलों में देते हैं. इंप्लिसिट रेफ़रंस.

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

थ्रेड और ऐप्लिकेशन पर की गई गतिविधि की लाइफ़साइकल

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

स्थायी धागे

ये थ्रेड उन गतिविधियों के बाद भी बने रहते हैं जिन्होंने उन्हें जन्म दिया है. बातचीत के थ्रेड की निर्माण या नष्ट होने की परवाह किए बिना, बिना किसी रुकावट के चलाना जारी रखना है हालांकि, आवेदन प्रक्रिया के साथ-साथ उन सेवाओं को भी खत्म कर दिया जाएगा. और सक्रिय ऐप्लिकेशन घटक होते हैं. कुछ मामलों में, यह लगातार बने रहना ज़रूरी है.

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

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

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

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

थ्रेड की प्राथमिकता

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

हर बार थ्रेड बनाने पर, आपको कॉल करना चाहिए setThreadPriority(). सिस्टम का थ्रेड शेड्यूलर, ज़्यादा प्राथमिकता वाले थ्रेड को प्राथमिकता देता है. इससे, साथ ही, वे सभी काम पूरे कर सकें. आम तौर पर, थ्रेड फ़ोरग्राउंड में ग्रुप को डिवाइस इस्तेमाल करने में लगने वाले कुल समय का करीब 95% हिस्सा मिलता है. वहीं, बैकग्राउंड ग्रुप की संख्या करीब 5% है.

इसका इस्तेमाल करके, सिस्टम हर थ्रेड को अपना प्राथमिकता मान भी असाइन करता है Process क्लास.

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

Process क्लास इन कॉन्सटेंट का वह सेट जिसका इस्तेमाल आपका ऐप्लिकेशन थ्रेड की प्राथमिकताएं सेट करने के लिए कर सकता है. उदाहरण के लिए, THREAD_PRIORITY_DEFAULT अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है यह थ्रेड की डिफ़ॉल्ट वैल्यू दिखाता है. आपके ऐप्लिकेशन को थ्रेड की प्राथमिकता इस पर सेट करनी चाहिए: THREAD_PRIORITY_BACKGROUND अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है का इस्तेमाल करें.

आपका ऐप्लिकेशन, THREAD_PRIORITY_LESS_FAVORABLE का इस्तेमाल कर सकता है और THREAD_PRIORITY_MORE_FAVORABLE मिलती-जुलती प्राथमिकताएं सेट करने के लिए, बढ़ोतरी करने वाले के तौर पर कॉन्सटेंट. इनकी सूची के लिए थ्रेड की प्राथमिकताएं, THREAD_PRIORITY कॉन्सटेंट इंच Process क्लास.

अगर आपको ज़्यादा जानकारी चाहिए, तो थ्रेड मैनेज करते समय, Thread और Process क्लास.

थ्रेडिंग के लिए हेल्पर क्लास

Kotlin का इस्तेमाल करने वाले डेवलपर को हम कोरूटीन का इस्तेमाल करने का सुझाव देते हैं. कोरूटीन के कई फ़ायदे हैं. जैसे, कॉलबैक के बिना एक साथ काम नहीं करने वाला कोड लिखना और स्कोपिंग, रद्द करने, और गड़बड़ियों को ठीक करने के लिए स्ट्रक्चर्ड एक साथ कई काम करना.

यह फ़्रेमवर्क, आसान Java क्लास और प्रिमिटिव भी देता है, ताकि थ्रेडिंग, जैसे कि Thread, Runnable , और Executors क्लास, साथ ही, HandlerThread जैसी अन्य प्रॉम्प्ट भी दिखेंगी. ज़्यादा जानकारी के लिए, कृपया Android पर थ्रेडिंग की सुविधा लेख पढ़ें.

हैंडलरThread क्लास

हैंडलर थ्रेड, लंबे समय तक चलने वाला थ्रेड होता है. यह सूची से काम लेकर, ऑपरेट करता है उस पर.

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

इस उदाहरण में, जब आपका ऐप्लिकेशन किसीCamera.open() हैंडलर थ्रेड पर काम का ब्लॉक, संबंधित onPreviewFrame() कॉलबैक यह यूज़र इंटरफ़ेस (यूआई) थ्रेड के बजाय, हैंडलर थ्रेड पर लैंड होता है. इसलिए, अगर आपको लंबे समय तक काम करते हैं, तो यह आपके लिए एक बेहतर समाधान हो सकता है.

जब आपका ऐप्लिकेशन HandlerThread का इस्तेमाल करके थ्रेड बनाता है, तो यह काम न करें थ्रेड को सेट करना भूल जाओ अपने काम के हिसाब से तय करना. याद रखें, सीपीयू (CPU) ही काम कर सकते हैं साथ ही कुछ थ्रेड को हैंडल से जोड़ सकते हैं. प्राथमिकता तय करने से मदद मिलती है जब बाकी सभी थ्रेड में इस काम को शेड्यूल किया जाता है, तो सिस्टम को इस काम को शेड्यूल करने के सही तरीके पता होते हैं ध्यान खींचने की कोशिश कर रहे हैं.

ThreadPoolexeutor क्लास

कुछ ऐसे काम होते हैं जिन्हें कम करके, बिलकुल एक जैसे डिस्ट्रिब्यूट किए गए टास्क. उदाहरण के लिए, ऐसा ही एक टास्क है हर एक के लिए एक फ़िल्टर कैलकुलेट करना 8 मेगापिक्सल इमेज का 8x8 ब्लॉक. काम के पैकेट की भारी मात्रा को देखते हुए यह बनाता है, तो HandlerThread इस्तेमाल करने के लिए सही क्लास नहीं है.

ThreadPoolExecutor एक हेल्पर क्लास है इस प्रक्रिया को और आसान बनाया है. यह क्लास थ्रेड का एक ग्रुप, सेट बनाने का काम मैनेज करती है वह अपनी प्राथमिकताएं तय करती है. साथ ही, मैनेज करती है कि काम किस तरह से बांटा जाए. जैसे-जैसे वर्कलोड बढ़ता या घटता है, क्लास स्पिन होती है या ज़्यादा थ्रेड मिट जाती है वर्कलोड के हिसाब से खुद को अडजस्ट किया जा सकता है.

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

आपको कितने थ्रेड बनाने चाहिए?

हालांकि सॉफ़्टवेयर स्तर से, आपके कोड में सैकड़ों थ्रेड न किया हो, तो ऐसा करने से परफ़ॉर्मेंस से जुड़ी समस्याएं आ सकती हैं. आपके ऐप्लिकेशन का सीपीयू सीमित तौर पर इस्तेमाल होता है बैकग्राउंड सेवाओं, रेंडरर, ऑडियो इंजन, नेटवर्किंग वगैरह. सीपीयू में सिर्फ़ वे चीज़ें होती हैं साथ-साथ कुछ थ्रेड को हैंडल करने की सुविधा; उससे ऊपर दी गई हर चीज़ प्राथमिकता और शेड्यूल करने की समस्या में शामिल किया गया हो. इसलिए, यह ज़रूरी है कि आप जितने थ्रेड की ज़रूरत होगी.

व्यावहारिक तौर पर, इसके लिए कई चीज़ें ज़िम्मेदार हैं. हालांकि, कोई वैल्यू चुनकर (जैसे, स्टार्टर के लिए 4), और उसकी जांच Systrace ऐसा होता है मज़बूत रणनीति बनाई है. ट्रायल ऐंड एरर का इस्तेमाल करके, तय करें कि कम से कम कितने थ्रेड का इस्तेमाल किया जा सके. साथ ही, इससे कोई समस्या नहीं होनी चाहिए.

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

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