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

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

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 कंसोल में अपना डेटा देखने के लिए, यूआरएल पर क्लिक करें. डैशबोर्ड में डेटा अपडेट होने में कुछ समय लग सकता है.

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

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

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

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

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

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

अगर "SDK का पता चला" मैसेज दिखने के 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. पक्का करें कि इनमें से किसी भी फ़्लैग के ज़रिए, प्लगिन को बंद न किया गया हो:

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

2. जांच करें कि आपकी AndroidManifest.xml फ़ाइल में मौजूद इन फ़्लैग में से किसी एक के ज़रिए, Performance Monitoring एसडीके को बंद न किया गया हो:

   • firebase_performance_collection_enabled
   • firebase_performance_collection_deactivated

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

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

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

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

1. पक्का करें कि Android SDK के सबसे नए वर्शन (v22.0.6) का इस्तेमाल किया जा रहा हो. स्क्रीन रेंडरिंग के ट्रेस, सिर्फ़ 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
      • firebasePerformanceInstrumentationEnabled को अपनी gradle.properties फ़ाइल में जोड़ना

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

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

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

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

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

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

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

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

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

2. देखें कि नेटवर्क लाइब्रेरी, आपके डिवाइस के साथ काम करती है या नहीं. Performance Monitoring इन नेटवर्किंग लाइब्रेरी का इस्तेमाल करने वाले नेटवर्क अनुरोधों के लिए, मेट्रिक अपने-आप इकट्ठा करता है: OkHttp 3.x.x, Java's 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 सर्वर-साइड सैंपलिंग का इस्तेमाल कर सकता है. इससे डिवाइसों से मिले कुछ इवेंट को ड्रॉप किया जा सकता है. हालांकि, इस तरह की सीमा तय करने से हमारी मेट्रिक की परफ़ॉर्मेंस पर कोई असर नहीं पड़ता. हालांकि, इससे पैटर्न में मामूली बदलाव हो सकते हैं. इनमें ये शामिल हैं:

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

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

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

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

हमने 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 प्रॉपर्टी के बारे में ज़्यादा जानने के लिए, इंस्ट्रुमेंटेशन देखें.

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

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

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

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

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

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

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

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

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

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

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

ये ऐसे SDK वर्शन हैं जो रीयल-टाइम में काम करते हैं:

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

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

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

रीयल-टाइम में डेटा प्रोसेस करने की सुविधा के साथ काम करने वाले एसडीके के वर्शन ये हैं:

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

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

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

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

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

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

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

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

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

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

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