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

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

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

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

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

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

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

  • कोल्ड स्टार्ट में 500 मि॰से॰ से कम समय लगता है. कोल्ड स्टार्ट तब होता है, जब लॉन्च किया जा रहा ऐप्लिकेशन, सिस्टम की मेमोरी में मौजूद नहीं होता है. ऐसा तब होता है, जब रीबूट करने के बाद या ऐप्लिकेशन की प्रोसेस को उपयोगकर्ता या सिस्टम ने बंद कर दिया हो और उसके बाद ऐप्लिकेशन को पहली बार लॉन्च किया गया हो.

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

  • P95 और P99 की लेटेंसी, मीडियन लेटेंसी के बहुत करीब है. ऐप्लिकेशन को शुरू होने में ज़्यादा समय लगने पर, उपयोगकर्ता को खराब अनुभव मिलता है. ऐप्लिकेशन के स्टार्टअप के क्रिटिकल पाथ के दौरान, इंटरप्रोसेस कम्यूनिकेशन (आईपीसी) और गैर-ज़रूरी I/O की वजह से लॉक कंटेंशन हो सकता है. साथ ही, इससे गड़बड़ियां हो सकती हैं.

स्क्रोल जंक

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

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

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

ट्रांज़िशन का सही तरीके से न होना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ट्रेसपॉइंट

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

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

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

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

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

कंपाइलेशन

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

speed और speed-profile, दोनों ही dex से इंटरप्रेट किए जा रहे कोड की मात्रा को कम करते हैं. इससे बैकग्राउंड में होने वाले जस्ट-इन-टाइम (JIT) कंपाइलेशन की मात्रा भी कम हो जाती है. इससे परफ़ॉर्मेंस पर काफ़ी असर पड़ सकता है. सिर्फ़ 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 आता है. पहले activityStart से कोई फ़्रेम नहीं बनाया जाता.

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

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

ज़रूरत न होने पर भी मेमोरी का इस्तेमाल करना, जिससे बार-बार कचरा इकट्ठा होता है

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

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

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

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

चैंकी फ़्रेम

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

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

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

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

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

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

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

इन्हें पहचानने की प्रैक्टिस की जा सकती है.

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

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

जंकी फ़्रेम की पहचान करने और उनकी वजहों को डीबग करने के बारे में ज़्यादा जानने के लिए, धीमी रेंडरिंग देखें.

RecyclerView से जुड़ी सामान्य गलतियां

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

ज़्यादा लागत वाले notifyDatasetChanged() कॉल से बचने के तरीके जानने के लिए, डाइनैमिक डेटा दिखाना लेख पढ़ें. इन कॉल की वजह से, कॉन्टेंट पूरी तरह से बदलने के बजाय अपडेट होता है.

अगर हर नेस्ट किए गए RecyclerView को सही तरीके से इस्तेमाल नहीं किया जाता है, तो हर बार इंटरनल RecyclerView को पूरी तरह से फिर से बनाया जा सकता है. हर नेस्ट किए गए, इनर RecyclerView में RecycledViewPool सेट होना चाहिए, ताकि यह पक्का किया जा सके कि हर इनर RecyclerView के बीच व्यू रीसाइकल किए जा सकते हैं.

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

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

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

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

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

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

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

हमारा सुझाव है कि डिवाइस पर मौजूद 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 का इस्तेमाल करके, मेमोरी पर पड़ने वाले दबाव की जांच की जा सकती है. यह दबाव, मेमोरी लीक या इस्तेमाल के गलत पैटर्न की वजह से हो सकता है. इससे ऑब्जेक्ट के लाइव व्यू का पता चलता है.

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

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

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

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

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

    alt_text आठवीं इमेज. कचरा हटाने की सेवाएं.

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

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

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

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

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

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

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

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

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

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

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

      'रिटेन किया गया साइज़' कॉलम.
      ग्यारहवीं इमेज. रिटेन किया गया साइज़ कॉलम.

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

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

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

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

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