ऐप्लिकेशन के शुरू होने का विश्लेषण और ऑप्टिमाइज़ेशन

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

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

सिस्टम ट्रेस से, आपके डिवाइस पर हो रही गतिविधियों के बारे में अहम जानकारी मिलती है. इससे आपको यह समझने में मदद मिलती है कि स्टार्टअप के दौरान आपका ऐप्लिकेशन क्या कर रहा है. साथ ही, इससे आपको ऑप्टिमाइज़ेशन के संभावित क्षेत्रों की पहचान करने में मदद मिलती है.

अपने ऐप्लिकेशन के स्टार्टअप का विश्लेषण करने के लिए, यह तरीका अपनाएं:

• ऐप्लिकेशन स्टार्टअप के लिए ट्रेस रिकॉर्ड करने के लिए, एनवायरमेंट सेट अप करें.
• सिस्टम ट्रेस के बारे में जानें.
• Android Studio Profilers या Perfetto का इस्तेमाल करके, ट्रेस रिपोर्ट पर जाएं.

स्टार्टअप का विश्लेषण और उसे ऑप्टिमाइज़ करने का तरीका

ऐप्लिकेशन को अक्सर स्टार्टअप के दौरान कुछ ऐसे संसाधन लोड करने पड़ते हैं जो उपयोगकर्ताओं के लिए ज़रूरी होते हैं. ज़रूरी नहीं है कि स्टार्टअप पूरा होने से पहले ही गैर-ज़रूरी संसाधनों को लोड किया जाए.

परफ़ॉर्मेंस में बदलाव करने के लिए, इन बातों का ध्यान रखें:

• हर ऑपरेशन में लगने वाले समय का आकलन करने के लिए, Macrobenchmark लाइब्रेरी का इस्तेमाल करें. साथ ही, उन ब्लॉक की पहचान करें जिन्हें पूरा होने में ज़्यादा समय लगता है.

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

• पक्का करें कि आपको ऐप्लिकेशन के स्टार्टअप पर इस ऑपरेशन के चलने की उम्मीद है. अक्सर, लेगसी कोड या तीसरे पक्ष की लाइब्रेरी से गैर-ज़रूरी कार्रवाइयां की जा सकती हैं.

• अगर हो सके, तो लंबे समय तक चलने वाली कार्रवाइयों को बैकग्राउंड में ले जाएं. स्टार्टअप के दौरान, बैकग्राउंड प्रोसेस की वजह से सीपीयू का इस्तेमाल अब भी बढ़ सकता है.

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

जब तक आपको अपने ऐप्लिकेशन के स्टार्टअप टाइम से संतुष्टि न मिल जाए, तब तक उसे ऑप्टिमाइज़ करें और फिर से मेज़र करें. ज़्यादा जानकारी के लिए, समस्याओं का पता लगाने और उनका निदान करने के लिए मेट्रिक का इस्तेमाल करना लेख पढ़ें.

मुख्य कार्रवाइयों में लगने वाले समय का आकलन और विश्लेषण करना

जब आपके पास ऐप्लिकेशन के शुरू होने का पूरा ट्रेस हो, तो ट्रेस देखें और bindApplication या activityStart जैसी मुख्य कार्रवाइयों में लगने वाले समय को मेज़र करें. हमारा सुझाव है कि इन ट्रेस का विश्लेषण करने के लिए, Perfetto या Android Studio Profilers का इस्तेमाल करें.

ऐप्लिकेशन शुरू होने में लगे कुल समय को देखें. इससे आपको ऐसी कार्रवाइयों का पता चलेगा जो ये काम करती हैं:

• ये ज़्यादा समय तक दिखते हैं और इन्हें ऑप्टिमाइज़ किया जा सकता है. परफ़ॉर्मेंस के लिए, हर मिलीसेकंड मायने रखता है. उदाहरण के लिए, Choreographer ड्रॉ करने में लगने वाला समय, शुरुआती कंपोज़िशन में लगने वाला समय, लाइब्रेरी लोड होने में लगने वाला समय, Binder लेन-देन या संसाधन लोड होने में लगने वाला समय देखें. शुरुआत में, उन सभी कार्रवाइयों को देखें जिनमें 20 मि॰से॰ से ज़्यादा समय लगता है.
• मुख्य थ्रेड को ब्लॉक करना. ज़्यादा जानकारी के लिए, Systrace रिपोर्ट पर नेविगेट करना लेख पढ़ें.
• स्टार्टअप के दौरान चलाने की ज़रूरत नहीं होती.
• पहले फ़्रेम के रेंडर होने के बाद तक इंतज़ार किया जा सकता है.

परफ़ॉर्मेंस में कमियों का पता लगाने के लिए, इन सभी ट्रेस की ज़्यादा जांच करें.

मुख्य थ्रेड पर ज़्यादा समय लेने वाली कार्रवाइयों की पहचान करना

फ़ाइल I/O और नेटवर्क ऐक्सेस जैसी भारी कार्रवाइयों को मुख्य थ्रेड से अलग रखना सबसे सही तरीका है. ऐप्लिकेशन के स्टार्टअप के दौरान भी यह उतना ही ज़रूरी है, क्योंकि मुख्य थ्रेड पर ज़्यादा समय लेने वाली प्रोसेस की वजह से, ऐप्लिकेशन अनरिस्पॉन्सिव हो सकता है. साथ ही, अन्य ज़रूरी प्रोसेस में देरी हो सकती है. StrictMode.ThreadPolicy से उन मामलों की पहचान करने में मदद मिल सकती है जहां मुख्य थ्रेड पर महंगी कार्रवाइयां हो रही हैं. समस्याओं का पता जल्द से जल्द लगाने के लिए, डीबग बिल्ड पर StrictMode को चालू करना एक अच्छा तरीका है. इसे यहां दिए गए उदाहरण में दिखाया गया है:

class MyApplication : Application() {

    override fun onCreate() {
        super.onCreate()

        ...
        if (BuildConfig.DEBUG)
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectAll()
                    .penaltyDeath()
                    .build()
            )
        ...
    }
}

StrictMode.ThreadPolicy का इस्तेमाल करने से, सभी डीबग बिल्ड पर थ्रेड नीति लागू हो जाती है. साथ ही, थ्रेड नीति के उल्लंघन का पता चलने पर ऐप्लिकेशन क्रैश हो जाता है. इससे थ्रेड नीति के उल्लंघनों को अनदेखा करना मुश्किल हो जाता है.

टीटीआईडी और टीटीएफ़डी

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

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

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

थ्रेड की पूरी स्थिति का विश्लेषण करना

ऐप्लिकेशन के शुरू होने में लगने वाला समय चुनें और थ्रेड के सभी स्लाइस देखें. मुख्य थ्रेड को हर समय जवाब देना चाहिए.

Android Studio Profiler और Perfetto जैसे टूल, मुख्य थ्रेड और हर चरण में लगने वाले समय के बारे में पूरी जानकारी देते हैं. Perfetto ट्रेस को विज़ुअलाइज़ करने के बारे में ज़्यादा जानकारी के लिए, Perfetto यूज़र इंटरफ़ेस (यूआई) का दस्तावेज़ देखें.

मुख्य थ्रेड के स्लीपिंग स्टेट के बड़े हिस्सों की पहचान करना

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

मुख्य थ्रेड को ब्लॉक करने और नींद में खलल पड़ने की समस्या को कम करना

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

I/O से जुड़ी प्रोसेस के दौरान नींद में रुकावट आने की वजह से, बैटरी की खपत कम करने का अच्छा मौका मिल सकता है. I/O करने वाली अन्य प्रोसेस, भले ही वे किसी दूसरे ऐप्लिकेशन से जुड़ी हों, टॉप ऐप्लिकेशन के I/O से मुकाबला कर सकती हैं.

स्टार्टअप में लगने वाले समय को बेहतर बनाना

ऑप्टिमाइज़ेशन का कोई अवसर मिलने के बाद, स्टार्टअप के समय को बेहतर बनाने के लिए संभावित समाधानों के बारे में जानें:

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

यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस का विश्लेषण करना

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

शुरू करने के दौरान काम को सीमित करना

कुछ फ़्रेम को लोड होने में दूसरों की तुलना में ज़्यादा समय लग सकता है. इन्हें ऐप्लिकेशन के लिए महंगे ड्रॉ माना जाता है.

शुरुआत को ऑप्टिमाइज़ करने के लिए, यह तरीका अपनाएं:

• कंपोज़िशन और लेआउट के धीमे चरणों को प्राथमिकता दें और उन्हें बेहतर बनाने के लिए चुनें.
• Perfetto से मिली हर चेतावनी और Systrace से मिली हर सूचना की जांच करें. इसके लिए, कस्टम ट्रेस इवेंट जोड़ें, ताकि महंगे ड्रॉ और देरी को कम किया जा सके.

फ़्रेम के डेटा को मेज़र करना

फ़्रेम डेटा को मेज़र करने के कई तरीके हैं. डेटा इकट्ठा करने के पांच मुख्य तरीके यहां दिए गए हैं:

• dumpsys gfxinfo का इस्तेमाल करके लोकल कलेक्शन: dumpsys डेटा में देखे गए सभी फ़्रेम, आपके ऐप्लिकेशन की धीमी रेंडरिंग के लिए ज़िम्मेदार नहीं होते. साथ ही, इनका असर असली उपयोगकर्ताओं पर भी नहीं पड़ता. हालांकि, परफ़ॉर्मेंस के सामान्य रुझान को समझने के लिए, अलग-अलग रिलीज़ साइकल में इस मेज़रमेंट को देखना एक अच्छा तरीका है. यूज़र इंटरफ़ेस (यूआई) की परफ़ॉर्मेंस मेज़रमेंट को टेस्टिंग के तरीकों में इंटिग्रेट करने के लिए, gfxinfo और framestats का इस्तेमाल करने के बारे में ज़्यादा जानने के लिए, Android ऐप्लिकेशन की टेस्टिंग के बुनियादी सिद्धांत देखें.
• JankStats का इस्तेमाल करके फ़ील्ड कलेक्शन: JankStats लाइब्रेरी का इस्तेमाल करके, अपने ऐप्लिकेशन के कुछ हिस्सों से फ़्रेम रेंडर होने में लगने वाला समय इकट्ठा करें. साथ ही, डेटा को रिकॉर्ड और उसका विश्लेषण करें.
• Macrobenchmark (Perfetto) का इस्तेमाल करके की गई जांचों में
• Perfetto FrameTimeline: Android 12 (एपीआई लेवल 31) या इसके बाद के वर्शन पर, Perfetto ट्रेस से फ़्रेम टाइमलाइन मेट्रिक इकट्ठा की जा सकती हैं. इससे यह पता चलता है कि किस वजह से फ़्रेम ड्रॉप हो रहा है. इससे यह पता लगाया जा सकता है कि फ़्रेम क्यों छोड़े जा रहे हैं.
• जंक का पता लगाने के लिए Android Studio Profiler

मुख्य ऐक्टिविटी के कॉन्टेंट लोड होने में लगने वाला समय देखना

आपके ऐप्लिकेशन की मुख्य गतिविधि में ऐसी बहुत सी जानकारी हो सकती है जिसे कई सोर्स से लोड किया जाता है. होम Activity यूज़र इंटरफ़ेस (यूआई) देखें. खास तौर पर, Choreographer#doFrame इवेंट देखें.

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

मुख्य गतिविधि के कॉन्टेंट लोड होने में लगने वाले समय को ऑप्टिमाइज़ करने के लिए, इन संभावित समाधानों को आज़माएं:

• अपनी शुरुआती कंपोज़िशन को जितना हो सके उतना हल्का रखें. ज़्यादा जानकारी के लिए, Jetpack Compose की परफ़ॉर्मेंस देखें.
• ड्रॉप किए गए फ़्रेम और मुश्किल लेआउट के बारे में ज़्यादा जानकारी देने के लिए, कस्टम ट्रेसपॉइंट जोड़ें.
• स्टार्टअप के दौरान लोड किए गए बिटमैप रिसॉर्स की संख्या और साइज़ को कम करें. ज़्यादा जानकारी के लिए, बिटमैप इमेज को ऑप्टिमाइज़ करना लेख पढ़ें.

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

  var shouldLoad by remember {mutableStateOf(false)}
  
  if (shouldLoad) {
   MyComposable()
  }
  

  shouldLoad में बदलाव करके, शर्त वाले ब्लॉक में कंपोज़ेबल लोड करें:

  LaunchedEffect(Unit) {
   shouldLoad = true
  }
  

  इससे, फिर से कंपोज़ करने की प्रोसेस ट्रिगर होती है. इसमें पहले स्निपेट में मौजूद शर्त वाले ब्लॉक का कोड शामिल होता है.

  Compose की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के बारे में ज़्यादा जानने के लिए, सबसे सही तरीके देखें.