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

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

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

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

ऐप्लिकेशन के खुलने में लगने वाला समय

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

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

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

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

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

स्क्रोल जैंक

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

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

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

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

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

पावर से जुड़ी समस्याएं

काम करने से बैटरी कम खर्च होती है और ग़ैर-ज़रूरी काम बैटरी कम होते हैं ज़िंदगी.

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

हालांकि, इसमें मेहनत लगती है, इसलिए ध्यान रखें कि यह नुक़सान पहुँचाने में परफ़ॉर्मेंस की समस्याओं को हल करना.

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

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

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

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

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

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

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

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

मैक्रोबेंचमार्क की मदद से, सीधे तौर पर कंपाइलेशन मोड की जानकारी दी जा सकती है.

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

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

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

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

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

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

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

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

alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है पहली इमेज. ट्रैंपोलिन से जुड़ी गतिविधि दिखाने वाला ट्रेस.

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

गै़र-ज़रूरी बजट की वजह से बार-बार जीसी ट्रिगर हो रहे हैं

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

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

alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है दूसरी इमेज. GC इवेंट के बीच स्पेस दिखा रहा ट्रेस.

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

जैंकी फ़्रेम

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

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

alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है तीसरी इमेज. बार-बार तेज़ी से काम करने वाले फ़्रेम दिखाने वाला ट्रेस.

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

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

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

alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है पांचवी इमेज. टूटा हुआ फ़्रेम दिखाने वाला ट्रेस.

आप उनकी पहचान करने का अभ्यास कर सकते हैं.

alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है छठी इमेज. ज़्यादा अस्त-व्यस्त फ़्रेम दिखा रहा ट्रेस.

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

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

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

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

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

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

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

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

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

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

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

नीचे दिए गए चरणों में, स्टार्टअप टाइप को अलग किया जा सकता है:

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

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

इसके लिए, यहां कुछ ज़रूरी बातें बताई गई हैं:

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

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

  • I/O: स्टार्टअप के दौरान परफ़ॉर्म किए गए I/O का पता लगाएं और लंबे स्टॉल देखें.

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

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

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

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

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

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

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

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

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

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

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

    alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है आठवीं इमेज. कचरा इकट्ठा करना.

    उपयोगकर्ता की ऐसी गतिविधि की पहचान करने के बाद जिससे मेमोरी का दबाव बढ़ रहा है, विश्लेषण करें मेमोरी दबाव की मूल वजहों के लिए किया जा सकता है.

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

    ऐलोकेशन और हल्का साइज़, जैसा कि नौवीं इमेज में दिखाया गया है.

    alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है नौवीं इमेज. आवंटन और शैले के लिए मान साइज़.

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

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

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

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

    • शैल साइज़: सिर्फ़ ऑब्जेक्ट की मेमोरी को ट्रैक करता है. यह काम का है का इस्तेमाल किया जाता है.

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

      alt_टेक्स्ट अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है 10वीं इमेज. पूरी मेमोरी डंप.

      बनाए रखे गए आकार का कॉलम.
      11वीं इमेज. बनाए रखे गए साइज़ का कॉलम.
  3. ऑप्टिमाइज़ेशन के असर को मेज़र करना.

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

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

    मेमोरी में सुधार करने के खास असर के बारे में यहां बताया गया है:

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