ऐप्लिकेशन स्टार्टअप समय

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

ऐप्लिकेशन के स्टार्टअप की अलग-अलग स्थितियों के बारे में जानकारी

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

हमारा सुझाव है कि आप हमेशा कोल्ड स्टार्ट की धारणा के आधार पर ऑप्टिमाइज़ करें. ऐसा करने से, गर्म और बहुत गर्म इंजन को शुरू करने की परफ़ॉर्मेंस भी बेहतर हो सकती है.

अपने ऐप्लिकेशन को तेज़ी से शुरू होने के लिए ऑप्टिमाइज़ करने के लिए, यह समझना ज़रूरी है कि सिस्टम और ऐप्लिकेशन के लेवल पर क्या हो रहा है. साथ ही, यह भी समझना ज़रूरी है कि ये इन सभी स्थितियों में कैसे इंटरैक्ट करते हैं.

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

कोल्ड स्टार्ट

कोल्ड स्टार्ट का मतलब है कि ऐप्लिकेशन को फिर से शुरू करना. इसका मतलब है कि जब तक यह प्रोसेस शुरू नहीं होती, तब तक सिस्टम की प्रोसेस, ऐप्लिकेशन की प्रोसेस बनाती है. कोल्ड स्टार्ट तब होता है, जब डिवाइस के बूट होने या सिस्टम के ऐप्लिकेशन को बंद करने के बाद, आपका ऐप्लिकेशन पहली बार लॉन्च होता है.

इस तरह से शुरू होने पर, स्टार्टअप के समय को कम करना सबसे बड़ी चुनौती होती है, क्योंकि सिस्टम और ऐप्लिकेशन के पास लॉन्च की दूसरी स्थितियों की तुलना में ज़्यादा काम होता है.

कोल्ड स्टार्ट की शुरुआत में, सिस्टम को ये तीन काम करने होते हैं:

1. ऐप्लिकेशन को लोड और लॉन्च करें.
2. ऐप्लिकेशन लॉन्च होने के तुरंत बाद, एक खाली विंडो दिखाएं.
3. ऐप्लिकेशन की प्रोसेस बनाएं.

सिस्टम के ऐप्लिकेशन प्रोसेस बनाने के बाद, ऐप्लिकेशन प्रोसेस ही अगले चरणों के लिए ज़िम्मेदार होती है:

1. ऐप्लिकेशन ऑब्जेक्ट बनाएं.
2. मुख्य थ्रेड लॉन्च करें.
3. मुख्य गतिविधि बनाएं.
4. व्यू की संख्या बढ़ाना.
5. स्क्रीन का लेआउट तय करें.
6. शुरुआती ड्रॉ करें.

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

पहली इमेज में दिखाया गया है कि सिस्टम और ऐप्लिकेशन, एक-दूसरे के बीच काम को कैसे हैंड ऑफ़ करते हैं.

ऐप्लिकेशन और गतिविधि बनाते समय, परफ़ॉर्मेंस से जुड़ी समस्याएं आ सकती हैं.

ऐप्लिकेशन बनाना

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

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

इसके बाद, सिस्टम और ऐप्लिकेशन-लेवल की प्रोसेस, ऐप्लिकेशन लाइफ़साइकल के चरणों के हिसाब से आगे बढ़ती हैं.

गतिविधि बनाना

ऐप्लिकेशन की प्रोसेस आपकी गतिविधि बनाने के बाद, गतिविधि ये कार्रवाइयां करती है:

1. वैल्यू को शुरू करता है.
2. कंस्ट्रक्टर को कॉल करता है.
3. ऐक्टिविटी की लाइफ़साइकल की मौजूदा स्थिति के हिसाब से, Activity.onCreate() जैसे कॉलबैक मैथड को कॉल करता है.

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

वॉर्म स्टार्ट

वॉर्म स्टार्ट में, कोल्ड स्टार्ट के दौरान होने वाली कार्रवाइयों का एक सबसेट शामिल होता है. साथ ही, यह हॉट स्टार्ट की तुलना में ज़्यादा ओवरहेड दिखाता है. कई संभावित स्थितियां ऐसी होती हैं जिन्हें वॉर्म स्टार्ट माना जा सकता है. जैसे:

• उपयोगकर्ता आपके ऐप्लिकेशन से बाहर निकलता है, लेकिन फिर उसे फिर से लॉन्च करता है. प्रोसेस चलती रहेगी, लेकिन ऐप्लिकेशन को onCreate() को कॉल करके, गतिविधि को फिर से शुरू करना होगा.

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

हॉट स्टार्ट

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

हालांकि, अगर onTrimMemory() जैसे मेमोरी ट्रिमिंग इवेंट के जवाब में कुछ मेमोरी को मिटा दिया जाता है, तो हॉट स्टार्ट इवेंट के जवाब में इन ऑब्जेक्ट को फिर से बनाना होगा.

हॉट स्टार्ट में, स्क्रीन पर वही व्यवहार दिखता है जो कोल्ड स्टार्ट में दिखता है. ऐप्लिकेशन, गतिविधि को रेंडर करने के बाद ही स्क्रीन दिखाता है.

Perfetto में ऐप्लिकेशन के शुरू होने की पहचान करने का तरीका

ऐप्लिकेशन के शुरू होने से जुड़ी समस्याओं को डीबग करने के लिए, यह पता लगाना ज़रूरी है कि ऐप्लिकेशन के शुरू होने के फ़ेज़ में क्या शामिल है. Perfetto में ऐप्लिकेशन के स्टार्टअप फ़ेज़ की पहचान करने के लिए, यह तरीका अपनाएं:

1. Perfetto में, Android ऐप्लिकेशन के स्टार्टअप से मिली मेट्रिक वाली लाइन ढूंढें. अगर आपको यह विकल्प नहीं दिखता है, तो डिवाइस पर मौजूद सिस्टम ट्रैकिंग ऐप्लिकेशन का इस्तेमाल करके, ट्रैक रिकॉर्ड करने की कोशिश करें.

   

2. स्लाइस चुनने के लिए, उससे जुड़े स्लाइस पर क्लिक करें और m दबाएं. स्लाइस के चारों ओर ब्रैकेट दिखते हैं. इनसे यह पता चलता है कि स्लाइस बनाने में कितना समय लगा. अवधि, मौजूदा चुनी गई अवधि टैब में भी दिखती है.

3. पिन आइकॉन पर क्लिक करके, Android ऐप्लिकेशन के स्टार्टअप की लाइन को पिन करें. यह आइकॉन, लाइन पर कर्सर घुमाने पर दिखता है.

4. जिस ऐप्लिकेशन की जानकारी देखनी है उसकी लाइन तक स्क्रोल करें. इसके बाद, लाइन को बड़ा करने के लिए पहली सेल पर क्लिक करें.

5. आम तौर पर, सबसे ऊपर मौजूद मुख्य थ्रेड को ज़ूम इन करने के लिए, w दबाएं. ज़ूम आउट करने, बाईं ओर जाने, और दाईं ओर जाने के लिए, s, a, d दबाएं.

   

6. डेरिव्ड मेट्रिक स्लाइस की मदद से, यह देखना आसान हो जाता है कि ऐप्लिकेशन के स्टार्टअप में क्या शामिल है. इससे, ज़्यादा जानकारी के साथ डीबग करना जारी रखा जा सकता है.

स्टार्टअप की जांच करने और उन्हें बेहतर बनाने के लिए मेट्रिक का इस्तेमाल करना

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

स्टार्टअप मेट्रिक का इस्तेमाल करने के फ़ायदे

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

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

Android की ज़रूरी जानकारी

Android की ज़रूरी जानकारी वाली सुविधा, आपके ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बनाने में मदद कर सकती है. यह सुविधा, ऐप्लिकेशन के स्टार्टअप में लगने वाले समय के ज़्यादा होने पर, आपको Play Console पर सूचना देती है.

'Android की ज़रूरी जानकारी', आपके ऐप्लिकेशन के लिए स्टार्टअप में लगने वाले इन समय को ज़्यादा मानता है:

• कोल्ड स्टार्टअप में पांच सेकंड या उससे ज़्यादा समय लगता है.
• वॉर्म स्टार्टअप में दो सेकंड या उससे ज़्यादा समय लगता है.
• हॉट स्टार्टअप में 1.5 सेकंड या उससे ज़्यादा समय लगता है.

Android की ज़रूरी जानकारी, शुरुआती डिसप्ले में लगने वाले समय (टीटीआईडी) मेट्रिक का इस्तेमाल करती है. Google Play, 'Android की ज़रूरी जानकारी' का डेटा कैसे इकट्ठा करता है, इस बारे में जानने के लिए Play Console का दस्तावेज़ देखें.

शुरुआती डिसप्ले में लगने वाला समय

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

टीटीआईडी को समय की वैल्यू के तौर पर मेज़र किया जाता है. यह वैल्यू, बीत चुके कुल समय को दिखाती है. इसमें इवेंट का यह क्रम शामिल होता है:

• प्रोसेस शुरू हो रही है.
• ऑब्जेक्ट को शुरू किया जा रहा है.
• गतिविधि बनाना और शुरू करना.
• लेआउट को बड़ा करना.
• पहली बार ऐप्लिकेशन को ड्रॉ करना.

टीटीआईडी पाना

TTID ढूंढने के लिए, Logcat कमांड-लाइन टूल में, Displayed नाम की वैल्यू वाली आउटपुट लाइन खोजें. यह वैल्यू, TTID होती है और यह नीचे दिए गए उदाहरण जैसी दिखती है. इसमें TTID, 3s534ms है:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms

Android Studio में TTID ढूंढने के लिए, फ़िल्टर ड्रॉप-डाउन से अपने Logcat व्यू में फ़िल्टर बंद करें. इसके बाद, Displayed समय ढूंढें, जैसा कि 5वें चित्र में दिखाया गया है. फ़िल्टर बंद करना ज़रूरी है, क्योंकि यह लॉग ऐप्लिकेशन के बजाय सिस्टम सर्वर से मिलता है.

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

कभी-कभी, Logcat के आउटपुट में Displayed लाइन में कुल समय के लिए एक अतिरिक्त फ़ील्ड होता है. उदाहरण के लिए:

ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)

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

हमारा सुझाव है कि आप Android Studio में Logcat का इस्तेमाल करें. हालांकि, अगर Android Studio का इस्तेमाल नहीं किया जा रहा है, तो adb shell ऐक्टिविटी मैनेजर कमांड का इस्तेमाल करके, अपने ऐप्लिकेशन को चलाकर भी TTID को मेज़र किया जा सकता है. यहां एक उदाहरण दिया गया है:

adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN

Displayed मेट्रिक, Logcat आउटपुट में पहले की तरह ही दिखती है. आपकी टर्मिनल विंडो में ये चीज़ें दिखती हैं:

Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete

-c और -a आर्ग्युमेंट ज़रूरी नहीं हैं. इनकी मदद से, <category> और <action> तय किए जा सकते हैं.

फ़ुल स्क्रीन में दिखने में लगने वाला समय

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

सिस्टम, गतिविधि के onDraw() तरीके को कॉल करने पर, Choreographer के लिए टीटीआईडी तय करता है. साथ ही, यह भी तय करता है कि इसे पहली बार कॉल किया जा रहा है या नहीं. हालांकि, सिस्टम को यह पता नहीं होता कि TTFD का पता कब लगाना है, क्योंकि हर ऐप्लिकेशन अलग-अलग तरीके से काम करता है. TTFD का पता लगाने के लिए, ऐप्लिकेशन को सिस्टम को सिग्नल देना होगा कि वह पूरी तरह से ड्रॉ हो गया है.

TTFD फ़ाइल फिर से पाना

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

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

reportFullyDrawn() का इस्तेमाल करने पर, Logcat इस तरह का आउटपुट दिखाता है, जैसा कि इस उदाहरण में दिखाया गया है. इसमें TTFD 1 सेकंड 54 मिलीसेकंड है:

system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms

Logcat आउटपुट में कभी-कभी total समय शामिल होता है, जैसा कि शुरुआती डिसप्ले में लगने वाला समय में बताया गया है.

अगर डिसप्ले चालू होने में ज़रूरत से ज़्यादा समय लग रहा है, तो डिसप्ले चालू होने की प्रोसेस में आ रही रुकावटों की पहचान की जा सकती है.

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

डिवाइस के चालू होने में लगने वाले समय की सटीक जानकारी

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

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

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

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

यहां दिए गए उदाहरण में बताया गया है कि एक साथ कई बैकग्राउंड टास्क कैसे चलाए जा सकते हैं. साथ ही, हर टास्क के लिए अपना रिपोर्टर कैसे रजिस्टर किया जा सकता है:

class MainActivity : ComponentActivity() {

    sealed interface ActivityState {
        data object LOADING : ActivityState
        data object LOADED : ActivityState
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            var activityState by remember {
                mutableStateOf(ActivityState.LOADING as ActivityState)
            }
            fullyDrawnReporter.addOnReportDrawnListener {
                activityState = ActivityState.LOADED
            }
            ReportFullyDrawnTheme {
                when(activityState) {
                    is ActivityState.LOADING -> {
                        // Display the loading UI.
                    }
                    is ActivityState.LOADED -> {
                        // Display the full UI.
                    }
                }
            }
            SideEffect {
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
                fullyDrawnReporter.addReporter()
                lifecycleScope.launch(Dispatchers.IO) {
                    // Perform the background operation.
                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

public class MainActivity extends ComponentActivity {
    private FullyDrawnReporter fullyDrawnReporter;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        fullyDrawnReporter = getFullyDrawnReporter();
        fullyDrawnReporter.addOnReportDrawnListener(() -> {
            // Trigger the UI update.
            return Unit.INSTANCE;
        });

        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();
                // Do the background work.
                fullyDrawnReporter.removeReporter();
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                fullyDrawnReporter.addReporter();
                // Do the background work.
                fullyDrawnReporter.removeReporter();
            }
        }).start();
    }
}

अगर आपका ऐप्लिकेशन Jetpack Compose का इस्तेमाल करता है, तो पूरी तरह से ड्रॉ होने की स्थिति दिखाने के लिए, इन एपीआई का इस्तेमाल किया जा सकता है:

• ReportDrawn: इससे पता चलता है कि आपका कॉम्पोज़ेबल, इंटरैक्शन के लिए तुरंत तैयार है.
• ReportDrawnWhen: यह फ़ंक्शन list.count > 0 जैसे प्रीडिकेट को इस्तेमाल करता है. इससे यह पता चलता है कि आपका कॉम्पोज़ेबल, इंटरैक्शन के लिए कब तैयार है.
• ReportDrawnAfter: यह एक ऐसा तरीका है जिसे पूरा करने के बाद, आपका कॉम्पोज़ेबल इंटरैक्शन के लिए तैयार हो जाता है.

रुकावटों की पहचान करना

रुकावटों का पता लगाने के लिए, Android Studio के सीपीयू प्रोफ़ाइलर का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, सीपीयू प्रोफ़ाइलर की मदद से सीपीयू गतिविधि की जांच करना लेख पढ़ें.

अपने ऐप्लिकेशन और गतिविधियों के onCreate() तरीकों में इनलाइन ट्रैकिंग की मदद से, संभावित रुकावटों के बारे में अहम जानकारी भी पाई जा सकती है. इनलाइन ट्रैकिंग के बारे में जानने के लिए, Trace फ़ंक्शन के दस्तावेज़ और सिस्टम ट्रैकिंग की खास जानकारी देखें.

सामान्य समस्याएं हल करना

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

ऐप्लिकेशन को शुरू करने में ज़्यादा समय लगना

जब आपका कोड Application ऑब्जेक्ट को बदल देता है और उस ऑब्जेक्ट को शुरू करते समय भारी काम या जटिल लॉजिक को लागू करता है, तो लॉन्च की परफ़ॉर्मेंस पर असर पड़ सकता है. अगर आपके Application सबक्लास ऐसे शुरू होने की प्रोसेस शुरू करते हैं जिनकी अभी ज़रूरत नहीं है, तो ऐप्लिकेशन के शुरू होने में समय लग सकता है.

कुछ इनिशलाइज़ेशन पूरी तरह से ज़रूरी नहीं हो सकते. जैसे, जब किसी इंटेंट के जवाब में ऐप्लिकेशन शुरू किया जाता है, तो मुख्य गतिविधि के लिए स्टेटस की जानकारी को इनिशलाइज़ करना. किसी इंटेंट के साथ, ऐप्लिकेशन पहले से शुरू किए गए स्टेटस डेटा के सिर्फ़ सबसेट का इस्तेमाल करता है.

ऐप्लिकेशन को शुरू करने के दौरान आने वाली अन्य समस्याओं में, ग़ैर-ज़रूरी डेटा हटाने वाले ऐसे इवेंट शामिल हैं जिनका असर ज़्यादा होता है या जो बहुत ज़्यादा होते हैं. इसके अलावा, डिस्क I/O की प्रोसेस भी शुरू होने के साथ-साथ होती है, जिससे शुरू होने की प्रोसेस रुक जाती है. ग़ैर-ज़रूरी डेटा हटाने की प्रोसेस, खास तौर पर Dalvik रनटाइम के लिए ज़रूरी है. Android रनटाइम (ART) एक साथ ग़ैर-ज़रूरी डेटा हटाने की प्रोसेस करता है, ताकि इस प्रोसेस का असर कम से कम हो.

समस्या का पता लगाना

समस्या का पता लगाने के लिए, मेथड ट्रैकिंग या इनलाइन ट्रैकिंग का इस्तेमाल किया जा सकता है.

मेथड ट्रेसिंग

सीपीयू प्रोफ़ाइलर चलाने से पता चलता है कि callApplicationOnCreate() तरीका आखिर में आपके com.example.customApplication.onCreate तरीके को कॉल करता है. अगर टूल से पता चलता है कि इन तरीकों को लागू होने में काफ़ी समय लग रहा है, तो ज़्यादा जानकारी देखें और जानें कि कौनसा काम किया जा रहा है.

इनलाइन ट्रेसिंग

इनलाइन ट्रैकिंग का इस्तेमाल करके, समस्या की वजहों की जांच करें. इनमें ये शामिल हैं:

• आपके ऐप्लिकेशन का शुरुआती onCreate() फ़ंक्शन.
• आपके ऐप्लिकेशन के शुरू होने पर, ग्लोबल सिंगलटन ऑब्जेक्ट.
• बोटलनेक के दौरान हो सकता है कि डिस्क I/O, डेसिरियलाइज़ेशन या टाइट लूप की कोई समस्या आ रही हो.

समस्या के समाधान

चाहे समस्या, ग़ैर-ज़रूरी शुरू करने की प्रक्रिया से जुड़ी हो या डिस्क I/O से, इसका समाधान 'धीरे-धीरे शुरू करना' है. दूसरे शब्दों में, सिर्फ़ उन ऑब्जेक्ट को शुरू करें जिनकी तुरंत ज़रूरत है. ग्लोबल स्टैटिक ऑब्जेक्ट बनाने के बजाय, सिंगलटन पैटर्न का इस्तेमाल करें. इसमें ऐप्लिकेशन, ऑब्जेक्ट को सिर्फ़ तब शुरू करता है, जब उन्हें पहली बार ज़रूरत होती है.

साथ ही, Hilt जैसे डिपेंडेंसी इंजेक्शन फ़्रेमवर्क का इस्तेमाल करें. यह पहली बार इंजेक्शन होने पर ऑब्जेक्ट और डिपेंडेंसी बनाता है.

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

ज़्यादा गतिविधि शुरू करना

गतिविधि बनाने में अक्सर बहुत ज़्यादा समय लगता है. आम तौर पर, परफ़ॉर्मेंस को बेहतर बनाने के लिए, इस काम को ऑप्टिमाइज़ करने के अवसर होते हैं. ऐसी सामान्य समस्याओं में ये शामिल हैं:

• बड़े या जटिल लेआउट को बड़ा करना.
• डिस्क पर स्क्रीन ड्रॉइंग या नेटवर्क I/O को ब्लॉक करना.
• बिटमैप लोड और डीकोड करना.
• VectorDrawable ऑब्जेक्ट को रेस्टर में बदलना.
• गतिविधि के अन्य सबसिस्टम को शुरू करना.

समस्या का पता लगाना

इस मामले में भी, मेथड ट्रैकिंग और इनलाइन ट्रैकिंग, दोनों काम की हो सकती हैं.

मेथड ट्रेसिंग

सीपीयू प्रोफ़ाइलर का इस्तेमाल करते समय, अपने ऐप्लिकेशन के Application सबक्लास कॉन्स्ट्रक्टर और com.example.customApplication.onCreate() तरीकों पर ध्यान दें.

अगर टूल से पता चलता है कि इन तरीकों को लागू होने में ज़्यादा समय लग रहा है, तो ज़्यादा जानकारी देखें और जानें कि वहां क्या काम चल रहा है.

इनलाइन ट्रेसिंग

इनलाइन ट्रैकिंग का इस्तेमाल करके, समस्या की वजहों की जांच करें. इनमें ये शामिल हैं:

• आपके ऐप्लिकेशन का शुरुआती onCreate() फ़ंक्शन.
• कोई भी ग्लोबल सिंगलटन ऑब्जेक्ट, जिसे यह शुरू करता है.
• बोटलनेक के दौरान हो सकता है कि डिस्क I/O, डेसिरियलाइज़ेशन या टाइट लूप की कोई समस्या आ रही हो.

समस्या के समाधान

इस प्रोसेस में कई समस्याएं आ सकती हैं. हालांकि, आम तौर पर होने वाली दो समस्याएं और उनके समाधान यहां दिए गए हैं:

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

पसंद के मुताबिक स्प्लैश स्क्रीन

अगर आपने Android 11 (एपीआई लेवल 30) या उससे पहले के वर्शन में, कस्टम स्प्लैश स्क्रीन लागू करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल किया है, तो आपको ऐप्लिकेशन के शुरू होने में ज़्यादा समय लग सकता है:

• windowDisablePreview थीम एट्रिब्यूट का इस्तेमाल करके, लॉन्च के दौरान सिस्टम की ओर से दिखाई गई शुरुआती खाली स्क्रीन को बंद करना.
• खास तौर पर बनाए गए Activity का इस्तेमाल करना.

Android 12 से, SplashScreen एपीआई पर माइग्रेट करना ज़रूरी है. इस एपीआई की मदद से, ऐप्लिकेशन शुरू होने में लगने वाला समय कम हो जाता है. साथ ही, अपनी स्प्लैश स्क्रीन में इन तरीकों से बदलाव किए जा सकते हैं:

• स्प्लैश स्क्रीन का रंग बदलने के लिए, कोई थीम सेट करें.
• windowSplashScreenAnimationDuration की मदद से, यह कंट्रोल करें कि स्प्लैश स्क्रीन कितनी देर तक दिखे.
• स्प्लैश स्क्रीन के ऐनिमेशन को पसंद के मुताबिक बनाएं. साथ ही, स्प्लैश स्क्रीन को बंद करने के लिए ऐनिमेशन को बेहतर तरीके से मैनेज करें.

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

ज़्यादा जानकारी के लिए, स्प्लैश स्क्रीन को माइग्रेट करने से जुड़ी गाइड देखें.