ऐप्लिकेशन चालू होने में लगने वाला समय, उपयोगकर्ताओं पर आपके ऐप्लिकेशन का पहला इंप्रेशन होता है. उपयोगकर्ताओं को इंतज़ार करना पसंद नहीं होता. इसलिए, आपको यह पक्का करना होगा कि आपका ऐप्लिकेशन तेज़ी से शुरू हो. आपको यह दिखाने के लिए कि ऐप्लिकेशन डेवलपमेंट टीम ने अपने ऐप्लिकेशन के स्टार्टअप से जुड़ी समस्याओं का पता कैसे लगाया और उनका निदान कैसे किया, यहां Gmail Wear OS टीम की कार्रवाई के बारे में बताया गया है.
Gmail Wear OS टीम ने ऐप्लिकेशन की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए काम किया. इसमें खास तौर पर, ऐप्लिकेशन के स्टार्टअप और रनटाइम रेंडरिंग की परफ़ॉर्मेंस पर फ़ोकस किया गया, ताकि टीम के ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़े मानदंड पूरे किए जा सकें. हालांकि, अगर आपके पास टारगेट करने के लिए कोई खास थ्रेशोल्ड नहीं है, तो भी ऐप्लिकेशन के स्टार्टअप को बेहतर बनाया जा सकता है. इसके लिए, आपको कुछ समय निकालकर इसकी जांच करनी होगी.
ट्रेस कैप्चर करना और ऐप्लिकेशन के स्टार्टअप को देखना
विश्लेषण शुरू करने के लिए, एक ट्रेस कैप्चर करें. इसमें ऐप्लिकेशन के स्टार्टअप की जानकारी शामिल होनी चाहिए, ताकि Perfetto या Android Studio में इसकी बारीकी से जांच की जा सके. इस केस स्टडी में Perfetto का इस्तेमाल किया गया है. ऐसा इसलिए, क्योंकि यह आपके ऐप्लिकेशन के अलावा, डिवाइस के सिस्टम में हो रही गतिविधियों के बारे में भी जानकारी देता है. Perfetto में ट्रेस अपलोड करने पर, यह इस तरह दिखता है:
हमारा फ़ोकस ऐप्लिकेशन के स्टार्टअप को बेहतर बनाने पर है. इसलिए, Android ऐप्लिकेशन के स्टार्टअप कस्टम मेट्रिक वाली लाइन ढूंढें. इसे अपनी व्यू में सबसे ऊपर पिन करने के लिए, लाइन पर कर्सर घुमाएं और पिन आइकॉन 
पर क्लिक करें. आपको Android ऐप्लिकेशन चालू होने में लगने वाला समय लाइन में जो बार या स्लाइस दिखता है उससे पता चलता है कि ऐप्लिकेशन चालू होने में कितना समय लगा. यह समय, ऐप्लिकेशन का पहला फ़्रेम स्क्रीन पर दिखने तक का होता है. इसलिए, आपको यहां समस्याएं या रुकावटें ढूंढनी चाहिए.
ध्यान दें कि Android ऐप्लिकेशन के स्टार्टअप मेट्रिक, शुरुआती डिसप्ले में लगने वाले समय को दिखाती है. भले ही, reportFullyDrawn() का इस्तेमाल किया जा रहा हो. पूरी तरह से दिखने में लगने वाले समय का पता लगाने के लिए, Perfetto के खोज बॉक्स में reportFullyDrawn() खोजें.
मुख्य थ्रेड की जांच करना
सबसे पहले, देखें कि मुख्य थ्रेड पर क्या हो रहा है. मुख्य थ्रेड बहुत ज़रूरी होती है, क्योंकि आम तौर पर यूज़र इंटरफ़ेस (यूआई) रेंडरिंग इसी थ्रेड में होती है. जब यह थ्रेड ब्लॉक हो जाती है, तो कोई भी ड्राइंग नहीं हो पाती और आपका ऐप्लिकेशन फ़्रीज़ हो जाता है. इसलिए, आपको यह पक्का करना होगा कि मुख्य थ्रेड पर कोई भी लंबी प्रोसेस न चल रही हो.
मुख्य थ्रेड ढूंढने के लिए, अपने ऐप्लिकेशन के पैकेज के नाम वाली लाइन ढूंढें और उसे बड़ा करें. पैकेज के नाम वाली दो लाइनें (आम तौर पर, सेक्शन की पहली दो लाइनें) मुख्य थ्रेड को दिखाती हैं. दो मुख्य थ्रेड लाइनों में से, पहली लाइन सीपीयू की स्थिति और दूसरी लाइन ट्रेसपॉइंट को दिखाती है. Android ऐप्लिकेशन स्टार्टअप मेट्रिक के नीचे मौजूद, दो मुख्य थ्रेड वाली लाइनों को पिन करें.
रनेबल स्टेट में बिताया गया समय और सीपीयू का इस्तेमाल
ऐप्लिकेशन के चालू होने के दौरान सीपीयू की गतिविधि की कुल जानकारी पाने के लिए, अपने कर्सर को मुख्य थ्रेड पर खींचें. इससे ऐप्लिकेशन के चालू होने की समयावधि कैप्चर की जा सकेगी. दिखने वाला थ्रेड की स्थितियां पैनल, आपको चुनी गई समयावधि के दौरान हर सीपीयू की स्थिति में बिताए गए कुल समय के बारे में बताता है.
Runnable स्थिति में बिताए गए समय को देखें. जब कोई थ्रेड Runnable स्थिति में होता है, तो वह काम करने के लिए उपलब्ध होता है. हालांकि, उसके लिए कोई काम शेड्यूल नहीं किया जाता है. इससे पता चलता है कि डिवाइस पर ज़्यादा लोड है और वह ज़्यादा प्राथमिकता वाले टास्क शेड्यूल नहीं कर पा रहा है. उपयोगकर्ता को दिखने वाले सबसे ऊपर के ऐप्लिकेशन को शेड्यूल करने में सबसे ज़्यादा प्राथमिकता दी जाती है. इसलिए, मुख्य थ्रेड के निष्क्रिय होने का मतलब अक्सर यह होता है कि आपके ऐप्लिकेशन में ज़्यादा सीपीयू इस्तेमाल करने वाली प्रोसेस, जैसे कि ऐनिमेशन रेंडरिंग, सीपीयू टाइम के लिए मुख्य थ्रेड के साथ प्रतिस्पर्धा कर रही हैं.
Runnable से Running स्थितियों में लगने वाले समय का आकलन करें, ताकि यह पता चल सके कि सीपीयू का इस्तेमाल कितना हो रहा है.Runnable स्थिति में बिताए गए समय और Running स्थिति में बिताए गए समय का अनुपात जितना ज़्यादा होगा, सीपीयू के इस्तेमाल को लेकर विवाद होने की संभावना उतनी ही ज़्यादा होगी. इस तरह से परफ़ॉर्मेंस से जुड़ी समस्याओं की जांच करते समय, सबसे पहले सबसे लंबे समय तक चलने वाले फ़्रेम पर ध्यान दें. इसके बाद, छोटे फ़्रेम पर काम करें.
Runnable स्टेट में बिताए गए समय का विश्लेषण करते समय, डिवाइस के हार्डवेयर पर ध्यान दें.
दिखाया गया ऐप्लिकेशन, दो सीपीयू वाले वियरेबल डिवाइस पर चल रहा है. इसलिए, यह उम्मीद की जाती है कि Runnable स्थिति में ज़्यादा समय बिताया जाएगा और अन्य प्रोसेस के साथ सीपीयू का ज़्यादा इस्तेमाल किया जाएगा. ऐसा तब होता है, जब हम ज़्यादा सीपीयू वाले डिवाइस को देखते हैं. फ़ोन ऐप्लिकेशन के लिए, Runnable स्थिति में ज़्यादा समय लगता है. हालांकि, यह वियरेबल के हिसाब से सही हो सकता है.
OpenDexFilesFromOat* में बिताया गया समय
अब OpenDexFilesFromOat* में बिताया गया समय देखें. ट्रेस में, यह bindApplication स्लाइस के साथ ही होता है. इस स्लाइस में, ऐप्लिकेशन की DEX फ़ाइलों को पढ़ने में लगने वाला समय दिखाया गया है.
ब्लॉक किए गए बाइंडर लेन-देन
इसके बाद, बाइंडर के लेन-देन देखें. Binder लेन-देन, क्लाइंट और सर्वर के बीच होने वाले कॉल को दिखाता है: इस मामले में, ऐप्लिकेशन (क्लाइंट) binder transaction के साथ Android सिस्टम (सर्वर) को कॉल करता है. इसके बाद, सर्वर binder
reply के साथ जवाब देता है. पक्का करें कि ऐप्लिकेशन शुरू होने के दौरान, वह गैर-ज़रूरी बाइंडर ट्रांज़ैक्शन न करे. इससे सीपीयू के इस्तेमाल में टकराव का खतरा बढ़ जाता है. अगर हो सके, तो
बाइंडर कॉल से जुड़े काम को ऐप्लिकेशन के स्टार्टअप के बाद के लिए टाल दें. अगर आपको बाइंडर ट्रांज़ैक्शन करने हैं, तो पक्का करें कि वे आपके डिवाइस की वीसिंक रीफ़्रेश रेट से ज़्यादा समय न लें.
इस मामले में, पहला बाइंडर लेन-देन काफ़ी लंबा लग रहा है. आम तौर पर, यह ActivityThreadMain स्लाइस के साथ ही होता है. इस बारे में ज़्यादा जानने के लिए कि क्या हो रहा है, यह तरीका अपनाएं:
- बाइंड किए गए लेन-देन से जुड़ा जवाब देखने और यह जानने के लिए कि बाइंड किए गए लेन-देन को प्राथमिकता कैसे दी जा रही है, बाइंड किए गए लेन-देन के स्लाइस पर क्लिक करें.
बाइंडर का जवाब देखने के लिए, मौजूदा चुना गया आइटम पैनल पर जाएं. इसके बाद, फ़ॉलो की जा रही थ्रेड सेक्शन में जाकर, बाइंडर का जवाब पर क्लिक करें. थ्रेड फ़ील्ड से आपको उस थ्रेड के बारे में भी पता चलता है जिस पर बाइंडर का जवाब दिया गया है. अगर आपको मैन्युअल तरीके से वहां जाना है, तो ऐसा किया जा सकता है. हालांकि, यह एक अलग प्रोसेस होगी. एक लाइन दिखती है, जो बाइंडर के लेन-देन और जवाब को कनेक्ट करती है.
पांचवीं इमेज. ऐप्लिकेशन के स्टार्टअप के दौरान होने वाले बाइंडर ट्रांज़ैक्शन की पहचान करें और आकलन करें कि क्या उन्हें टाला जा सकता है. यह देखने के लिए कि सिस्टम सर्वर इस बाइंडर ट्रांज़ैक्शन को कैसे हैंडल कर रहा है, Cpu 0 और Cpu 1 थ्रेड को अपनी स्क्रीन पर सबसे ऊपर पिन करें.
सिस्टम की उन प्रोसेस का पता लगाएं जो बाइंडर के जवाब को मैनेज करती हैं. इसके लिए, उन स्लाइस को ढूंढें जिनमें बाइंडर के जवाब वाले थ्रेड का नाम शामिल हो. इस मामले में, "Binder:687_11 [2542]" नाम शामिल है. बिंडर लेन-देन के बारे में ज़्यादा जानकारी पाने के लिए, सिस्टम से जुड़ी प्रोसेस पर क्लिक करें.
सीपीयू 0 पर होने वाले, बाइंडिंग से जुड़े लेन-देन से जुड़ी इस सिस्टम प्रोसेस को देखें:
Runnable (Preempted) स्थिति में है. इसका मतलब है कि इसमें देरी हो रही है.एंड स्टेट में Runnable (Preempted) लिखा है. इसका मतलब है कि सीपीयू किसी और काम में लगा है. इसलिए, प्रोसेस में देरी हो रही है. यह पता लगाने के लिए कि किस वजह से थ्रेड को रोका गया है, Ftrace Events पंक्तियों को बड़ा करें. उपलब्ध Ftrace
Events टैब में, स्क्रोल करें और "Binder:687_11 [2542]" से जुड़े इवेंट ढूंढें. सिस्टम प्रोसेस के रुकने के समय के आस-पास, दो सिस्टम सर्वर इवेंट हुए. इनमें "decon" आर्ग्युमेंट शामिल है. इसका मतलब है कि ये डिसप्ले कंट्रोलर से जुड़े हैं. यह सही लगता है, क्योंकि डिसप्ले कंट्रोलर, स्क्रीन पर फ़्रेम दिखाता है. यह एक ज़रूरी काम है! ठीक है, इवेंट में कोई बदलाव नहीं किया जाएगा.
जेआईटी गतिविधि
जस्ट-इन-टाइम कंपाइलेशन (JIT) गतिविधि की जांच करने के लिए, अपने ऐप्लिकेशन से जुड़ी प्रोसेस को बड़ा करें. इसके बाद, "Jit थ्रेड पूल" वाली दो लाइनें ढूंढें और उन्हें अपने व्यू में सबसे ऊपर पिन करें. इस ऐप्लिकेशन को चालू होने के दौरान, बेसलाइन प्रोफ़ाइल से फ़ायदा मिलता है. इसलिए, पहला फ़्रेम दिखने तक बहुत कम JIT गतिविधि होती है. यह गतिविधि, पहले Choreographer.doFrame कॉल के खत्म होने से पता चलती है. हालांकि, JIT compiling void में दिए गए धीमे शुरू होने की वजह पर ध्यान दें. इससे पता चलता है कि Application creation लेबल वाले ट्रेसपॉइंट के दौरान सिस्टम की गतिविधि की वजह से, बैकग्राउंड में बहुत ज़्यादा JIT गतिविधि हो रही है. इस समस्या को हल करने के लिए, पहले फ़्रेम के रेंडर होने के तुरंत बाद होने वाले इवेंट को बेसलाइन प्रोफ़ाइल में जोड़ें. इसके लिए, प्रोफ़ाइल कलेक्शन को तब तक बड़ा करें, जब तक ऐप्लिकेशन इस्तेमाल करने के लिए तैयार न हो जाए. ज़्यादातर मामलों में, ऐसा किया जा सकता है. इसके लिए, आपको अपने बेसलाइन प्रोफ़ाइल कलेक्शन मैक्रोबेंचमार्क टेस्ट के आखिर में एक लाइन जोड़नी होगी. यह लाइन, आपकी स्क्रीन पर किसी खास यूज़र इंटरफ़ेस (यूआई) विजेट के दिखने का इंतज़ार करती है. इससे पता चलता है कि स्क्रीन पर पूरी जानकारी दिख रही है.
नतीजे
इस विश्लेषण के बाद, Gmail Wear OS टीम ने ये सुधार किए:
- उन्हें ऐप्लिकेशन के स्टार्टअप के दौरान, सीपीयू गतिविधि में टकराव दिखा. इसलिए, उन्होंने ऐप्लिकेशन के लोड होने का संकेत देने के लिए इस्तेमाल किए गए स्पिनर ऐनिमेशन को एक स्टैटिक इमेज से बदल दिया. उन्होंने स्प्लैश स्क्रीन को भी लंबा कर दिया, ताकि शimmer स्टेट को टाला जा सके. शimmer स्टेट, दूसरी स्क्रीन की वह स्थिति होती है जिसका इस्तेमाल यह दिखाने के लिए किया जाता है कि ऐप्लिकेशन लोड हो रहा है. ऐसा सीपीयू के संसाधनों को खाली करने के लिए किया गया. इससे ऐप्लिकेशन के खुलने में लगने वाला समय 50% तक कम हो गया.
OpenDexFilesFromOat*और JIT गतिविधि में बिताए गए समय को देखकर, उन्होंने बेसलाइन प्रोफ़ाइलों को R8 की मदद से फिर से लिखने की सुविधा चालू की. इससे ऐप्लिकेशन के शुरू होने में लगने वाले समय में 20% की कमी आई.
ऐप्लिकेशन की परफ़ॉर्मेंस का बेहतर तरीके से विश्लेषण करने के लिए, टीम की ओर से यहां कुछ सलाह दी गई है:
- एक ऐसी प्रोसेस सेट अप करें जो लगातार चलती रहे और अपने-आप ट्रेस और नतीजे इकट्ठा कर सके. मानदंड का इस्तेमाल करके, अपने ऐप्लिकेशन के लिए ऑटोमेटेड ट्रेसिंग सेट अप करें.
- आपको लगता है कि कुछ बदलावों से परफ़ॉर्मेंस बेहतर हो सकती है, तो उनके लिए A/B टेस्टिंग का इस्तेमाल करें. अगर परफ़ॉर्मेंस बेहतर नहीं होती है, तो उन्हें अस्वीकार कर दें. Macrobenchmark लाइब्रेरी का इस्तेमाल करके, अलग-अलग स्थितियों में परफ़ॉर्मेंस को मेज़र किया जा सकता है.
ज़्यादा जानने के लिए, यहां दिए गए संसाधन देखें:
- परफ़ॉर्मेंस: Systrace के साथ सैंपलिंग प्रोफ़ाइलिंग का इस्तेमाल करना - MAD Skills
- परफ़ॉर्मेंस: MAD Skills में, प्रोफ़ाइलर ट्रेस कैप्चर करना