ऐप्लिकेशन की परफ़ॉर्मेंस को मेज़र करने के बारे में खास जानकारी

इस दस्तावेज़ की मदद से, अपने ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी मुख्य समस्याओं का पता लगाया जा सकता है और उन्हें ठीक किया जा सकता है.

परफ़ॉर्मेंस से जुड़ी मुख्य समस्याएं

किसी ऐप्लिकेशन की परफ़ॉर्मेंस खराब होने की कई वजहें हो सकती हैं. हालांकि, यहां कुछ सामान्य समस्याएं बताई गई हैं:

स्टार्टअप में लगने वाला समय

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

अपने ऐप्लिकेशन में स्टार्टअप के इन लक्ष्यों को हासिल करने की कोशिश करें:

• कोल्ड स्टार्ट में 500 मि॰से॰ से कम समय लगता है. कोल्ड स्टार्ट तब होता है, जब लॉन्च किया जा रहा ऐप्लिकेशन सिस्टम की मेमोरी में मौजूद नहीं होता है. ऐसा तब होता है, जब रीबूट करने के बाद या उपयोगकर्ता या सिस्टम की ओर से ऐप्लिकेशन की प्रोसेस बंद करने के बाद, ऐप्लिकेशन को पहली बार लॉन्च किया जाता है. कोल्ड स्टार्ट के लिए, सिस्टम को सबसे ज़्यादा काम करना पड़ता है. ऐसा इसलिए, क्योंकि उसे स्टोरेज से सब कुछ लोड करना होता है और ऐप्लिकेशन को शुरू करना होता है. कोल्ड स्टार्ट में 500 मि॰से॰ या इससे कम समय लगना चाहिए.
• वॉर्म स्टार्ट में 200 मि॰से॰ से कम और हॉट स्टार्ट में 150 मि॰से॰ से कम समय लगता है. वार्म स्टार्ट तब होता है, जब ऐप्लिकेशन की प्रोसेस पहले से ही बैकग्राउंड में चल रही हो. हालांकि, सिस्टम को यूज़र इंटरफ़ेस (यूआई) को फिर से शुरू करना होता है या ऐक्टिविटी को फ़ोरग्राउंड में वापस लाना होता है. जैसे, जब कोई उपयोगकर्ता ऐप्लिकेशन से बाहर निकल जाता है और कुछ समय बाद उसे फिर से खोलता है. हॉट स्टार्ट, कोल्ड स्टार्ट से भी ज़्यादा तेज़ होता है. ऐसा इसलिए, क्योंकि ऐप्लिकेशन की गतिविधि पहले से ही मेमोरी में कैश मेमोरी में सेव होती है. इसलिए, इसे सिर्फ़ फ़ोरग्राउंड में लाने की ज़रूरत होती है. इसके लिए, व्यू हैरारकी को फिर से बनाने की ज़रूरत नहीं होती. वार्म स्टार्ट को 200 मि॰से॰ से कम और हॉट स्टार्ट को 150 मि॰से॰ से कम रखने का लक्ष्य रखें.
• P95 और P99 की लेटेंसी, मीडियन लेटेंसी के बहुत करीब है. P95 और P99, स्टार्टअप के समय के 95वें और 99वें पर्सेंटाइल को दिखाते हैं. वहीं, मीडियन 50वां पर्सेंटाइल होता है. ऐप्लिकेशन को शुरू होने में ज़्यादा समय लगने से, उपयोगकर्ता को खराब अनुभव मिलता है. ऐप्लिकेशन के स्टार्टअप के दौरान, इंटरप्रोसेस कम्यूनिकेशन (आईपीसी) और ज़रूरी नहीं होने वाले I/O की वजह से, लॉक कंटेंशन की समस्या हो सकती है. साथ ही, इससे गड़बड़ियां हो सकती हैं.

स्क्रोल जैंक

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

अपने ऐप्लिकेशन में, रीफ़्रेश रेट को 90 हर्ट्ज़ पर सेट करें. आम तौर पर, रेंडरिंग रेट 60 हर्ट्ज़ होता है. हालांकि, कई नए डिवाइसों में उपयोगकर्ता के इंटरैक्शन के दौरान, 90 हर्ट्ज़ मोड में काम किया जाता है. जैसे, स्क्रोल करना. कुछ डिवाइसों पर, 120 हर्ट्ज़ तक की ज़्यादा दरें भी काम करती हैं.

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

ट्रांज़िशन सही से काम नहीं कर रहे हैं

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

बिजली की खपत में होने वाली गड़बड़ियां

स्मार्टवॉच का इस्तेमाल करने से, बैटरी का चार्ज कम होता है. साथ ही, बैटरी लाइफ़ भी कम हो जाती है.

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

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

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

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

परफ़ॉर्मेंस से जुड़ी समस्याओं को ठीक करने के लिए, उपयोगकर्ता के इन अहम सफ़र की पहचान करें और इनकी जांच करें:

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

इनमें से हर फ़्लो के लिए, यहां दिए गए डीबग करने वाले टूल का इस्तेमाल करके देखें कि क्या हो रहा है:

• Perfetto: इसकी मदद से, पूरे डिवाइस पर होने वाली गतिविधियों को देखा जा सकता है. साथ ही, सटीक टाइमिंग डेटा भी देखा जा सकता है.
• मेमोरी प्रोफ़ाइलर: इससे आपको यह पता चलता है कि हीप पर मेमोरी कैसे असाइन की जा रही है.
• Simpleperf: इससे यह पता चलता है कि किसी समयावधि के दौरान, कौनसे फ़ंक्शन कॉल सबसे ज़्यादा सीपीयू का इस्तेमाल कर रहे हैं. यह जानकारी फ़्लेमग्राफ़ के तौर पर दिखती है. अगर आपको Systrace में कोई ऐसी चीज़ दिखती है जिसमें ज़्यादा समय लग रहा है, लेकिन आपको इसकी वजह नहीं पता, तो Simpleperf से ज़्यादा जानकारी मिल सकती है.

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

• स्टार्टअप फ़्लो
  • फ़ील्ड मेट्रिक: Play Console के चालू होने में लगने वाला समय
  • लैब टेस्ट: Macrobenchmark की मदद से स्टार्टअप की जांच करना
• Jank
  • फ़ील्ड मेट्रिक
    • Play Console में फ़्रेम से जुड़ी ज़रूरी जानकारी: Play Console में, मेट्रिक को किसी खास उपयोगकर्ता के सफ़र के हिसाब से नहीं देखा जा सकता. यह सिर्फ़ पूरे ऐप्लिकेशन में होने वाले जंक की रिपोर्ट करता है.
    • FrameMetricsAggregator की मदद से कस्टम मेज़रमेंट: किसी खास वर्कफ़्लो के दौरान जैंक मेट्रिक रिकॉर्ड करने के लिए, FrameMetricsAggregator का इस्तेमाल किया जा सकता है.
  • लैब टेस्ट
    • Macrobenchmark की मदद से स्क्रोल करना.
    • मैक्रोबेंचमार्क, फ़्रेम टाइमिंग का डेटा इकट्ठा करता है. इसके लिए, वह dumpsys gfxinfo कमांड का इस्तेमाल करता है. ये कमांड, उपयोगकर्ता के एक सेशन को ब्रैकेट करती हैं. इससे किसी खास उपयोगकर्ता अनुभव के दौरान, जंक में होने वाले बदलाव को समझा जा सकता है. RenderTime मेट्रिक, यह हाइलाइट करती हैं कि फ़्रेम को रेंडर होने में कितना समय लग रहा है. रिग्रेशन या सुधारों की पहचान करने के लिए, ये मेट्रिक, जंक फ़्रेम की संख्या से ज़्यादा अहम होती हैं.

ऐप्लिकेशन लिंक की पुष्टि करने से जुड़ी समस्याएं

ऐप्लिकेशन लिंक, आपकी वेबसाइट के यूआरएल पर आधारित डीप लिंक होते हैं. इनकी पुष्टि यह देखने के लिए की जाती है कि ये आपकी वेबसाइट से जुड़े हैं या नहीं. ऐप्लिकेशन लिंक की पुष्टि न हो पाने की ये वजहें हो सकती हैं:

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

परफ़ॉर्मेंस का विश्लेषण करने के लिए ऐप्लिकेशन सेट अप करना

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

ट्रेसपॉइंट

ऐप्लिकेशन, अपने कोड को कस्टम ट्रेस इवेंट के साथ इंस्ट्रूमेंट कर सकते हैं.

ट्रेस कैप्चर किए जा रहे हैं. हालांकि, ट्रेसिंग से हर सेक्शन पर करीब 5μs का छोटा सा ओवरहेड लगता है. इसलिए, इसे हर तरीके के आस-पास न रखें. काम के बड़े हिस्सों को ट्रेस करने से, परफ़ॉर्मेंस से जुड़ी समस्याओं के बारे में अहम जानकारी मिल सकती है. हालांकि, इसमें >0.1 मि॰से॰ का समय लगता है.

APK के लिए ज़रूरी बातें

डीबग वैरिएंट, समस्याओं को ठीक करने और स्टैक सैंपल को सिंबल में बदलने में मददगार हो सकते हैं. हालांकि, इनसे परफ़ॉर्मेंस पर बुरा असर पड़ता है. Android 10 (एपीआई लेवल 29) और इसके बाद के वर्शन वाले डिवाइसों पर, रिलीज़ बिल्ड में प्रोफ़ाइलिंग की सुविधा चालू करने के लिए, मेनिफ़ेस्ट में profileable android:shell="true" का इस्तेमाल किया जा सकता है.

अपने प्रोडक्शन-ग्रेड कोड छोटा करने कॉन्फ़िगरेशन का इस्तेमाल करें. आपके ऐप्लिकेशन के इस्तेमाल किए गए संसाधनों के आधार पर, इससे परफ़ॉर्मेंस पर काफ़ी असर पड़ सकता है. कुछ ProGuard कॉन्फ़िगरेशन, ट्रेसपॉइंट हटा देते हैं. इसलिए, जिस कॉन्फ़िगरेशन पर आपको टेस्ट चलाने हैं उसके लिए, उन नियमों को हटा दें.

कंपाइलेशन

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

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

यहां दिया गया निर्देश, speed मोड का इस्तेमाल करके ऐप्लिकेशन को कंपाइल करता है:

adb shell cmd package compile -m speed -f com.example.packagename

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

/data/misc/profiles/ref/[package-name]/primary.prof

सिस्टम से जुड़ी ज़रूरी बातें

कम लेवल और ज़्यादा सटीक मेज़रमेंट के लिए, अपने डिवाइसों को कैलिब्रेट करें. एक ही डिवाइस और एक ही ओएस वर्शन पर A/B टेस्ट करें. एक ही तरह के डिवाइस पर भी परफ़ॉर्मेंस में काफ़ी अंतर हो सकता है.

रूट किए गए डिवाइसों पर, माइक्रोबेंचमार्क के लिए lockClocks स्क्रिप्ट का इस्तेमाल करें. ये स्क्रिप्ट, अन्य कामों के साथ-साथ ये काम भी करती हैं:

• सीपीयू को तय फ़्रीक्वेंसी पर रखें.
• छोटे कोर बंद करें और जीपीयू को कॉन्फ़िगर करें.
• थर्मल थ्रॉटलिंग की सुविधा बंद करें.

हमारा सुझाव है कि उपयोगकर्ता अनुभव पर फ़ोकस करने वाले टेस्ट के लिए, lockClocks स्क्रिप्ट का इस्तेमाल न करें. जैसे, ऐप्लिकेशन लॉन्च, DoU टेस्टिंग, और जंक टेस्टिंग. हालांकि, माइक्रोबेंचमार्क टेस्ट में नॉइज़ कम करने के लिए, यह ज़रूरी हो सकती है.

जब भी हो सके, Macrobenchmark जैसे टेस्टिंग फ़्रेमवर्क का इस्तेमाल करें. इससे मेज़रमेंट में होने वाली गड़बड़ियों को कम किया जा सकता है. साथ ही, मेज़रमेंट के सटीक न होने की समस्या को भी रोका जा सकता है.

ऐप्लिकेशन शुरू होने की रफ़्तार कम है: गैर-ज़रूरी ट्रैम्पोलिन गतिविधि

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

पहली इमेज. ट्रैम्पोलिन पर कूदने की गतिविधि दिखाने वाला ट्रेस.

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

ज़रूरत से ज़्यादा मेमोरी का इस्तेमाल करने की वजह से, बार-बार कचरा इकट्ठा होना

आपको Systrace में, उम्मीद से ज़्यादा बार गार्बेज कलेक्शन (GC) दिख सकते हैं.

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

दूसरी इमेज. जीसी इवेंट के बीच का समय दिखाने वाला ट्रेस.

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

जैंकी फ़्रेम

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

जब ऐप्लिकेशन को कम काम करना पड़ता है और फ़्रेम बनाए जाते हैं, तब 60 FPS वाले डिवाइस पर Choreographer.doFrame() ट्रेसपॉइंट, 16.7 मि॰से॰ के कैडेंस पर होते हैं:

तीसरी इमेज. इस ट्रेस में, फ़ास्ट फ़्रेम को बार-बार दिखाया गया है.

ज़ूम आउट करने और ट्रेस में नेविगेट करने पर, कभी-कभी आपको फ़्रेम को पूरा होने में थोड़ा ज़्यादा समय लगता है. हालांकि, यह समय तय किए गए 16.7 मि॰से॰ से ज़्यादा नहीं होता. ये फ़्रेम ठीक हैं:

चौथी इमेज. इस ट्रेस में, फ़ास्ट फ़्रेम को बार-बार दिखाया गया है. साथ ही, इसमें समय-समय पर काम के बस्ट भी दिखाए गए हैं.

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

पांचवी इमेज. इस ट्रेस में, एक जंकी फ़्रेम दिखाया गया है.

छठी इमेज. ज़्यादा जंक फ़्रेम दिखाने वाला ट्रेस.

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

Compose की परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के बारे में ज़्यादा जानने के लिए, Jetpack Compose Performance देखें. जंकी फ़्रेम की पहचान करने और उनकी वजहों को डीबग करने के बारे में ज़्यादा जानने के लिए, धीमी रेंडरिंग लेख पढ़ें.

लेज़ी लेआउट से जुड़ी आम गलतियां

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

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

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

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

अपने ऐप्लिकेशन को डीबग करना

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

Systrace की मदद से, ऐप्लिकेशन के स्टार्टअप को डीबग करना

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

स्टार्टअप के टाइप के बारे में ज़्यादा जानकारी इन चरणों में दी जा सकती है:

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

हमारा सुझाव है कि डिवाइस पर मौजूद System Tracing ऐप्लिकेशन की मदद से, Systrace कैप्चर करें. Android 10 और इसके बाद के वर्शन के लिए, Perfetto का इस्तेमाल करें. Android 9 और इससे पहले के वर्शन के लिए, Systrace का इस्तेमाल करें. हमारा यह भी सुझाव है कि ट्रेस फ़ाइलों को वेब पर आधारित Perfetto ट्रेस व्यूअर की मदद से देखें. ज़्यादा जानकारी के लिए, सिस्टम ट्रेसिंग की खास जानकारी देखें.

इन बातों का ध्यान रखें:

• मॉनिटर कंटेंशन: मॉनिटर से सुरक्षित किए गए संसाधनों के लिए प्रतिस्पर्धा की वजह से, ऐप्लिकेशन के शुरू होने में काफ़ी समय लग सकता है.

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

• कॉन्करेंट जीसी: यह आम है और इसका असर कम होता है. हालांकि, अगर आपको अक्सर यह समस्या आ रही है, तो Android Studio के मेमोरी प्रोफ़ाइलर की मदद से इसकी जांच करें.

• I/O: स्टार्टअप के दौरान किए गए I/O की जांच करें और देखें कि क्या कोई प्रोसेस लंबे समय तक रुकी हुई है.

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

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

डिवाइस पर सिस्टम ट्रेसिंग की सुविधा का इस्तेमाल करना

किसी डिवाइस पर सिस्टम ट्रेस कैप्चर करने के लिए, सिस्टम-लेवल के ऐप्लिकेशन, System Tracing का इस्तेमाल किया जा सकता है. इस ऐप्लिकेशन की मदद से, डिवाइस को प्लग इन किए बिना या adb से कनेक्ट किए बिना भी, डिवाइस से ट्रेस रिकॉर्ड किए जा सकते हैं.

Android Studio के मेमोरी प्रोफ़ाइलर का इस्तेमाल करना

Android Studio Memory Profiler का इस्तेमाल करके, मेमोरी पर पड़ने वाले दबाव की जांच की जा सकती है. यह दबाव, मेमोरी लीक या इस्तेमाल के गलत पैटर्न की वजह से हो सकता है. इससे ऑब्जेक्ट के लाइव व्यू का पता चलता है.

अपने ऐप्लिकेशन में मेमोरी से जुड़ी समस्याओं को ठीक करने के लिए, Memory Profiler का इस्तेमाल करें. इससे यह पता लगाया जा सकता है कि कचरा इकट्ठा करने की प्रोसेस क्यों और कितनी बार होती है.

ऐप्लिकेशन की मेमोरी को प्रोफ़ाइल करने के लिए, यह तरीका अपनाएं:

1. मेमोरी से जुड़ी समस्याओं का पता लगाना.

   उपयोगकर्ता की जिस गतिविधि पर आपको फ़ोकस करना है उसके मेमोरी प्रोफ़ाइलिंग सेशन को रिकॉर्ड करें. ऑब्जेक्ट की बढ़ती हुई संख्या देखें. जैसा कि सातवीं इमेज में दिखाया गया है. इससे आखिर में जीसी होता है. जैसा कि आठवीं इमेज में दिखाया गया है.

   सातवीं इमेज. ऑब्जेक्ट की संख्या बढ़ाई जा रही है.

   आठवीं इमेज. गारबेज कलेक्शन.

   मेमोरी पर दबाव डालने वाली उपयोगकर्ता गतिविधि की पहचान करने के बाद, मेमोरी पर दबाव डालने की मुख्य वजहों का विश्लेषण करें.

2. मेमोरी प्रेशर की वजह से होने वाली समस्याओं का पता लगाना.

   फ़िगर 9 में दिखाए गए तरीके से, टाइमलाइन में कोई रेंज चुनें, ताकि बंटवारा और शैलो साइज़, दोनों को विज़ुअलाइज़ किया जा सके.

   नौवीं इमेज. Allocations और Shallow Size की वैल्यू.

   इस डेटा को क्रम से लगाने के कई तरीके हैं. यहां कुछ उदाहरण दिए गए हैं. इनसे पता चलता है कि हर व्यू से, समस्याओं का विश्लेषण करने में कैसे मदद मिल सकती है.

   • क्लास के हिसाब से क्रम से लगाएं: यह विकल्प तब काम आता है, जब आपको ऐसी क्लास ढूंढनी हों जो ऐसे ऑब्जेक्ट जनरेट कर रही हैं जिन्हें आम तौर पर कैश मेमोरी में सेव किया जाता है या मेमोरी पूल से फिर से इस्तेमाल किया जाता है.

     उदाहरण के लिए, अगर कोई ऐप्लिकेशन हर सेकंड किसी क्लास के 2,000 ऑब्जेक्ट बना रहा है, तो इससे हर सेकंड Allocations की संख्या में 2,000 की बढ़ोतरी होती है. क्लास के हिसाब से क्रम से लगाने पर, आपको यह दिखेगा. अगर आपको इन ऑब्जेक्ट का दोबारा इस्तेमाल करना है, ताकि गार्बेज जनरेट न हो, तो मेमोरी पूल लागू करें.

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

   • शैलो साइज़: यह सिर्फ़ ऑब्जेक्ट की मेमोरी को ट्रैक करता है. यह उन सामान्य क्लास को ट्रैक करने के लिए उपयोगी है जिनमें ज़्यादातर प्रिमिटिव वैल्यू शामिल होती हैं.

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

     दसवीं इमेज. पूरी मेमोरी डंप.

     

3. ऑप्टिमाइज़ेशन के असर का आकलन करना.

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

   ऑप्टिमाइज़ेशन के असर का आकलन करने के लिए, प्रोफ़ाइलर टाइमलाइन में, जीसी के बीच का समय मेज़र करें. पॉज़िटिव असर होने पर, जीसी के बीच का समय बढ़ जाता है.

   मेमोरी को बेहतर बनाने से ये फ़ायदे मिलते हैं:

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