ऐप्लिकेशन की क्वालिटी से जुड़ी समस्याओं और सुझावों के बारे में नई अहम जानकारी
फ़िलहाल, ऐप्लिकेशन के साथ काम करने से जुड़ी समस्याएं, खराब परफ़ॉर्मेंस, और उपयोगकर्ता अनुभव से जुड़े कुछ सुझाव दिखाए जाते हैं. आने वाले साल में भी, हम क्वालिटी से जुड़ी समस्याओं का पता लगाकर उनके बारे में बताते रहेंगे. साथ ही, ऐप्लिकेशन की क्वालिटी को बेहतर बनाने के लिए, ज़्यादा सुझाव उपलब्ध कराएंगे.
Android की ज़रूरी जानकारी वाले पेज की मदद से, आपको अपने ऐप्लिकेशन के क्रैश या फ़्रीज़ होने, उसकी परफ़ॉर्मेंस, बैटरी खर्च वगैरह के बारे में जानकारी मिलती है. इस जानकारी का इस्तेमाल करके अपने ऐप्लिकेशन को और भी बेहतर बनाया जा सकता है.
अपने ऐप्लिकेशन के डेटा को ऐक्सेस करने का तरीका चुनना
'Android की ज़रूरी जानकारी' से मिले डेटा को ऐक्सेस करने के दो तरीके हैं: Play Console से और Play Developer Reporting API की मदद से.
एपीआई, प्रोग्राम के हिसाब से डेवलपर को 'Android की ज़रूरी जानकारी' के डेटा का ऐक्सेस अपने-आप देता रहता है. इससे उन डेवलपर को बेहद आसानी होती है जो इस डेटा को अन्य डेटासेट के साथ जोड़ना चाहते हैं या अपने वर्कफ़्लो में शामिल करना चाहते हैं. एपीआई की मदद से 'Android की ज़रूरी जानकारी' का डेटा ऐक्सेस करने के बारे में ज़्यादा जानने के लिए, Google Play Developer Reporting API पेज पर जाएं.
Play Console में, अपने ऐप्लिकेशन के बारे में Android की ज़रूरी जानकारी वाली सुविधा से मिला डेटा ढूंढने और उसकी समीक्षा करने के लिए:
- Play Console खोलें और Android की ज़रूरी जानकारी पेज (क्वालिटी > Android की ज़रूरी जानकारी > खास जानकारी) पर जाएं.
- आपको तारीख की सीमा के हिसाब से, अपने डेटा को देखने की सुविधा मिलती है. ऐसा करने के लिए ऊपर दाईं ओर, तारीख की सीमा चुनने वाले टूल का इस्तेमाल करें.
अहम जानकारी: अगर कोई डेटा उपलब्ध नहीं है, तो इसका मतलब है कि ऐप्लिकेशन से जुड़ी समस्याओं का पता लगाने के लिए जो फ़िल्टर इस्तेमाल किए गए हैं उनमें ज़रूरी डेटा पॉइंट मौजूद नहीं हैं.
अपने ऐप्लिकेशन की 'सबसे ज़रूरी जानकारी' पर नज़र रखना
Android की ज़रूरी जानकारी पेज में सबसे ऊपर, अपने ऐप्लिकेशन की 'सबसे ज़रूरी जानकारी' का डेटा देखा जा सकता है. ये आपके ऐप्लिकेशन की तकनीकी क्वालिटी की सबसे अहम मेट्रिक होती हैं. इसका असर इस बात पर भी पड़ता है कि Google Play पर आपके ऐप्लिकेशन को लोग आसानी से खोज पा रहे हैं या नहीं. 'सबसे ज़रूरी जानकारी' के डेटा में ये शामिल हैं:
- उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों के रेट (उन मामलों के हिसाब से एएनआर रेट जिनमें लोगों को लगा कि ऐप्लिकेशन ने काम करना बंद कर दिया)
- यूज़र-पर्सीव्ड क्रैश रेट (उन मामलों के हिसाब से क्रैश रेट जिनमें लोगों को लगा कि ऐप्लिकेशन क्रैश हो गया)
Google Play इन मेट्रिक में, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड के बारे में जानकारी देता है. अगर ऐप्लिकेशन के लिए एएनआर और क्रैश की संख्या इस थ्रेशोल्ड से ज़्यादा हो, तो Google Play पर आपके ऐप्लिकेशन को खोज पाने की संभावना कम हो जाती है. कुछ मामलों में तो आपके ऐप्लिकेशन के लिए स्टोर पेज पर चेतावनी भी दिखाई जा सकती है. ऐसा इसलिए किया जाता है, ताकि उपयोगकर्ताओं को ऐप्लिकेशन की परफ़ॉर्मेंस के बारे में जानकारी मिल सके.
"गंभीर समस्याएं" सेक्शन का इस्तेमाल करके, उन मामलों की तुरंत पहचान की जा सकती है जिनमें आपको ऐप्लिकेशन को बेहतर बनाने की ज़रूरत है. गंभीर समस्याएं दो तरह की होती हैं:
- ऐप्लिकेशन की खराब परफ़ॉर्मेंस: वे मेट्रिक जो ऐप्लिकेशन की खराब परफ़ॉर्मेंस के लिए तय थ्रेशोल्ड को पार कर चुकी हैं
- अनियमितताएं: डेटा में बड़े पैमाने पर बदलाव होना. उदाहरण के लिए, उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों के रेट में तेज़ी से बढ़ोतरी होना
इसके बारे में ईमेल से सूचनाएं पाने के लिए, सेटअप > सूचनाएं पर जाएं या "सबसे ज़रूरी जानकारी" सेक्शन के कोने में मौजूद सूचनाएं मैनेज करें (क्वालिटी > Android की ज़रूरी जानकारी > खास जानकारी) पर क्लिक करें. ध्यान दें कि अभी सिर्फ़ अनियमितताओं के लिए ही सूचनाएं दी जाती हैं.
सभी ज़रूरी जानकारी ब्राउज़ करनाAndroid की ज़रूरी जानकारी वाले पेज के बीच में, क्वालिटी के आधार पर मिली ज़रूरी जानकारी से जुड़ा डेटा देखा जा सकता है.
टेबल में, मौजूदा और पिछली समयावधि के लिए मेट्रिक देखी जा सकती हैं. यह भी देखा जा सकता है कि Google Play पर मौजूद अन्य ऐप्लिकेशन के मुकाबले, आपके ऐप्लिकेशन की परफ़ॉर्मेंस कैसी है.
किसी मेट्रिक के बारे में ज़्यादा जानकारी के लिए, मेट्रिक के बगल में मौजूद ब्यौरा देखें () चुनें. अगली स्क्रीन पर, इनकी समीक्षा की जा सकती है:
- ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड
- कैटगरी के मानदंड
- मानदंड की पूरी तुलना
- मिलते-जुलते ऐप्लिकेशन का पसंद के मुताबिक बनाया गया ग्रुप में बदलाव करने के लिए, पेज में सबसे ऊपर, मिलते-जुलते ऐप्लिकेशन की तुलना वाले कार्ड में मिलते-जुलते ऐप्लिकेशन के ग्रुप में बदलाव करें चुनें. मिलते-जुलते ऐप्लिकेशन का पसंद के मुताबिक बनाया गया ग्रुप बनाने के बाद, यह देखा जा सकता है कि Google Play पर मौजूद अन्य ऐप्लिकेशन के मुकाबले, आपके ऐप्लिकेशन की परफ़ॉर्मेंस कैसी है.
- समय के हिसाब से मेट्रिक में हुए बदलाव
आपके डेटा को व्यवस्थित करने, उसे अलग-अलग हिस्सों में बांटने, और उसका विश्लेषण करने में आपकी मदद के लिए, मेट्रिक को कई अलग-अलग डाइमेंशन के हिसाब से बांटा जाता है. सभी मेट्रिक में ये आंकड़े होते हैं:
- आर्टफ़ैक्ट: आपके ऐप्लिकेशन का वह वर्शन जिसमें समस्या हुई है
- Android वर्शन (एसडीके): ऐप्लिकेशन इस्तेमाल करने वाले व्यक्ति के डिवाइस से रिपोर्ट किया गया Android OS का वर्शन
- डिवाइस का साइज़, डाइमेंशन या कॉन्फ़िगरेशन: डिवाइस का वह टाइप जिस पर आपका ऐप्लिकेशन इस्तेमाल किया गया. उदाहरण के लिए, फ़ोन, टैबलेट, टीवी, पहना जाने वाला डिवाइस
- डिवाइस का मॉडल: डिवाइस के बारे में पूरी जानकारी. इसमें किसी खास ब्रैंड और डिवाइस के आइडेंटिफ़ायर की जानकारी शामिल होती है. जैसे, "Google Oriole". किसी डिवाइस के एक मॉडल में अलग-अलग Android वर्शन, रैम, स्टोरेज या चिप पर सिस्टम (SoC) वाले वैरिएंट हो सकते हैं.
- देश/इलाके: समस्या के समय व्यक्ति के डिवाइस की जगह
अहम जानकारी: डिवाइस के हार्डवेयर या सॉफ़्टवेयर के हिसाब से ब्रेकडाउन देखने के लिए, टेबल में डिवाइस के बगल में मौजूद आइकॉन () पर क्लिक करें. इसमें डिवाइस का मॉडल या Android वर्शन शामिल हो सकता है.
ब्रेकडाउन के बारे में ज़्यादा जानकारी देने वाली कुछ मेट्रिक:
- वेक लॉक का नाम: ऐसे टैग जो आपके ऐप्लिकेशन में PowerManager API इस्तेमाल करते समय, प्रोग्राम के हिसाब से अपने-आप सेट हुए थे
- वेक-अप का नाम: ऐसे टैग जो आपके ऐप्लिकेशन में AlarmManager API का इस्तेमाल करते समय, प्रोग्राम के हिसाब से अपने-आप सेट हुए थे
- एएनआर वाली गतिविधि का नाम: गतिविधि की उस क्लास का पूरी तरह क्वालिफ़ाइड नाम जिसमें एएनआर वाली गड़बड़ी हुई (अगर उपलब्ध हो)
- एएनआर का टाइप: एएनआर वाली गड़बड़ी कब हुई. उदाहरण के लिए, किसी सेवा पर काम करते समय (अगर उपलब्ध हो)
ज़्यादा जानकारी उपलब्ध होने पर, उसे देखा जा सकता है. उदाहरण के लिए, ब्रेकडाउन से जुड़े क्रैश या एएनआर क्लस्टर की जानकारी. इसके लिए, आइटम के बगल में मौजूद जानकारी देखें () चुनें.
अहम जानकारी: स्क्रीन के सबसे ऊपर दिए गए टॉगल का इस्तेमाल करके, आपके पास किसी कैटगरी में, एक मेट्रिक से दूसरी मेट्रिक में जाने का विकल्प होता है. साथ ही, पेज को फ़िल्टर भी किया जा सकता है.
डेटा टाइप और मेट्रिक
'Android की ज़रूरी जानकारी' का पिछले 90 दिनों का डेटा, Play Console में उपलब्ध होता है. साथ ही, Play Developer Reporting API में इसका तीन साल तक का डेटा उपलब्ध होता है.
यह डेटा, अलग-अलग Android डिवाइसों और ओएस वर्शन का इस्तेमाल करने वाले उन उपयोगकर्ताओं से इकट्ठा किया जाता है जिन्होंने इस्तेमाल और गड़बड़ी से जुड़ी जानकारी अपने-आप शेयर होने की सुविधा के लिए ऑप्ट-इन किया है. Android के उपयोगकर्ता, डेटा शेयर करने के लिए किस तरह ऑप्ट-इन कर सकते हैं, इस बारे में ज़्यादा जानने के लिए खाता सहायता केंद्र पर जाएं.
'Android की ज़रूरी जानकारी' हर दिन अपडेट होती है. कई बार ऐसा हो सकता है कि Android 10 के बाद के वर्शन वाले डिवाइसों का डेटा, इससे पहले के वर्शन वाले डिवाइसों के डेटा से पहले मिल जाए. अगर ऐसा होता है, तो जितने दिनों के लिए, Android 10 के बाद के वर्शन वाले डिवाइसों का डेटा मौजूद रहेगा उतने दिनों के लिए सिर्फ़ यही डेटा दिखेगा.
ध्यान दें: Android की ज़रूरी जानकारी वाली मेट्रिक में, उन तकनीकी समस्याओं को शामिल नहीं किया जाता है जो बिना सर्टिफ़िकेट वाले डिवाइस मॉडल या आपके ऐप्लिकेशन के ऐसे वर्शन में होती हैं जिन्हें Google Play से इंस्टॉल नहीं किया गया है.
सभी को छोटा करें सभी को बड़ा करें
ऐप्लिकेशन को क्रैश या फ़्रीज़ होने जैसी समस्याओं से बचाना
एएनआर रेट से जुड़ी मेट्रिकएएनआर रेट से जुड़ी मेट्रिक, आपके ऐप्लिकेशन की क्वालिटी के बारे में खास जानकारी देती हैं. इन मेट्रिक में, उपयोगकर्ताओं की संख्या और एएनआर की संख्या को कैलकुलेट किया जाता है, फिर इन्हें आपके ऐप्लिकेशन के इस्तेमाल के हिसाब से नॉर्मलाइज़ किया जाता है. इन मेट्रिक में, हर दिन के सक्रिय उपयोगकर्ताओं के प्रतिशत को शामिल किया जाता है. एक दिन में किसी डिवाइस पर आपके ऐप्लिकेशन का इस्तेमाल करने वाले व्यक्ति को हर दिन का सक्रिय उपयोगकर्ता माना जाता है. अगर कोई उपयोगकर्ता आपके ऐप्लिकेशन का इस्तेमाल एक दिन में एक से ज़्यादा डिवाइसों पर करता है, तो उस दिन सक्रिय उपयोगकर्ता की गिनती इस्तेमाल किए गए डिवाइस के अनुसार की जाएगी. अगर एक दिन में कई उपयोगकर्ता एक ही डिवाइस का इस्तेमाल करते हैं, तो उन सभी की गिनती एक सक्रिय उपयोगकर्ता के तौर पर की जाएगी.
एएनआर रेट से जुड़ी मेट्रिक तीन तरह की होती हैं:
- उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों का रेट: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों का प्रतिशत जिन्होंने उपयोगकर्ता को महसूस होने वाली एएनआर की कम से कम एक गड़बड़ी का सामना किया. उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों का मतलब एएनआर वाली उन गड़बड़ियां से है जो शायद ऐप्लिकेशन पर उपयोगकर्ता को दिखी हों. फ़िलहाल, इनमें सिर्फ़ "इनपुट भेजने का समय खत्म हुआ" मैसेज वाली गड़बड़ियां गिनी जाती हैं. इस मेट्रिक की वैल्यू, हमेशा आपके ऐप्लिकेशन के कुल एएनआर रेट से कम होगी. ऐसा इसलिए, क्योंकि इसे आपके ऐप्लिकेशन के रोज़ाना इस्तेमाल के हिसाब से नॉर्मलाइज़ किया जाता है. हालांकि, इसमें सभी एएनआर को शामिल नहीं किया जाता है.
उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों का रेट, ऐप्लिकेशन के लिए सबसे ज़रूरी जानकारी है. इसका असर इस बात पर पड़ता है कि Google Play पर आपके ऐप्लिकेशन को लोग आसानी से खोज पा रहे हैं या नहीं. उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों का रेट बहुत मायने रखता है, क्योंकि इसमें उन एनआर को शामिल किया जाता है जिनका सामना उपयोगकर्ता को आपका ऐप्लिकेशन इस्तेमाल करते समय अक्सर करना पड़ता है. साथ ही, इनकी वजह से ऐप्लिकेशन में सबसे ज़्यादा क्रैश और फ़्रीज़ होने जैसी समस्याएं भी आती हैं.
- एएनआर रेट: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों का प्रतिशत जिन्होंने एएनआर वाली कम से कम एक गड़बड़ी का सामना किया. इस मेट्रिक में ऐसे एएनआर के मामलों की जानकारी होती है जिन्हें उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों के तौर पर नहीं गिना जाता. हालांकि, हम इस बात की गारंटी नहीं दे सकते कि ये एएनआर उपयोगकर्ताओं के अनुभव पर असर नहीं डालते.
- मल्टिपल-एएनआर रेट: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों का प्रतिशत जिन्होंने एएनआर वाली कम से कम दो गड़बड़ियों का सामना किया. यह मेट्रिक, समस्या से जुड़े लूप को हाइलाइट करने में मदद करती है.
समस्या को ठीक करना
एएनआर रेट की मेट्रिक में जिन एएनआर की गड़बड़ियों को शामिल किया जाता है उनकी जानकारी क्रैश और एएनआर पेज पर दी जाती है. यहां पर उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों को फ़िल्टर किया जा सकता है.
Android Developers साइट, एएनआर का पता लगाने और उसे ठीक करने से जुड़ी जानकारी उपलब्ध कराती है.
क्रैश रेट से जुड़ी मेट्रिक, आपके ऐप्लिकेशन की क्वालिटी की खास जानकारी देती हैं. इन मेट्रिक में, उपयोगकर्ताओं की संख्या और क्रैश की संख्या को कैलकुलेट किया जाता है. फिर इन्हें आपके ऐप्लिकेशन के इस्तेमाल के हिसाब से नॉर्मलाइज़ किया जाता है. मेट्रिक में इन उपयोगकर्ताओं को हर दिन के उपयोगकर्ताओं के प्रतिशत के तौर पर शामिल किया जाता है. हर दिन के उपयोगकर्ता में उन लोगों को गिना जाता है जो एक दिन में किसी डिवाइस पर आपके ऐप्लिकेशन का इस्तेमाल करते हैं. अगर किसी उपयोगकर्ता के पास एक से ज़्यादा डिवाइस हैं, तो उस उपयोगकर्ता को एक से ज़्यादा बार गिना जाएगा. उदाहरण के लिए, अगर दो उपयोगकर्ता अपने-अपने डिवाइस पर, दो दिन तक ऐप्लिकेशन इस्तेमाल करते हैं, तो उससे चार डेली सेशन बनेंगे.
क्रैश रेट से जुड़ी तीन मेट्रिक होती हैं:
- यूज़र-पर्सीव्ड क्रैश रेट: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों का प्रतिशत जिन्होंने कम से कम एक यूज़र-पर्सीव्ड क्रैश का सामना किया. यूज़र-पर्सीव्ड क्रैश, वह क्रैश होता है जिसमें उपयोगकर्ता को ऐप्लिकेशन में क्रैश से जुड़ी गड़बड़ी का पता चलता है. उदाहरण के लिए, ऐप्लिकेशन में क्रैश होने की गड़बड़ी तब होती है, जब आपका ऐप्लिकेशन किसी गतिविधि को दिखा रहा होता है या किसी फ़ोरग्राउंड सेवा के तौर पर काम कर रहा होता है. यह मेट्रिक, हमेशा आपके ऐप्लिकेशन के कुल क्रैश रेट की संख्या से कम होगी. इसकी वजह यह है कि आपके ऐप्लिकेशन के रोज़ाना इस्तेमाल के हिसाब से इसे नॉर्मलाइज़ किया जाता है. हालांकि, इसमें सभी क्रैश शामिल नहीं किए जाते हैं.
यूज़र-पर्सीव्ड क्रैश रेट, ऐप्लिकेशन के लिए 'सबसे ज़रूरी जानकारी' की तरह होता है. इसका मतलब है कि इसका असर इस बात पर भी पड़ता है कि Google Play पर आपके ऐप्लिकेशन को लोग आसानी से खोज पा रहे हैं या नहीं. यूज़र-पर्सीव्ड क्रैश रेट बहुत ही ज़रूरी जानकारी होती है. इसमें उन क्रैश की गिनती की जाती है जिनसे उपयोगकर्ता को आपका ऐप्लिकेशन इस्तेमाल करते समय अक्सर सामना करना पड़ता है. साथ ही, इनसे ऐप्लिकेशन में सबसे ज़्यादा क्रैश और फ़्रीज़ होने जैसी समस्याएं भी आती हैं. इसलिए, आपको यह पक्का करना चाहिए कि आपका ऐप्लिकेशन इस मेट्रिक के लिए, ऐप्लिकेशन की खराब परफ़ॉर्मेंस का थ्रेशोल्ड को पार न करे.
-
क्रैश रेट: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों का प्रतिशत जिन्होंने कम से कम एक क्रैश का सामना किया. इस मेट्रिक में, ऐसे क्रैश मामलों की जानकारी शामिल होती है जिन्हें यूज़र-पर्सीव्ड ANR के तौर पर नहीं गिना जाता. हालांकि, हम इस बात की गारंटी नहीं दे सकते कि ये क्रैश उपयोगकर्ताओं पर असर डालते हैं या नहीं.
-
एक से ज़्यादा बार क्रैश होने की दर: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले उन लोगों का प्रतिशत जिन्होंने कम से कम दो क्रैश का सामना किया. यह मेट्रिक, समस्या से जुड़े लूप को हाइलाइट करने में मदद करती है.
समस्या को ठीक करना
Android Developers साइट, क्रैश का पता लगाने और उसे ठीक करने से जुड़ी जानकारी उपलब्ध कराती है.
ऐप्लिकेशन चालू होने और लोड होने में लगने वाला समय
शुरू होने का समय (शुरुआती डिसप्ले में लगने वाला समय)ऐप्लिकेशन के चालू होने में लगने वाला समय पेज पर, यह जानकारी मिलती है कि आपका ऐप्लिकेशन किस समय, सिस्टम की कोल्ड, वॉर्म, और हॉट स्थितियों से धीरे शुरू होता है. उपयोगकर्ता के डिवाइस पर आपका ऐप्लिकेशन खोले जाने से लेकर, स्क्रीन पर पहली बार फ़्रेम दिखने के बीच लगने वाले समय को, ऐप्लिकेशन चालू होने में लगने वाला समय कहा जाता है. इसे 'शुरुआती डिसप्ले में लगने वाला समय' के तौर पर भी जाना जाता है.
हो सकता है कि इस समय के बाद भी आपका ऐप्लिकेशन, उपयोगकर्ता से इंटरैक्शन के लिए तैयार न हो. उदाहरण के लिए, ऐसा तब हो सकता है, जब आपके ऐप्लिकेशन में लोड होने वाली स्क्रीन की संख्या ज़्यादा हो.
डेटा इकट्ठा करने की जानकारी
- शुरू होने में लगने वाले समय तभी रिकॉर्ड किए जाते हैं, जब कोई उपयोगकर्ता किसी गतिविधि को ट्रिगर करता है.
- उदाहरण: कीबोर्ड ऐप्लिकेशन के लिए, शुरू होने में लगा समय, साथी ऐप्लिकेशन के शुरू होने में लगने वाले समय के बराबर होता है.
- अगर कोई ऐप्लिकेशन एक ही दिन में एक ही सिस्टम स्थिति से कई बार शुरू होता है, तो उस दिन के लिए ऐप्लिकेशन के शुरू होने में लगने वाले सबसे ज़्यादा समय को रिकॉर्ड किया जाता है.
- ऐप्लिकेशन का पहला फ़्रेम पूरी तरह लोड हो जाने पर, शुरू होने में लगने वाले समय ट्रैक किए जाते हैं. भले ही, वह ऐसी स्क्रीन न हो जिससे उपयोगकर्ता इंटरैक्ट करता हो.
- उदाहरण: अगर कोई ऐप्लिकेशन स्प्लैश स्क्रीन से शुरू होता है, तो ऐप्लिकेशन शुरू होने में लगने वाला समय, स्प्लैश स्क्रीन दिखने के लिए ज़रूरी समय के बराबर होता है.
ज़रूरी जानकारी
- ऐसे सेशन जिन पर असर पड़ा: उन सेशन का प्रतिशत जिनके दौरान लोगों को सिस्टम की हर स्थिति में ऐप्लिकेशन के धीरे शुरू होने की समस्या का सामना किया:
- स्लो कोल्ड स्टार्ट: पांच सेकंड या इससे ज़्यादा
- स्लो वॉर्म स्टार्ट: दो सेकंड या उससे ज़्यादा
- स्लो हॉट स्टार्ट: 1 सेकंड या उससे ज़्यादा
- सेशन की संख्या: रिकॉर्ड किए गए सेशन की अनुमानित संख्या.
- 90वां/99वां पर्सेंटाइल: ऐसे 10%/1% डेली सेशन जहां आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों को ऐप्लिकेशन शुरू होने में ज़्यादा समय लगने की समस्या का सामना करना पड़ा.
समस्या को ठीक करना
अगर आपके ऐप्लिकेशन को खुलने में आम तौर पर ज़्यादा समय लगता है, तो इस समस्या को ठीक करने के सुझाए गए तरीके जानने के लिए, Android Developers साइट पर जाएं.
रेंडरिंग
रेंडर किए गए सभी फ़्रेम की मेट्रिक
धीमे सेशन की दर (30 FPS या 20 FPS) [सिर्फ़ गेम के लिए]यह क्यों ज़रूरी है
'धीमे सेशन' मेट्रिक का इस्तेमाल करके, अपने गेम के फ़्रेम रेट की परफ़ॉर्मेंस को समझा जा सकता है. इसकी मदद से डेवलपर यह जान सकते हैं कि लोग उनके गेम को आसानी से खेल पा रहे हैं या नहीं.
अपने ऐप्लिकेशन के डेटा के बारे में जानें
'धीमे सेशन' मेट्रिक के पेज पर, आपको उन डेली सेशन के प्रतिशत के बारे में जानकारी मिलेगी जहां उपयोगकर्ताओं को 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 साइट पर जाएं.
'Android यूज़र इंटरफ़ेस (यूआई) टूलकिट' का इस्तेमाल करके, फ़्रेम रेंडर होने में लगने वाला समय
रेंडर होने में काफ़ी ज़्यादा समय लेने वाले फ़्रेम [सिर्फ़ ऐप्लिकेशन के लिए]अपने ऐप्लिकेशन के डेटा के बारे में जानें
'बहुत ज़्यादा समय लेने वाले फ़्रेम' पेज पर, आपको उन डेली सेशन के प्रतिशत के बारे में जानकारी मिलेगी जहां उपयोगकर्ताओं को 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 ने आपके ऐप्लिकेशन की सबसे ज़रूरी जानकारी के लिए, ऐप्लिकेशन के ठीक से काम न करने की समस्या के थ्रेशोल्ड तय किए हैं.
अगर आपका ऐप्लिकेशन, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड को पार कर लेता है, तो Google Play पर आपके ऐप्लिकेशन को खोजे जाने की संभावना कम हो जाती है. अगर किसी खास डिवाइस मॉडल पर, आपके ऐप्लिकेशन की परफ़ॉर्मेंस खराब है, तो Google Play अपने उपयोगकर्ताओं को आपके ऐप्लिकेशन के बजाय, इन डिवाइसों के मुताबिक काम करने वाले ऐप्लिकेशन इस्तेमाल करने का सुझाव देता है. कुछ मामलों में, आपके ऐप्लिकेशन के स्टोर पेज पर इसके लिए चेतावनी भी दिखाई जा सकती है. इससे, ऐप्लिकेशन की परफ़ॉर्मेंस को उपयोगकर्ता के हिसाब से बेहतर बनाने में मदद मिलती है. साथ ही, उपयोगकर्ताओं को Google Play पर, बेहतर तकनीकी क्वालिटी वाले किसी अन्य ऐप्लिकेशन का सुझाव भी दिया जा सकता है.
आम तौर पर, Google Play आपके ऐप्लिकेशन की क्वालिटी का आकलन करते समय, पिछले 28 दिनों का डेटा इस्तेमाल करता है. हालांकि, अगर आपके ऐप्लिकेशन में गड़बड़ियों की संख्या बढ़ती है, तो ऐप्लिकेशन पर जल्द कार्रवाई की जा सकती है.
सभी को छोटा करें सभी को बड़ा करें
ऐप्लिकेशन को क्रैश या फ़्रीज़ होने जैसी समस्याओं से बचाना
उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों के रेट के थ्रेशोल्डGoogle Play ने यूज़र-पर्सीव्ड ANR रेट मेट्रिक में, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड के बारे में जानकारी दी है:
-
सभी डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों में से कम से कम 0.47% लोगों को सभी डिवाइस मॉडल पर, उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों का सामना करना पड़ता है.
-
किसी खास डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों में से कम से कम 8% लोगों को किसी एक डिवाइस मॉडल पर, उपयोगकर्ता को महसूस हुई एएनआर वाली गड़बड़ियों का सामना करना पड़ता है.
एएनआर रेट को बेहतर करने के लिए, क्रैश और एएनआर पेज पर रिपोर्ट किए गए एएनआर क्लस्टर ठीक करें. एएनआर का असर जितने ज़्यादा लोगों पर पड़ेगा क्लस्टर का उतना ही योगदान आपके एएनआर रेट पर होगा.
ऐसा हो सकता है कि डिवाइस का कोई खास हार्डवेयर या सॉफ़्टवेयर आपके एएनआर रेट पर असर डाल रहा हो. ऐसे में Android की ज़रूरी जानकारी की सुविधा के ज़रिए आपको इसकी सूचना दी जाएगी. इसके अलावा, पहुंच और डिवाइस की खास जानकारी पेज (रिलीज़ करें > पहुंच और डिवाइस > की खास जानकारी) पर जाकर, एएनआर रेट पर असर डालने वाले हार्डवेयर या सॉफ़्टवेयर की जानकारी खुद ही हासिल की जा सकती है.
Google Play ने यूज़र-पर्सीव्ड क्रैश रेट मेट्रिक में, ऐप्लिकेशन की खराब परफ़ॉर्मेंस के थ्रेशोल्ड से जुड़ी जानकारी दी है:
-
सभी डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों में से कम से कम 1.09% लोगों को सभी डिवाइस मॉडल पर यूज़र-पर्सीव्ड क्रैश का सामना करना पड़ता है.
-
किसी खास डिवाइस मॉडल पर ऐप्लिकेशन की खराब परफ़ॉर्मेंस: हर दिन आपका ऐप्लिकेशन इस्तेमाल करने वाले लोगों में से कम से कम 8% लोगों को किसी खास डिवाइस मॉडल पर एक यूज़र-पर्सीव्ड क्रैश का सामना करना पड़ता है.
ऐप्लिकेशन की क्रैश रेट को बेहतर करने के लिए, क्रैश और ANRs पेज पर मौजूद क्रैश क्लस्टर ठीक करें. क्रैश का असर जितना ज़्यादा उपयोगकर्ताओं पर पड़ेगा उतना ही असर क्लस्टर का आपके क्रैश रेट पर भी होगा.
अगर डिवाइस का कोई खास हार्डवेयर या सॉफ़्टवेयर आपके क्रैश रेट पर असर डाल रहा है, तो 'Android की ज़रूरी जानकारी' की मदद से आपको इसकी सूचना मिलेगी. इसके अलावा, पहुंच और डिवाइस की खास जानकारी पेज (रिलीज़ करें > पहुंच और डिवाइस > खास जानकारी) पर जाकर, क्रैश रेट पर असर डालने वाले हार्डवेयर या सॉफ़्टवेयर की जानकारी खुद ही हासिल की जा सकती है.
मिलता-जुलता कॉन्टेंट
अपने ऐप्लिकेशन की परफ़ॉर्मेंस और बिना क्रैश या फ़्रीज़ हुए काम करने की क्षमता को बेहतर बनाने के लिए 'Android की ज़रूरी जानकारी' को इस्तेमाल करने के सबसे सही तरीके जानें.