Crashlytics से जुड़ी समस्या हल करने और अक्सर पूछे जाने वाले सवाल

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

साल 2023 की शुरुआत में, हमने इवेंट को ग्रुप करने के लिए बेहतर विश्लेषण इंजन के साथ-साथ, अपडेट किया गया डिज़ाइन और नई समस्याओं (जैसे, वैरिएंट!) के लिए कुछ बेहतर सुविधाएं लॉन्च की थीं. पूरी जानकारी के लिए, हमारी हाल ही की ब्लॉग पोस्ट पढ़ें. हालांकि, हाइलाइट के बारे में जानने के लिए, यहां पढ़ें.

Crashlytics आपके ऐप्लिकेशन के सभी इवेंट (जैसे, क्रैश, गैर-फ़ैटल, और ANR) का विश्लेषण करता है. साथ ही, इवेंट के ग्रुप बनाता है, जिन्हें समस्याएं कहा जाता है. किसी समस्या में मौजूद सभी इवेंट में एक ही तरह की गड़बड़ी होती है.

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

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

इन सुधारों के बाद, आपको ये सुविधाएं मिलेंगी:

• समस्या वाली लाइन में दिखाया गया बेहतर मेटाडेटा
  अब आपके ऐप्लिकेशन में समस्याओं को समझना और उन्हें प्राथमिकता के आधार पर ठीक करना आसान हो गया है.

• डुप्लीकेट समस्याएं कम होती हैं
  लाइन नंबर में बदलाव करने से कोई नई समस्या नहीं होती.

• अलग-अलग वजहों से होने वाली मुश्किल समस्याओं को आसानी से डीबग करना
  किसी समस्या में सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करें.

• ज़्यादा काम की चेतावनियां और सिग्नल
  नई समस्या का मतलब है कि कोई नया बग है.

• ज़्यादा असरदार खोज
  हर समस्या में, खोजे जा सकने वाले ज़्यादा मेटाडेटा होते हैं. जैसे, अपवाद का टाइप और पैकेज का नाम.

ये सुधार इस तरह रोल आउट किए जा रहे हैं:

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

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

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

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

• आपने अपने Firebase प्रोजेक्ट में, Google Analytics को चालू किया हो.

• आपने Google Analytics के लिए, डेटा शेयर करने की सुविधा चालू की है. Analytics में डेटा शेयर करने की सेटिंग मैनेज करना में जाकर, इस सेटिंग के बारे में ज़्यादा जानें

• आपने अपने ऐप्लिकेशन में, Google Analytics के लिए Firebase SDK टूल जोड़ा है . इस SDK टूल को Crashlytics SDK टूल के साथ जोड़ना ज़रूरी है.

• आपने अपने ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए, Firebase SDK टूल के नए वर्शन इस्तेमाल किए हैं.

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

अगर आपको क्रैश-फ़्री मेट्रिक (जैसे, क्रैश-फ़्री उपयोगकर्ता और सेशन) नहीं दिख रही हैं या अविश्वसनीय मेट्रिक दिख रही हैं, तो ये देखें:

• पक्का करें कि आपने Crashlytics SDK टूल के 11.7.0 या इसके बाद के वर्शन का इस्तेमाल किया हो.

• पक्का करें कि डेटा इकट्ठा करने की सेटिंग, क्रैश-फ़्री मेट्रिक की क्वालिटी पर असर न डाल रही हों:

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

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

क्रैश-फ़्री मेट्रिक को समझना लेख पढ़ें.

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

1. पक्का करें कि आपके पास Crashlytics Unity SDK टूल का 8.6.1 या इसके बाद का वर्शन हो.

2. पक्का करें कि आपने अपनी सिंबल फ़ाइल जनरेट और अपलोड करने के लिए, Firebase सीएलआई crashlytics:symbols:upload कमांड को सेट अप किया हो और उसे चलाया जा रहा हो.

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

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

1. पक्का करें कि आपके पास Crashlytics Unity SDK टूल का v8.6.0 या इसके बाद का वर्शन हो.

2. अपने प्लैटफ़ॉर्म के लिए ज़रूरी टास्क पूरे करें:

   • Apple प्लैटफ़ॉर्म के ऐप्लिकेशन के लिए: आपको कुछ करने की ज़रूरत नहीं है. Apple के प्लैटफ़ॉर्म पर काम करने वाले ऐप्लिकेशन के लिए, Firebase Unity Editor प्लग इन आपके Xcode प्रोजेक्ट को सिंबल अपलोड करने के लिए अपने-आप कॉन्फ़िगर करता है.

   • Android ऐप्लिकेशन के लिए: पक्का करें कि आपने अपनी सिम्बल फ़ाइल जनरेट और अपलोड करने के लिए, Firebase सीएलआई crashlytics:symbols:upload कमांड को सेट अप किया हो और उसे चलाया जा रहा हो.

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

नोट की मदद से, प्रोजेक्ट के सदस्य किसी खास समस्या के बारे में सवाल पूछ सकते हैं, स्टेटस के बारे में अपडेट दे सकते हैं वगैरह.

जब कोई प्रोजेक्ट में शामिल व्यक्ति कोई नोट पोस्ट करता है, तो उसे उसके Google खाते के ईमेल पते से लेबल किया जाता है. यह ईमेल पता, नोट के साथ उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस है.

यहां बताया गया है कि नोट देखने, लिखने, और मिटाने के लिए, किस तरह का ऐक्सेस ज़रूरी है:

• प्रोजेक्ट के जिन सदस्यों के पास इनमें से कोई भी भूमिका है वे मौजूदा नोट देख सकते हैं और उन्हें मिटा सकते हैं. साथ ही, किसी समस्या के बारे में नए नोट लिख सकते हैं.

  • प्रोजेक्ट का मालिक या एडिटर, Firebase एडमिन, क्वालिटी एडमिन या Crashlytics एडमिन

• प्रोजेक्ट के जिन सदस्यों के पास इनमें से कोई भूमिका है वे किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे नोट को मिटा या लिख नहीं सकते.

  • प्रोजेक्ट व्यूअर, Firebase व्यूअर, क्वालिटी व्यूअर या Crashlytics व्यूअर

अगर आपका प्रोजेक्ट Google Mobile Ads SDK टूल के साथ-साथ Crashlytics का इस्तेमाल करता है, तो हो सकता है कि अपवाद हैंडलर को रजिस्टर करते समय, क्रैश रिपोर्टर रुकावट डाल रहे हों. इस समस्या को ठीक करने के लिए, disableSDKCrashReporting को कॉल करके Mobile Ads SDK टूल में क्रैश रिपोर्टिंग की सुविधा बंद करें.

Crashlytics को BigQuery से लिंक करने के बाद, आपके बनाए गए नए डेटासेट अपने-आप अमेरिका में सेव हो जाते हैं. भले ही, आपके Firebase प्रोजेक्ट की लोकेशन कुछ भी हो.

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

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि Crashlytics किसी समस्या को रिग्रेशन के तौर पर कैसे कैटगरी में बांटता है:

1. Crashlytics को पहली बार, क्रैश "A" के बारे में क्रैश रिपोर्ट मिलती है. Crashlytics उस क्रैश से जुड़ी समस्या (समस्या "A") खोलता है.
2. आपने इस गड़बड़ी को तुरंत ठीक कर दिया, "A" समस्या को बंद कर दिया, और फिर अपने ऐप्लिकेशन का नया वर्शन रिलीज़ कर दिया.
3. समस्या को बंद करने के बाद, Crashlytics को "A" समस्या के बारे में एक और शिकायत मिलती है.
   • अगर रिपोर्ट किसी ऐसे ऐप्लिकेशन वर्शन से है जिसके बारे में Crashlytics को पहले से पता था, तो Crashlytics उस समस्या को फिर से होने वाली समस्या के तौर पर नहीं लेगा. इसका मतलब है कि उस वर्शन ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी. समस्या बंद रहेगी.
   • अगर रिपोर्ट किसी ऐसे ऐप्लिकेशन वर्शन से मिली है जिसके बारे में Crashlytics नहीं जानता था, तो Crashlytics यह मान लेगा कि समस्या फिर से आ गई है और वह समस्या को फिर से खोल देगा.

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

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

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

अगर आपको हमारे रेग्रेशन एल्गोरिदम की वजह से, किसी समस्या को फिर से खोलना नहीं है, तो उसे बंद करने के बजाय "म्यूट" करें.

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

ध्यान दें कि फ़ैटल क्रैश की रिपोर्टिंग शुरू करने पर, आपके ऐप्लिकेशन के बिना क्रैश हुए काम करने वाले उपयोगकर्ताओं (सीएफ़यू) का प्रतिशत कम हो सकता है. हालांकि, सीएफ़यू मेट्रिक से आपके ऐप्लिकेशन के असली उपयोगकर्ताओं के अनुभव के बारे में ज़्यादा जानकारी मिलेगी.

Crashlytics को किसी ऐसे अपवाद की शिकायत, फ़ैटल के तौर पर करने के लिए, इन दोनों शर्तों को पूरा करना ज़रूरी है:

• आपके ऐप्लिकेशन में शुरू करने के दौरान, ReportUncaughtExceptionsAsFatal प्रॉपर्टी को true पर सेट किया जाना चाहिए.

• आपका ऐप्लिकेशन (या इसमें शामिल लाइब्रेरी) कोई ऐसा अपवाद दिखाती है जिसे पकड़ा नहीं जाता. किसी अपवाद को न फेंकने पर भी उसे अनकच नहीं माना जाता.

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

• सोचें कि इन अपवादों को कैसे पकड़ा और मैनेज किया जा सकता है.
• Unity डीबग कंसोल और Crashlytics में अपवादों को लॉग करने के लिए, अलग-अलग विकल्पों पर विचार करें.

थ्रो किए गए अपवादों को कैच और हैंडल करना

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

हमारा सुझाव है कि पहले से पता चलने वाले सभी अपवादों को तब तक पकड़ें और मैनेज करें, जब तक प्रोग्राम को पहले जैसी स्थिति में नहीं लाया जा सकता.

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

Unity या Crashlytics में अपवादों को लॉग करना

समस्या को डीबग करने में मदद पाने के लिए, Unity या Crashlytics में अपवाद रिकॉर्ड करने के कई तरीके हैं.

Crashlytics का इस्तेमाल करते समय, यहां दिए गए दो सबसे सामान्य और सुझाए गए विकल्प इस्तेमाल किए जा सकते हैं:

• पहला विकल्प: Unity कंसोल में प्रिंट करें, लेकिन डेवलपमेंट या समस्या हल करने के दौरान Crashlytics को रिपोर्ट न करें

  • Debug.Log(exception), Debug.LogWarning(exception), और Debug.LogError(exception) का इस्तेमाल करके, Unity कंसोल पर प्रिंट करें. ये एक्सप्शन के कॉन्टेंट को Unity कंसोल पर प्रिंट करते हैं और एक्सप्शन को फिर से नहीं दिखाते.

• दूसरा विकल्प: Crashlytics डैशबोर्ड में एक साथ कई रिपोर्ट देखने के लिए, Crashlytics पर अपलोड करें. ऐसा इन स्थितियों में करें:

  • अगर किसी अपवाद को लॉग करना ज़रूरी है, ताकि आने वाले समय में होने वाले संभावित Crashlytics इवेंट को डीबग किया जा सके, तो Crashlytics.Log(exception.ToString()) का इस्तेमाल करें.
  • अगर किसी अपवाद को पकड़ने और मैनेज करने के बावजूद, Crashlytics को उसकी शिकायत करनी है, तो उसे गैर-घातक इवेंट के तौर पर लॉग करने के लिए Crashlytics.LogException(exception) का इस्तेमाल करें.

हालांकि, अगर आपको Unity Cloud Diagnostic में मैन्युअल तरीके से किसी गंभीर इवेंट की शिकायत करनी है, तो Debug.LogException का इस्तेमाल करें. यह विकल्प, पहले विकल्प की तरह ही Unity कंसोल पर अपवाद को प्रिंट करता है. हालांकि, यह अपवाद भी दिखाता है, भले ही इसे अभी तक दिखाया गया हो या नहीं. यह गड़बड़ी, स्थानीय तौर पर नहीं दिखती. इसका मतलब है कि try-catch ब्लॉक के साथ Debug.LogException(exception) के आस-पास होने पर भी, अपवाद नहीं पकड़ा जाता.

इसलिए, Debug.LogException को सिर्फ़ तब कॉल करें, जब आपको इनमें से सभी काम करने हों:

• Unity कंसोल में अपवाद को प्रिंट करने के लिए.
• अपवाद को Crashlytics में, गंभीर इवेंट के तौर पर अपलोड करने के लिए.
• अपवाद को फेंकने के लिए, इसे पहचाना नहीं गया अपवाद के तौर पर माना जाए और इसे Unity Cloud डाइग्नोस्टिक्स को रिपोर्ट किया जाए.

ध्यान दें कि अगर आपको Unity कंसोल में किसी अपवाद को प्रिंट करना है और Crashlytics पर गैर-घातक इवेंट के तौर पर अपलोड करना है, तो इसके बजाय यह तरीका अपनाएं:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}