परफ़ॉर्मेंस मॉनिटर करने से जुड़ी समस्या हल करना और अक्सर पूछे जाने वाले सवाल

परफ़ॉर्मेंस इवेंट के लिए लॉग मैसेज देखने का तरीका

1. बिल्ड के समय Performance Monitoring के लिए डीबग लॉगिंग चालू करें. इसके लिए, अपने ऐप्लिकेशन की AndroidManifest.xml फ़ाइल में <meta-data> एलिमेंट जोड़ें. जैसे:

   <application>
       <meta-data
         android:name="firebase_performance_logcat_enabled"
         android:value="true" />
   </application>

2. गड़बड़ी के मैसेज देखने के लिए, अपने लॉग मैसेज देखें.

3. Performance Monitoring अपने लॉग मैसेज को FirebasePerformance के साथ टैग करता है. Logcat फ़िल्टर का इस्तेमाल करके, खास तौर पर ड्यूरेशन ट्रेस और एचटीटीपी/एस नेटवर्क अनुरोध की लॉगिंग देखी जा सकती है. इसके लिए, यह कमांड चलाएं:

   adb logcat -s FirebasePerformance

4. यहां दिए गए लॉग देखें. इनसे पता चलता है कि Performance Monitoring, परफ़ॉर्मेंस इवेंट लॉग कर रहा है:

   • Logging trace metric: TRACE_NAME, FIREBASE_PERFORMANCE_CONSOLE_URL
   • Logging network request trace: URL

5. Firebase कंसोल में अपना डेटा देखने के लिए, यूआरएल पर क्लिक करें. डैशबोर्ड में डेटा अपडेट होने में कुछ समय लग सकता है.

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

ऐप्लिकेशन में SDK टूल जोड़ दिया गया है, लेकिन कंसोल में अब भी SDK टूल जोड़ने के लिए कहा जा रहा है

जब Firebase को आपके ऐप्लिकेशन से इवेंट की जानकारी (जैसे, ऐप्लिकेशन इंटरैक्शन) मिलती है, तो वह यह पता लगा सकता है कि आपने अपने ऐप्लिकेशन में Performance Monitoring SDK टूल को सही तरीके से जोड़ा है या नहीं. आम तौर पर, ऐप्लिकेशन शुरू करने के 10 मिनट के अंदर, Firebase कंसोल के परफ़ॉर्मेंस डैशबोर्ड पर "SDK टूल का पता चला" मैसेज दिखता है. इसके बाद, 30 मिनट के अंदर डैशबोर्ड पर प्रोसेस किया गया शुरुआती डेटा दिखने लगता है.

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

Console में SDK टूल का पता चलने की जानकारी दिख रही है, लेकिन कोई डेटा नहीं दिख रहा है

Performance Monitoring, परफ़ॉर्मेंस इवेंट डेटा को प्रोसेस करता है. इसके बाद, उसे परफ़ॉर्मेंस डैशबोर्ड में दिखाता है.

अगर "एसडीके टूल का पता चला" मैसेज दिखने के बाद 24 घंटे से ज़्यादा समय हो गया है और आपको अब भी डेटा नहीं दिख रहा है, तो Firebase स्टेटस डैशबोर्ड देखें. ऐसा हो सकता है कि कोई समस्या हो. अगर कोई आउटेज नहीं है, तो Firebase की सहायता टीम से संपर्क करें.

ऐप्लिकेशन, परफ़ॉर्मेंस इवेंट लॉग नहीं कर रहा है

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

1. Performance Monitoring Gradle प्लग इन का सेटअप देखने के लिए, यह तरीका अपनाएं:

   1. पक्का करें कि आपने प्लग इन को सही तरीके से जोड़ा हो. खास तौर पर, इन बातों का ध्यान रखें:

      • आपने अपनी मॉड्यूल (ऐप्लिकेशन-लेवल) build.gradle फ़ाइल में प्लग इन (apply plugin: 'com.google.firebase.firebase-perf') जोड़ा है.
      • आपने अपनी प्रोजेक्ट-लेवल build.gradle फ़ाइल में, प्लगिन (classpath 'com.google.firebase:perf-plugin:2.0.2') के लिए क्लासपाथ डिपेंडेंसी शामिल की हो.

   2. पक्का करें कि इनमें से किसी भी फ़्लैग का इस्तेमाल करके, प्लग इन को बंद न किया गया हो:

      • आपके मॉड्यूल (ऐप्लिकेशन-लेवल) की build.gradle फ़ाइल में instrumentationEnabled
      • आपकी gradle.properties फ़ाइल में firebasePerformanceInstrumentationEnabled

2. देखें कि आपकी AndroidManifest.xml फ़ाइल में, इनमें से किसी भी फ़्लैग की मदद से Performance Monitoring SDK टूल को बंद न किया गया हो:

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

3. पक्का करें कि Performance Monitoring को रनटाइम के दौरान बंद न किया गया हो.

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

परफ़ॉर्मेंस डैशबोर्ड में, स्क्रीन ट्रेस डेटा मौजूद नहीं है

अगर आपको स्क्रीन रेंडरिंग ट्रेस का डेटा नहीं मिल रहा है, तो समस्या हल करने के लिए यह तरीका आज़माएं:

1. पक्का करें कि Android SDK टूल के सबसे नए वर्शन (v23.0.1) का इस्तेमाल किया जा रहा हो. स्क्रीन रेंडरिंग ट्रेस की सुविधा, सिर्फ़ v15.2.0 या इसके बाद के वर्शन पर उपलब्ध है.

2. पक्का करें कि आपने किसी स्क्रीन के लिए, हार्डवेयर से तेज़ी लाएं सुविधा को मैन्युअल तरीके से बंद न किया हो.

3. पक्का करें कि DexGuard या Jack का इस्तेमाल न किया जा रहा हो. Performance Monitoring, इन टूलचेन के साथ काम नहीं करता.

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

   • Jack का इस्तेमाल अब नहीं किया जाता. आम तौर पर, इसका इस्तेमाल आपके ऐप्लिकेशन में नहीं किया जाना चाहिए.

परफ़ॉर्मेंस डैशबोर्ड में, कस्टम ट्रेस डेटा मौजूद नहीं है

क्या आपको अपने-आप इकट्ठा होने वाले ट्रेस की परफ़ॉर्मेंस का डेटा दिख रहा है, लेकिन कस्टम कोड ट्रेस की परफ़ॉर्मेंस का डेटा नहीं दिख रहा है? समस्या हल करने के लिए, यह तरीका आज़माएं:

1. अगर आपने Trace API की मदद से, कस्टम कोड ट्रेस को इंस्ट्रुमेंट किया है, तो ट्रेस के सेटअप की जांच करें. खास तौर पर, इनकी जांच करें:

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

2. अगर आपने @AddTrace नोटेशन की मदद से, कस्टम कोड ट्रेस को इंस्ट्रूमेंट किया है, तो Performance Monitoring Gradle प्लग इन का सेटअप देखें:

   1. पक्का करें कि आपने प्लग इन को सही तरीके से जोड़ा हो. खास तौर पर, इन बातों का ध्यान रखें:

      • आपने अपनी मॉड्यूल (ऐप्लिकेशन-लेवल) build.gradle फ़ाइल में प्लग इन (apply plugin: 'com.google.firebase.firebase-perf') जोड़ा है.
      • आपने अपनी प्रोजेक्ट-लेवल build.gradle फ़ाइल में, प्लगिन (classpath 'com.google.firebase:perf-plugin:2.0.2') के लिए क्लासपाथ डिपेंडेंसी शामिल की हो.

   2. पक्का करें कि इनमें से किसी भी फ़्लैग का इस्तेमाल करके, प्लग इन को बंद न किया गया हो:

      • आपके मॉड्यूल (ऐप्लिकेशन-लेवल) की build.gradle फ़ाइल में instrumentationEnabled
      • आपकी gradle.properties फ़ाइल में firebasePerformanceInstrumentationEnabled

3. अपने लॉग मैसेज देखें, ताकि यह पक्का किया जा सके कि Performance Monitoring, कस्टम कोड के ट्रेस को उम्मीद के मुताबिक लॉग कर रहा है.

4. अगर Performance Monitoring इवेंट लॉग कर रहा है, लेकिन 24 घंटे के बाद भी कोई डेटा नहीं दिखता है, तो Firebase की सहायता टीम से संपर्क करें.

परफ़ॉर्मेंस डैशबोर्ड में नेटवर्क अनुरोध का डेटा मौजूद नहीं है

अगर आपको नेटवर्क अनुरोध का डेटा नहीं मिल रहा है, तो समस्या हल करने के लिए यह तरीका अपनाएं:

1. Android ऐप्लिकेशन के लिए, Performance Monitoring Gradle प्लग इन, इंस्ट्रुमेंटेशन की सुविधा चालू करता है. इससे एचटीटीपी/एस नेटवर्क के अनुरोधों की अपने-आप निगरानी की जा सकती है. इन बातों पर ध्यान दें:

   1. पक्का करें कि आपने प्लग इन को सही तरीके से जोड़ा हो. खास तौर पर, इन बातों का ध्यान रखें:

      • आपने अपनी मॉड्यूल (ऐप्लिकेशन-लेवल) build.gradle फ़ाइल में प्लग इन (apply plugin: 'com.google.firebase.firebase-perf') जोड़ा है.
      • आपने अपनी प्रोजेक्ट-लेवल build.gradle फ़ाइल में, प्लगिन (classpath 'com.google.firebase:perf-plugin:2.0.2') के लिए क्लासपाथ डिपेंडेंसी शामिल की हो.

   2. पक्का करें कि इनमें से किसी भी फ़्लैग का इस्तेमाल करके, प्लग इन को बंद न किया गया हो:

      • आपके मॉड्यूल (ऐप्लिकेशन-लेवल) की build.gradle फ़ाइल में instrumentationEnabled
      • आपकी gradle.properties फ़ाइल में firebasePerformanceInstrumentationEnabled

2. देखें कि नेटवर्क लाइब्रेरी काम कर रही है या नहीं. Performance Monitoring, नेटवर्क के उन अनुरोधों के लिए मेट्रिक अपने-आप इकट्ठा करता है जो इन नेटवर्किंग लाइब्रेरी का इस्तेमाल करते हैं: OkHttp 3.x.x, Java का URLConnection, और Apache HttpClient.

   ध्यान दें कि नेटवर्क के अनुरोधों के लिए, कस्टम मॉनिटरिंग जोड़ी जा सकती है.

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

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

   • Performance Monitoring, DexGuard और Jack के साथ काम नहीं करता.

     • DexGuard, एचटीटीपी/एस नेटवर्क के अनुरोधों की निगरानी करने की सुविधा बंद कर देता है.
     • Jack का इस्तेमाल अब नहीं किया जाता. आम तौर पर, इसका इस्तेमाल आपके ऐप्लिकेशन में नहीं किया जाना चाहिए.

   • Performance Monitoring, अमान्य Content-Type हेडर वाले नेटवर्क अनुरोधों की रिपोर्ट नहीं करता. हालांकि, Content-Type हेडर के बिना किए गए नेटवर्क अनुरोध अब भी स्वीकार किए जाएंगे.

नेटवर्क के अनुरोध का डेटा, उम्मीद के मुताबिक एग्रीगेट नहीं हो रहा है

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

कस्टम यूआरएल पैटर्न भी आज़माए जा सकते हैं!

प्रोजेक्ट के होम पेज पर मौजूद परफ़ॉर्मेंस कार्ड में, 'सबसे बड़ी समस्याएं' सेक्शन का क्या हुआ?

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

परफ़ॉर्मेंस कार्ड में सबसे ऊपर मौजूद ऐप्लिकेशन सिलेक्टर, हाल ही की सूचनाएं सेक्शन में मौजूद सूचनाओं को फ़िल्टर करता है. चुने गए ऐप्लिकेशन के लिए, सिर्फ़ तीन सबसे हाल की सूचनाएं दिखती हैं.

सूचनाओं के बारे में ज़्यादा जानने के लिए, परफ़ॉर्मेंस की समस्याओं के लिए सूचनाएं सेट अप करना लेख पढ़ें.

कंसोल में समस्याओं के लिए थ्रेशोल्ड सेट करने की सुविधा का क्या हुआ?

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

Firebase कंसोल में मौजूद जानकारी और मेट्रिक का क्या हुआ?

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

मुझे सैंपल की संख्या उम्मीद के मुताबिक क्यों नहीं दिख रही है?

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

हम जो डेटा इकट्ठा करते हैं उसकी मात्रा को मैनेज करने के लिए, Performance Monitoring सैंपलिंग के इन विकल्पों का इस्तेमाल करता है:

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

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

  जिन प्रोजेक्ट में BigQuery इंटिग्रेशन की सुविधा चालू है उन्हें नेटवर्क रिक्वेस्ट ट्रेस की संख्या के लिए ज़्यादा सीमा मिलती है.

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

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

  • ट्रेस की संख्या, कोड के किसी हिस्से को लागू किए जाने की संख्या से अलग हो सकती है.
  • कोड में एक-दूसरे से जुड़े हुए ट्रेस में, सैंपल की संख्या अलग-अलग हो सकती है.

Console में समस्याएं टैब का क्या हुआ?

हमने 'समस्याएं' टैब को हटाकर, 'सूचनाएं' टैब जोड़ा है. इससे आपको सेट किए गए थ्रेशोल्ड के पार होने पर, अपने-आप सूचना मिलती है. थ्रेशोल्ड की स्थिति जानने के लिए, अब आपको Firebase कंसोल को मैन्युअल तरीके से देखने की ज़रूरत नहीं है. सूचनाओं के बारे में जानने के लिए, परफ़ॉर्मेंस से जुड़ी समस्याओं के लिए सूचनाएं सेट अप करना लेख पढ़ें.

Console में डिवाइस पर और नेटवर्क टैब का क्या हुआ? मैं उन पेजों पर मौजूद ट्रेस कैसे देखूं?

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

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

ट्रेस टेबल के इन सब-टैब में अपने ट्रेस देखें:

• नेटवर्क रिक्वेस्ट ट्रेस (आउट-ऑफ़-द-बॉक्स और कस्टम, दोनों) — नेटवर्क के अनुरोध सब-टैब
• कस्टम कोड ट्रेस — कस्टम ट्रेस सब-टैब
• ऐप्लिकेशन शुरू होने, फ़ोरग्राउंड में ऐप्लिकेशन, और बैकग्राउंड में ऐप्लिकेशन के ट्रेस — कस्टम ट्रेस सब-टैब
• स्क्रीन रेंडरिंग ट्रेस — स्क्रीन रेंडरिंग सब-टैब
• पेज लोड ट्रेस — पेज लोड सब-टैब

ट्रेस टेबल और मेट्रिक और डेटा देखने के बारे में ज़्यादा जानने के लिए, कंसोल की खास जानकारी वाले पेज (iOS+ | Android | वेब) पर जाएं.

रेंडर होने में ज़्यादा समय लेने वाले और फ़्रीज़ हुए फ़्रेम की संख्या, मेरी उम्मीद के मुताबिक क्यों नहीं है?

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

मुझे फ़्रैगमेंट ट्रेस क्यों नहीं दिख रहे हैं?

ऐप्लिकेशन की गतिविधि के साथ-साथ फ़्रैगमेंट की परफ़ॉर्मेंस देखने के लिए, पक्का करें कि आपका ऐप्लिकेशन Performance Monitoring Android SDK टूल के 20.1.0 या इसके बाद के वर्शन का इस्तेमाल कर रहा हो. ज़्यादा जानने के लिए, अपने ऐप्लिकेशन में परफ़ॉर्मेंस मॉनिटरिंग जोड़ें लेख पढ़ें.

मुझे कैसे पता चलेगा कि कौनसे ट्रेस, फ़्रैगमेंट और गतिविधियों से जुड़े हैं?

हर फ़्रैगमेंट और गतिविधि ट्रेस, आपके ऐप्लिकेशन में तय किए गए क्लास के नाम पर आधारित होता है. हर स्क्रीन ट्रेस में, क्लास के नाम से पहले st प्रीफ़िक्स होता है. Firebase कंसोल पर, प्रीफ़िक्स को हटा दिया जाता है. ज़्यादा जानने के लिए, स्क्रीन रेंडरिंग की परफ़ॉर्मेंस के डेटा (Apple और Android ऐप्लिकेशन) के बारे में जानें लेख पढ़ें.

मुझे अन्य ट्रेस की तुलना में कम फ़्रैगमेंट ट्रेस क्यों दिख रहे हैं?

Performance Monitoring, किसी डिवाइस पर इकट्ठा किए गए सभी इवेंट के लिए, इवेंट सैंपलिंग करता है. इस तरीके से, हमें उपयोगकर्ता के डिवाइसों से कम से कम इवेंट इकट्ठा करने की ज़रूरत पड़ती है, ताकि परफ़ॉर्मेंस मेट्रिक उपलब्ध कराई जा सकें.

मेरे ऐप्लिकेशन की रेंडरिंग परफ़ॉर्मेंस में कोई समस्या होने पर, मुझे इसकी सूचना कैसे मिलती है?

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

Performance Monitoring Gradle प्लगिन को चालू करने के बाद, मेरे बिल्ड टाइम ज़्यादा हैं. मैं इसे कैसे बेहतर बनाऊं?

Android के लिए Performance Monitoring, बाइट कोड इंस्ट्रुमेंटेशन का इस्तेमाल करता है. इससे, एचटीटीपी/एचटीटीपीएस नेटवर्क अनुरोधों को मॉनिटर करने जैसी कुछ बेहतरीन सुविधाएं मिलती हैं. कंपाइलेशन के हिस्से के तौर पर, इस प्रोसेस में आपके ऐप्लिकेशन की सभी क्लास (इनमें डिपेंडेंसी भी शामिल हैं) को बार-बार दोहराना ज़रूरी है. इससे उस कोड को इंस्ट्रुमेंट किया जा सकता है जो आपके ऐप्लिकेशन के नेटवर्क अनुरोध की परफ़ॉर्मेंस को मेज़र करने के लिए ज़रूरी है.

बिल्ड टाइम बढ़ने की कुछ मुख्य वजहें यहां दी गई हैं:

• क्लास या फ़ाइलों की संख्या
• इनमें से हर क्लास का साइज़ (कोड की लाइनें)
• आपकी मशीन का कॉन्फ़िगरेशन
• शुरुआती बिल्ड बनाम बाद का बिल्ड (बाद के बिल्ड आम तौर पर शुरुआती बिल्ड की तुलना में तेज़ी से काम करते हैं)

बिल्ड टाइम को ऑप्टिमाइज़ करने के लिए, अपने कोड को मॉड्यूलर बनाएं.

Performance Monitoring प्लग इन के v1.3.3 से, हमने इंक्रीमेंटल बिल्ड प्रोसेसिंग और लाइब्रेरी इनपुट की कैश मेमोरी को बेहतर बनाने पर ध्यान दिया है. बिल्ड टाइम में हाल ही में किए गए सुधारों का फ़ायदा पाने के लिए, प्लग इन के नए वर्शन (v2.0.2) का इस्तेमाल करें.

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

अगर मुझे Performance Monitoring Gradle प्लग इन के साथ काम न करने वाली लाइब्रेरी की वजह से, बिल्ड से जुड़ी गड़बड़ियां मिलती हैं, तो मुझे क्या करना चाहिए?

Android के लिए Performance Monitoring, बाइट कोड इंस्ट्रुमेंटेशन का इस्तेमाल करता है. इससे, एचटीटीपी/एचटीटीपीएस नेटवर्क अनुरोधों को मॉनिटर करने जैसी कुछ बेहतरीन सुविधाएं मिलती हैं. कंपाइलेशन के हिस्से के तौर पर, इस प्रोसेस में आपके ऐप्लिकेशन की सभी क्लास (इनमें डिपेंडेंसी भी शामिल हैं) को बार-बार दोहराना ज़रूरी है. इससे उस कोड को इंस्ट्रुमेंट किया जा सकता है जो आपके ऐप्लिकेशन के नेटवर्क अनुरोध की परफ़ॉर्मेंस को मेज़र करने के लिए ज़रूरी है.

अगर आपको Performance Monitoring प्लग इन के साथ इंटिग्रेट करने के बाद, JSR/RET are not supported with computeFrames option जैसी गड़बड़ियां मिलती हैं, तो इसकी वजह यह हो सकती है कि आप किसी ऐसी लाइब्रेरी पर भी निर्भर हैं जो Performance Monitoring Gradle प्लग इन के साथ काम नहीं करती.

इस समस्या से बचने के लिए, काम न करने वाली क्लास/लाइब्रेरी को इंस्ट्रुमेंट होने से रोका जा सकता है. इसके लिए, यह तरीका अपनाएं:

1. Performance Monitoring Gradle प्लगिन को नए वर्शन पर अपडेट करें. इसके लिए, कम से कम v1.4.0 होना चाहिए.
2. अपने Android Gradle प्लगिन के वर्शन को v7.2.0 या इसके बाद के वर्शन पर अपडेट करें.
3. अपने मॉड्यूल (ऐप्लिकेशन-लेवल) की build.gradle फ़ाइल में यह फ़्लैग जोड़ें, ताकि काम न करने वाली क्लास/लाइब्रेरी को इंस्ट्रुमेंट न किया जाए:

   android {
     // ...
     androidComponents {
       onVariants(selector().all(), {
           instrumentation.excludes.add("example.incompatible.library")
       })
     }
   }

   Android Gradle प्लगिन के Instrumentation एपीआई की exclude प्रॉपर्टी के बारे में ज़्यादा जानने के लिए, इंस्ट्रुमेंटेशन देखें.

अगर आपको लाइब्रेरी के साथ काम न करने की वजह से, बिल्ड से जुड़ी गड़बड़ियां मिलती हैं, तो कृपया GitHub पर समस्या की शिकायत करें, ताकि उन्हें Performance Monitoring प्लगिन में इंस्ट्रुमेंट करने से भी रोका जा सके.

मुझे Performance Monitoring के डेटा को BigQuery में एक्सपोर्ट करने में, उम्मीद से ज़्यादा समय लग रहा है. क्या यह रीयल टाइम में नहीं है?

अगर आपने Firebase Performance Monitoring के लिए BigQuery इंटिग्रेशन चालू किया है, तो आपका डेटा पैसिफ़िक समय के मुताबिक, दिन खत्म होने के 12 से 24 घंटे बाद BigQuery में एक्सपोर्ट हो जाएगा.

उदाहरण के लिए, 19 अप्रैल का डेटा, BigQuery में 20 अप्रैल को दोपहर 12:00 बजे से आधी रात के बीच उपलब्ध होगा. सभी तारीखें और समय, पैसिफ़िक टाइम के हिसाब से हैं.

कितने कस्टम यूआरएल पैटर्न बनाए जा सकते हैं?

हर ऐप्लिकेशन के लिए, ज़्यादा से ज़्यादा 400 कस्टम यूआरएल पैटर्न बनाए जा सकते हैं. साथ ही, उस ऐप्लिकेशन के हर डोमेन के लिए, ज़्यादा से ज़्यादा 100 कस्टम यूआरएल पैटर्न बनाए जा सकते हैं.

"करीब-करीब रीयल-टाइम" परफ़ॉर्मेंस डेटा का क्या मतलब है?

Firebase Performance Monitoring, इकट्ठा किए गए परफ़ॉर्मेंस डेटा को प्रोसेस करता है. इससे Firebase कंसोल में करीब-करीब रीयल-टाइम डेटा दिखता है. प्रोसेस किया गया डेटा, इकट्ठा होने के कुछ ही मिनटों में कंसोल में दिखने लगता है. इसलिए, इसे "करीब-करीब रीयल-टाइम" कहा जाता है.

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

मुझे अपने ऐप्लिकेशन के लिए, करीब-करीब रीयल-टाइम में परफ़ॉर्मेंस डेटा कैसे मिलेगा?

रीयल-टाइम के आस-पास डेटा प्रोसेसिंग की सुविधा का फ़ायदा पाने के लिए, आपको सिर्फ़ यह पक्का करना होगा कि आपका ऐप्लिकेशन, Performance Monitoring SDK टूल के ऐसे वर्शन का इस्तेमाल करता हो जो रीयल-टाइम डेटा प्रोसेसिंग के साथ काम करता हो.

SDK टूल के ये वर्शन, रीयल-टाइम में काम करते हैं:

• iOS — v7.3.0 या इसके बाद का वर्शन
• tvOS — v8.9.0 या इसके बाद का वर्शन
• Android — v19.0.10 या इसके बाद का वर्शन (या Firebase Android BoM v26.1.0 या इसके बाद का वर्शन)
• वेब — v7.14.0 या इसके बाद का वर्शन

ध्यान दें कि हम हमेशा SDK टूल के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन का इस्तेमाल करने पर, Performance Monitoring आपके डेटा को रीयल टाइम के आस-पास प्रोसेस कर पाएगा.

Performance Monitoring SDK के किन वर्शन को रीयल-टाइम के साथ काम करने वाला माना जाता है?

SDK टूल के ये वर्शन, रीयल-टाइम डेटा प्रोसेसिंग के साथ काम करते हैं:

• iOS — v7.3.0 या इसके बाद का वर्शन
• tvOS — v8.9.0 या इसके बाद का वर्शन
• Android — v19.0.10 या इसके बाद का वर्शन (या Firebase Android BoM v26.1.0 या इसके बाद का वर्शन)
• वेब — v7.14.0 या इसके बाद का वर्शन

ध्यान दें कि हम हमेशा SDK टूल के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन का इस्तेमाल करने पर, Performance Monitoring आपके डेटा को रीयल टाइम के आस-पास प्रोसेस कर पाएगा.

अगर मैं अपने ऐप्लिकेशन को रीयल-टाइम में काम करने वाले एसडीके वर्शन पर अपडेट न करूं, तो क्या होगा?

अगर आपका ऐप्लिकेशन, रीयल-टाइम में काम करने वाले एसडीके वर्शन का इस्तेमाल नहीं करता है, तो भी आपको Firebase कंसोल में अपने ऐप्लिकेशन की परफ़ॉर्मेंस का पूरा डेटा दिखेगा. हालांकि, परफ़ॉर्मेंस डेटा इकट्ठा होने के करीब 36 घंटे बाद ही दिखेगा.

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

हां! ऐप्लिकेशन का कोई इंस्टेंस, SDK टूल के किसी भी वर्शन का इस्तेमाल करता हो, आपको अपने सभी उपयोगकर्ताओं का परफ़ॉर्मेंस डेटा दिखेगा.

हालांकि, अगर आपको हाल ही का डेटा (करीब 36 घंटे से कम पुराना) देखना है, तो दिखाया गया डेटा, रीयल-टाइम के साथ काम करने वाले एसडीके वर्शन का इस्तेमाल करने वाले ऐप्लिकेशन इंस्टेंस के उपयोगकर्ताओं का होता है. हालांकि, पुराने डेटा में आपके ऐप्लिकेशन के सभी वर्शन का परफ़ॉर्मेंस डेटा शामिल होता है.

मुझे परफ़ॉर्मेंस डेटा रीयल टाइम में क्यों नहीं दिख रहा है?

रीयल टाइम परफ़ॉर्मेंस डेटा देखने के लिए, पक्का करें कि आपका ऐप्लिकेशन Performance Monitoring SDK टूल के ऐसे वर्शन का इस्तेमाल करता हो जो रीयल टाइम डेटा प्रोसेसिंग के साथ काम करता हो.

• iOS — v7.3.0 या इसके बाद का वर्शन
• tvOS — v8.9.0 या इसके बाद का वर्शन
• Android — v19.0.10 या इसके बाद का वर्शन (या Firebase Android BoM v26.1.0 या इसके बाद का वर्शन)
• वेब — v7.14.0 या इसके बाद का वर्शन

ध्यान दें कि हम हमेशा SDK टूल के नए वर्शन का इस्तेमाल करने का सुझाव देते हैं. हालांकि, ऊपर दिए गए किसी भी वर्शन का इस्तेमाल करने पर, Performance Monitoring आपके डेटा को रीयल टाइम के आस-पास प्रोसेस कर पाएगा.