'Android की ज़रूरी जानकारी' का इस्तेमाल करके, अपने ऐप्लिकेशन की तकनीकी क्वालिटी पर नज़र रखना

किसी मेट्रिक के बारे में ज़्यादा जानकारी के लिए, मेट्रिक के बगल में मौजूद ब्यौरा देखें () चुनें. अगली स्क्रीन पर, इनकी समीक्षा की जा सकती है:

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

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

ANR रेट से जुड़ी तीन मेट्रिक होती हैं:

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

समस्या को ठीक करना

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

Android Developers साइट, ANRs का पता लगाने और उसे ठीक करने से जुड़ी जानकारी उपलब्ध कराती है.

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

क्रैश रेट से जुड़ी तीन मेट्रिक होती हैं:

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

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

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

समस्या को ठीक करना

Android Developers साइट, क्रैश का पता लगाने और उसे ठीक करने से जुड़ी जानकारी उपलब्ध कराती है.

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

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

डेटा इकट्ठा करने की जानकारी

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

ज़रूरी जानकारी

• ऐसे सेशन जिन पर असर पड़ा: उन सेशन का प्रतिशत, जिनके दौरान उपयोगकर्ताओं को हर सिस्टम स्थिति में ऐप्लिकेशन के धीरे शुरू होने की समस्या का सामना करना पड़ा:
  • स्लो कोल्ड स्टार्ट: पांच सेकंड या उससे ज़्यादा
  • स्लो वॉर्म स्टार्ट: दो सेकंड या उससे ज़्यादा
  • स्लो हॉट स्टार्ट: 1 सेकंड या उससे ज़्यादा
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: ऐसे 10%/1% डेली सेशन जहां आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों को ऐप्लिकेशन शुरू होने में ज़्यादा समय लगने की समस्या का सामना करना पड़ा.

समस्या को ठीक करना

अगर आपके ऐप्लिकेशन को खुलने में आम तौर पर ज़्यादा समय लगता है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए, Android Developers साइट पर जाएं.

यह क्यों ज़रूरी है

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

अपने ऐप्लिकेशन के डेटा के बारे में जानें

'धीमे सेशन' मेट्रिक के पेज पर, आपको उन डेली सेशन के प्रतिशत के बारे में जानकारी मिलेगी जहां उपयोगकर्ताओं को 25% से ज़्यादा फ़्रेम के रेंडर होने में, 30 FPS या 20 FPS (फ़्रेम प्रति सेकंड) से कम के फ़्रेम रेट का अनुभव हुआ है. यह जानकारी, चुने गए मानदंड के हिसाब से दिखती है. अपने गेम के लिए, फ़्रेम रेट के हिसाब से सेशन के डिस्ट्रिब्यूशन की जानकारी भी देखी जा सकती है. (सेशन-लेवल फ़्रेम रेट का हिसाब 75वें पर्सेंटाइल पर लगाया जाता है. इसका मतलब यह है कि सेशन में कुल फ़्रेम में से, कम से कम 75% फ़्रेम ने यह फ़्रेम रेट हासिल किया.)

Google Play पर मौजूद ज़्यादातर गेम का फ़्रेम रेट, 30 FPS (फ़्रेम प्रति सेकंड) या उससे ज़्यादा होना चाहिए. इससे उपयोगकर्ताओं को बेहतरीन अनुभव मिलता है, भले ही वे किसी भी तरह का गेम खेल रहे हों. हालांकि, कुछ उपयोगकर्ता कम से कम 60 FPS (फ़्रेम प्रति सेकंड) की दर पर गेम खेलना पसंद करेंगे, खासकर नए वर्शन वाले डिवाइसों पर. धीमे सेशन की दर (30 FPS) की मेट्रिक पर नज़र रखें, ताकि यह पक्का किया जा सके कि यह दर मिल रही है या नहीं. ध्यान रखें कि इस मेट्रिक में सिर्फ़ वे सेशन शामिल होते हैं जिनमें शामिल 25% से ज़्यादा फ़्रेम को रेंडर होने में 30 FPS (फ़्रेम प्रति सेकंड) का फ़्रेम रेट हासिल नहीं होता. इसलिए, इसमें दिख रहे फ़्रेम रेट में कुछ फ़र्क़ हो सकता है.

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

'Android की ज़रूरी जानकारी' से, हर डिवाइस के 30 FPS के फ़्रेम रेट वाले धीमे सेशन और 20 FPS के फ़्रेम रेट वाले धीमे सेशन की जानकारी मिलती है. यह जानकारी सभी डिवाइसों और सेशन के लिए मिलती है. उपयोगकर्ता के अनुभव को बेहतर तरीके से समझने के लिए सभी मेट्रिक का इस्तेमाल करें. साथ ही, हर डिवाइस के लिए गेम की परफ़ॉर्मेंस पर ध्यान दें. आने वाले समय में, Play अपने उपयोगकर्ताओं को उन गेम से दूर रखना शुरू कर देगा जो उनके फ़ोन पर 20 FPS (फ़्रेम प्रति सेकंड) की दर से रेंडर नहीं हो पाते.

'Android की ज़रूरी जानकारी', गेम के एक मिनट तक चलने के बाद ही फ़्रेम रेट की जानकारी इकट्ठा करती है.

डेटा इकट्ठा करने की जानकारी

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

धीमे सेशन वाले फ़्रेम रेट का डेटा, Android 9 और उसके बाद के वर्शन पर काम करने वाले डिवाइसों से इकट्ठा किया जाता है.

डैशबोर्ड डिसप्ले

• औसत फ़्रेम रेट: Android 9 या उसके बाद के वर्शन पर काम करने वाले डिवाइसों के लिए, आपके गेम के फ़्रेम रेट की परफ़ॉर्मेंस का हिसाब, 75वें पर्सेंटाइल पर किया जाता है. इसका मतलब है कि 75% मौकों पर, 75% सेशन का फ़्रेम रेट इतना या इससे ज़्यादा था.
• समय के हिसाब से धीमे सेशन का रेट: यह टाइम सीरीज़ उन सेशन का प्रतिशत दिखाती है जो धीमे सेशन माने जाते हैं.
• फ़्रेम रेट का डिस्ट्रिब्यूशन: हिस्टोग्राम, हर सेशन के लिए फ़्रेम रेट का 75वां पर्सेंटाइल दिखाता है. इसका मतलब है कि किसी सेशन में 75% फ़्रेम, सेशन को बकेट करने में इस्तेमाल होने वाले फ़्रेम रेट से ज़्यादा तेज़ थे.

समस्या को ठीक करना

अगर आपके ऐप्लिकेशन में धीमे सेशन की संख्या काफ़ी ज़्यादा है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए, Android Developers साइट पर जाएं.

अपने ऐप्लिकेशन के डेटा के बारे में जानें

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

डेटा इकट्ठा करने की जानकारी

जब आपके ऐप्लिकेशन में यूज़र इंटरफ़ेस (यूआई) टूलकिट फ़्रेमवर्क का इस्तेमाल किया जाता है, तो Google हर फ़्रेम के लिए, रेंडर होने में लगने वाले समय की जानकारी इकट्ठा करता है. OpenGL या Vulkan का इस्तेमाल करके रेंडर किए गए फ़्रेम के लिए, रेंडर होने में लगने वाले समय को इकट्ठा नहीं किया जाता.

डैशबोर्ड डिसप्ले

कोई पंक्ति चुनने पर आपको, पर्सेंटाइल में बांटा गया डेटा दिखेगा.

• ऐसे सेशन जिन पर असर पड़ा: उन डेली सेशन का प्रतिशत जहां उपयोगकर्ताओं को 50% से ज़्यादा फ़्रेम रेंडर होने में 16 मि॰से॰ से ज़्यादा समय लगने की समस्या का सामना करना पड़ा. डेली सेशन उस दिन के लिए इस्तेमाल होता है जिस दौरान आपका ऐप्लिकेशन इस्तेमाल किया गया था. जैसे, अगर दो उपयोगकर्ता, ऐप्लिकेशन का दो दिनों तक इस्तेमाल करते हैं, तो उससे चार डेली सेशन बनेंगे.
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: कुल फ़्रेम में से 90%/99% फ़्रेम को रेंडर होने में लगने वाला समय, दिखाई गई संख्या से कम था. ये संख्याएं, इकट्ठे किए गए सभी फ़्रेम पर आधारित होती हैं.

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

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

• छूटे हुए Vsync: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, छूटे हुए Vsync इवेंट की संख्या में, फ़्रेम की संख्या से भाग दिया जाता है.
• हाई इनपुट लेटेंसी: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, 24 मि॰से॰ से ज़्यादा समय लेने वाले इनपुट इवेंट की संख्या में, फ़्रेम की संख्या से भाग दिया जाता है.
• धीमा यूज़र इंटरफ़ेस (यूआई) थ्रेड: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, 8 मि॰से॰ से ज़्यादा समय लेने वाले यूज़र इंटरफ़ेस (यूआई) थ्रेड की संख्या में, फ़्रेम की संख्या से भाग दिया जाता है.
• धीमे ड्रॉ निर्देश: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, जीपीयू को ड्रॉ के निर्देश भेजने में जितनी बार 12 मि॰से॰ से ज़्यादा समय लगा, उस संख्या में फ़्रेम की संख्या से भाग दिया जाता है.
• धीमे बिट मैप अपलोड: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, बिट मैप को जीपीयू पर अपलोड होने में जितनी बार 3.2 मि॰से॰ से ज़्यादा समय लगा, उस संख्या में फ़्रेम की संख्या से भाग दिया जाता है.

समस्या को ठीक करना

अगर आपके ऐप्लिकेशन में ऐसे कई फ़्रेम मौजूद हैं जिन्हें रेंडर होने में 16 मि॰से॰ से ज़्यादा समय लगता है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए Android Developers साइट पर जाएं.

अपने ऐप्लिकेशन के डेटा के बारे में जानें

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

डेटा इकट्ठा करने की जानकारी

जब आपके ऐप्लिकेशन में यूज़र इंटरफ़ेस (यूआई) टूलकिट फ़्रेमवर्क का इस्तेमाल किया जाता है, तो Google हर फ़्रेम के लिए, रेंडर होने में लगने वाले समय की जानकारी इकट्ठा करता है. OpenGL या Vulkan का इस्तेमाल करके रेंडर किए गए फ़्रेम के लिए, रेंडर होने में लगने वाले समय को इकट्ठा नहीं किया जाता.

डैशबोर्ड डिसप्ले

कोई पंक्ति चुनने पर आपको, पर्सेंटाइल में बांटा गया डेटा दिखेगा.

• ऐसे सेशन जिन पर असर पड़ा: उन डेली सेशन का प्रतिशत जहां उपयोगकर्ताओं को 50% से ज़्यादा फ़्रेम रेंडर होने में 16 मि॰से॰ से ज़्यादा समय लगने की समस्या का सामना करना पड़ा. डेली सेशन उस दिन के लिए इस्तेमाल होता है जिस दौरान आपका ऐप्लिकेशन इस्तेमाल किया गया था. जैसे, अगर दो उपयोगकर्ता, ऐप्लिकेशन का दो दिनों तक इस्तेमाल करते हैं, तो उससे चार डेली सेशन बनेंगे.
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: कुल फ़्रेम में से 90%/99% फ़्रेम को रेंडर होने में लगने वाला समय, दिखाई गई संख्या से कम था. ये संख्याएं, इकट्ठे किए गए सभी फ़्रेम पर आधारित होती हैं.

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

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

• छूटे हुए Vsync: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, छूटे हुए Vsync इवेंट की संख्या में, फ़्रेम की संख्या से भाग दिया जाता है.
• हाई इनपुट लेटेंसी: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, 24 मि॰से॰ से ज़्यादा समय लेने वाले इनपुट इवेंट की संख्या में, फ़्रेम की संख्या से भाग दिया जाता है.
• धीमा यूज़र इंटरफ़ेस (यूआई) थ्रेड: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, 8 मि॰से॰ से ज़्यादा समय लेने वाले यूज़र इंटरफ़ेस (यूआई) थ्रेड की संख्या में, फ़्रेम की संख्या से भाग दिया जाता है.
• धीमे ड्रॉ निर्देश: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, जीपीयू को ड्रॉ के निर्देश भेजने में जितनी बार 12 मि॰से॰ से ज़्यादा समय लगा, उस संख्या में फ़्रेम की संख्या से भाग दिया जाता है.
• धीमे बिट मैप अपलोड: 16 मि॰से॰ से ज़्यादा समय में रेंडर होने वाले सभी फ़्रेम के लिए, बिट मैप को जीपीयू पर अपलोड होने में जितनी बार 3.2 मि॰से॰ से ज़्यादा समय लगा, उस संख्या में फ़्रेम की संख्या से भाग दिया जाता है.

समस्या को ठीक करना

अगर आपके ऐप्लिकेशन में ऐसे कई फ़्रेम मौजूद हैं जिन्हें रेंडर होने में 16 मि॰से॰ से ज़्यादा समय लगता है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए Android Developers साइट पर जाएं.

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

डेटा इकट्ठा करने की जानकारी

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

ज़रूरी जानकारी

• ऐसे सेशन जिन पर असर पड़ा: उन बैटरी सेशन का प्रतिशत जहां उपयोगकर्ताओं को एक घंटे से ज़्यादा समय के, कम से कम एक वेक लॉक का सामना करना पड़ा.
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: ऐसे 10%/1% डेली सेशन जहां उपयोगकर्ताओं को, दिखाई गई संख्या से ज़्यादा समय के लिए पार्शियल वेक लॉक का सामना करना पड़ा.
• ऐप्लिकेशन की खराब परफ़ॉर्मेंस का थ्रेशोल्ड: अगर आपके ऐप्लिकेशन में किसी समस्या के सामने आने का रेट, उसके थ्रेशोल्ड के बराबर या उससे ज़्यादा है, तो आपके ऐप्लिकेशन को Google Play पर टॉप 1,000 ऐप्लिकेशन (इंस्टॉल की संख्या के हिसाब से) के आखिरी 25% ऐप्लिकेशन में रखा जाता है.

समस्या को ठीक करना

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

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

डेटा इकट्ठा करने की जानकारी

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

ज़रूरी जानकारी

• ऐसे सेशन जिन पर असर पड़ा: उन बैटरी सेशन का प्रतिशत जब डिवाइस की स्क्रीन हर घंटे में, 10 से ज़्यादा बार चालू हुई. बैटरी सेशन, पिछले 24 घंटों में मिली सभी बैटरी रिपोर्ट की एक साथ इकट्ठा की गई जानकारी होती है. Android 10 की बैटरी रिपोर्ट में दो बार बैटरी चार्ज होने के बीच के समय की जानकारी होती है. इस रिपोर्ट में जानकारी तब ही शामिल होती है, जब बैटरी को 20% से कम से लेकर 80% से ज़्यादा तक या किसी भी वैल्यू से लेकर 100% तक चार्ज किया जाता है. Android 11 और उसके बाद वाले वर्शन की बैटरी रिपोर्ट में 24 घंटे की तय अवधि से जुड़ी जानकारी होती है. Google तब ही डेटा इकट्ठा करता है, जब डिवाइस चार्ज नहीं हो रहा हो.
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: ऐसे 10%/1% डेली सेशन जहां उपयोगकर्ताओं को हर घंटे में स्क्रीन चालू करने की संख्या, दिखाई गई वैल्यू से ज़्यादा दिखती है.
• ऐप्लिकेशन की खराब परफ़ॉर्मेंस का थ्रेशोल्ड: अगर आपके ऐप्लिकेशन में किसी समस्या के सामने आने का रेट, उसके थ्रेशोल्ड के बराबर या उससे ज़्यादा है, तो आपके ऐप्लिकेशन को Google Play पर टॉप 1,000 ऐप्लिकेशन (इंस्टॉल की संख्या के हिसाब से) के आखिरी 25% ऐप्लिकेशन में रखा जाता है.

समस्या को ठीक करना

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

बहुत ज़्यादा वाई-फ़ाई स्कैन (बैकग्राउंड) पेज दिखाता है कि वाई-फ़ाई स्कैन की वजह से कब बैटरी का बहुत ज़्यादा उपयोग हुआ है.

डेटा इकट्ठा करने की जानकारी

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

ज़रूरी जानकारी

• ऐसे सेशन जिन पर असर पड़ा: उन बैटरी सेशन का प्रतिशत जहां उपयोगकर्ताओं को, हर घंटे चार से ज़्यादा बार वाई-फ़ाई स्कैन का सामना करना पड़ा.
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: ऐसे 10%/1% डेली सेशन जहां ऐप्लिकेशन इस्तेमाल करने वाले लोगों को बैकग्राउंड में हर घंटे, दिखाई गई संख्या से ज़्यादा बार वाई-फ़ाई स्कैन का सामना करना पड़ा.

समस्या को ठीक करना

अगर आपका ऐप्लिकेशन, बैकग्राउंड में वाई-फ़ाई को कई बार स्कैन करता है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए, Android Developers साइट पर जाएं.

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

डेटा इकट्ठा करने की जानकारी

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

ज़रूरी जानकारी

• ऐसे सेशन जिन पर असर पड़ा: उन बैटरी सेशन का प्रतिशत जहां बैकग्राउंड में हर दिन 50 एमबी से ज़्यादा नेटवर्क का इस्तेमाल हुआ.
• सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
• 90वां/99वां पर्सेंटाइल: ऐसे 10%/1% डेली सेशन जहां ऐप्लिकेशन इस्तेमाल करने वाले लोगों ने पाया कि बैकग्राउंड में हर दिन, दिखाई गई संख्या से ज़्यादा नेटवर्क का इस्तेमाल किया गया.

समस्या को ठीक करना

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

अस्वीकार की गई अनुमतियां पेज पर, रोज़ाना अनुमति मांगने के उस सेशन का प्रतिशत देखा जा सकता है जिस दौरान उपयोगकर्ताओं ने अनुमतियां देने से मना किया है. रोज़ाना अनुमति मांगने का सेशन, वह दिन होता है जिस दौरान आपके ऐप्लिकेशन ने उपयोगकर्ता से कम से कम एक अनुमति मांगी है.

डेटा इकट्ठा करने की जानकारी

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

ज़रूरी जानकारी

• अस्वीकार किए गए: रोज़ाना अनुमति मांगने के समय का वह प्रतिशत, जिस दौरान उपयोगकर्ताओं ने अनुमतियां देने से मना कर दिया.
• फिर से कभी न पूछें: रोज़ाना अनुमति मांगने के समय का वह प्रतिशत जिस दौरान उपयोगकर्ताओं ने 'फिर से कभी न पूछें' चुनकर, अनुमतियां नहीं दीं.
• कुल सेशन: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.

समस्या को ठीक करना

अगर आपका ऐप्लिकेशन, अनुमतियों को बहुत बड़ी संख्या में अस्वीकार करता है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए, Android Developers साइट पर जाएं.

Google Play ने यूज़र-पर्सीव्ड ANR रेट मेट्रिक में, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड के बारे में जानकारी दी है:

• सभी डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन के सक्रिय उपयोगकर्ताओं में से कम से कम 0.47% लोगों को सभी डिवाइस मॉडल पर यूज़र-पर्सीव्ड ANR का सामना करना पड़ता है.

• किसी खास डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन के सक्रिय उपयोगकर्ताओं में से कम से कम 8% लोगों को किसी खास डिवाइस मॉडल पर यूज़र-पर्सीव्ड ANR का सामना करना पड़ता है.

ANR रेट को बेहतर करने के लिए, क्रैश और ANRs पेज पर रिपोर्ट किए गए ANR क्लस्टर ठीक करें. ANR का असर जितने ज़्यादा उपयोगकर्ताओं पर पड़ेगा उतना ही क्लस्टर का योगदान आपके ANR रेट पर होगा.

अगर डिवाइस का कोई खास हार्डवेयर या सॉफ़्टवेयर आपके ANR रेट पर असर डाल रहा होगा, तो 'Android की ज़रूरी जानकारी' की मदद से आपको इसकी सूचना मिलेगी. इसके अलावा, पहुंच और डिवाइस की खास जानकारी पेज (रिलीज़ करें > पहुंच और डिवाइस > खास जानकारी) पर जाकर, ANR रेट पर असर डालने वाले हार्डवेयर या सॉफ़्टवेयर की जानकारी खुद ही हासिल की जा सकती है.

Google Play ने यूज़र-पर्सीव्ड क्रैश रेट मेट्रिक में, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड से जुड़ी जानकारी दी है:

• सभी डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन के सक्रिय उपयोगकर्ताओं में से कम से कम 1.09% लोगों को सभी डिवाइस मॉडल पर यूज़र-पर्सीव्ड क्रैश का सामना करना पड़ता है.

• किसी खास डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन के सक्रिय उपयोगकर्ताओं में से कम से कम 8% लोगों को किसी खास डिवाइस मॉडल पर यूज़र-पर्सीव्ड क्रैश का सामना करना पड़ता है.

ऐप्लिकेशन की क्रैश रेट को बेहतर करने के लिए, क्रैश और ANRs पेज पर मौजूद क्रैश क्लस्टर ठीक करें. क्रैश का असर जितना ज़्यादा उपयोगकर्ताओं पर पड़ेगा उतना ही असर क्लस्टर का आपके क्रैश रेट पर भी होगा.

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