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

उपयोगकर्ता उम्मीद करते हैं कि ऐप्लिकेशन तेज़ी से लोड हों और रिस्पॉन्सिव हों. ऐसा ऐप्लिकेशन जो धीरे-धीरे शुरू होता है यह उम्मीद पर खरा नहीं उतरता और लोगों को निराश कर सकता है. इस तरह की खराब अनुभव की वजह से उपयोगकर्ता, 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 में ऐप्लिकेशन स्टार्टअप की पहचान करने का तरीका

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

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

    तीसरी इमेज.Android ऐप्लिकेशन स्टार्टअप से हासिल की गई मेट्रिक की स्लाइस परफ़ेटो.

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

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

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

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

    चौथी इमेज.इसके बाद, Android ऐप्लिकेशन स्टार्टअप से हासिल की गई मेट्रिक का स्लाइस ऐप्लिकेशन की मुख्य थ्रेड पर ले जाते हैं.

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

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

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

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

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

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

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

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

'Android की ज़रूरी जानकारी' में, आपके ऐप्लिकेशन के स्टार्ट होने का समय इन बातों का ध्यान रखा जाता है:

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

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

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

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

TTID को समय की एक वैल्यू के रूप में मापा जाता है, जो बीता हुआ कुल समय दिखाता है इसमें इवेंट के ये क्रम शामिल होते हैं:

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

TTID वापस पाएं

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

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

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

पांचवीं इमेज. बंद किए गए फ़िल्टर और Displayed लॉगकैट में वैल्यू.

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

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

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

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

हमारा सुझाव है कि Android Studio में Logcat का इस्तेमाल करें. हालांकि, Android का इस्तेमाल न करने पर Studio से, आप अपने ऐप्लिकेशन को adb शेल के साथ चलाकर 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) वह समय है जो किसी ऐप्लिकेशन को बनने में लगता है जो उपयोगकर्ता के लिए इंटरैक्टिव हैं. इसे प्रदर्शन में लगने वाले समय के रूप में रिपोर्ट किया जाता है ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) के पहले फ़्रेम और एसिंक्रोनस रूप से लोड होने वाले कॉन्टेंट के साथ दिखाई दे सकता है. आम तौर पर, यह लोड किया गया मुख्य कॉन्टेंट होता है को भी ऐक्सेस किया जा सकता है. दूसरे शब्दों में, TTFD में टीटीआईडी और ऐप्लिकेशन को इस्तेमाल करने में लगने वाला समय. अपने ऐप्लिकेशन के TTFD कम होने पर, उपयोगकर्ता आपके तुरंत मिल जाता है.

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

TTFD वापस पाएं

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

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

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

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

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

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

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

स्टार्टअप समय को सटीक बनाएं

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

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

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

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

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

Kotlin

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 {
                lifecycleScope.launch(Dispatchers.IO) {
                    fullyDrawnReporter.addReporter()

                    // Perform the background operation.

                    fullyDrawnReporter.removeReporter()
                }
                lifecycleScope.launch(Dispatchers.IO) {
                    fullyDrawnReporter.addReporter()

                    // Perform the background operation.

                    fullyDrawnReporter.removeReporter()
                }
            }
        }
    }
}

Java

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 एक साथ हों जो शुरू करना, जो आगे बढ़ने की प्रोसेस को ब्लॉक करता है. कचरा Duet AI के रनटाइम के दौरान, कलेक्शन का इस्तेमाल खास तौर पर किया जाता है; Android रनटाइम (एआरटी) एक ही समय पर कचरा इकट्ठा करने की प्रोसेस करता है. कार्रवाई का असर.

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

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

तरीका ट्रेस करने की सुविधा

सीपीयू प्रोफ़ाइलर चलाने से पता चलता है कि 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 एपीआई पर माइग्रेट करना ज़रूरी है. इस एपीआई की मदद से, ऐप्लिकेशन के चालू होने में कम समय लगता है. साथ ही, इससे स्प्लैश स्क्रीन में बदलाव करने में मदद मिलती है नीचे दिए गए तरीकों से:

इसके अलावा, कॉम्पट लाइब्रेरी, SplashScreen API का बैकपोर्ट करती है, ताकि साथ ही, पुराने सिस्टम के साथ काम करता है और स्प्लैश स्क्रीन पर एक जैसा लुक और स्टाइल बनाए रखता है. स्क्रीन डिसप्ले की सुविधा है.

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

पीछे जाएं
अनुमति न मिलना