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

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

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

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

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

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

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

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

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

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

स्क्रोल करने पर रुक-रुककर चलना

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

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

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

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

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

बिजली की खपत ज़्यादा होना

काम करने से बैटरी चार्ज कम हो जाता है और ज़रूरत से ज़्यादा काम करने से बैटरी लाइफ़ कम हो जाती है.

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

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

समस्याओं की पहचान करना

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

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

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

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

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

  • इंटेंट फ़िल्टर के दायरे: सिर्फ़ उन यूआरएल के लिए इंटेंट फ़िल्टर में 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 से, dex से रनटाइम क्लास लोड होने के असर को कम किया जा सकता है.

यह निर्देश, 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 दिख रहा है. इसमें पहली गतिविधि के लिए कोई फ़्रेम नहीं दिखाया गया है.

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

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

ज़रूरत न होने पर एलोकेशन करने से, बार-बार जीसी ट्रिगर होना

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

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

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

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

फ़्रेम में रुकावट आना

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

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

alt_text तीसरी इमेज. तेज़ी से बार-बार फ़्रेम दिखाने वाला ट्रेस.

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

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

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

alt_text पांचवीं इमेज. ट्रैक, जिसमें फ़्रेम में रुकावट आ रही है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • एक साथ कई जीसी: यह आम है और इसका असर कम होता है. हालांकि, अगर आपको अक्सर ऐसा अनुभव हो रहा है, तो Android Studio के मेमोरी प्रोफ़ाइलर की मदद से इसकी जांच करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. मेमोरी के दबाव वाले हॉट स्पॉट का पता लगाना.

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

    alt_text नौवीं इमेज. बंटवारे और छोटे साइज़ की वैल्यू.

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

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

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

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

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

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

      alt_text 10वीं इमेज. पूरी मेमोरी का डंप.

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

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

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

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

    मेमोरी में हुए सुधारों का असर इन चीज़ों पर पड़ता है:

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