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

iOS+ Android Flutter Unity

इस पेज पर, समस्या हल करने में मदद मिलती है. साथ ही, Crashlytics के इस्तेमाल के बारे में अक्सर पूछे जाने वाले सवालों के जवाब भी मिलते हैं. अगर आपको अपनी ज़रूरत के हिसाब से जानकारी नहीं मिल पा रही है या आपको और मदद चाहिए, तो Firebase की सहायता टीम से संपर्क करें.

समस्या हल करने के सामान्य तरीके/अक्सर पूछे जाने वाले सवाल

समस्याएं टेबल में, कुछ समस्याओं के लिए अलग-अलग फ़ॉर्मैट (और कभी-कभी "वैरिएंट") दिखना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्रैश-फ़्री मेट्रिक और/या वेग से जुड़ी सूचनाएं न दिखना

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

ब्रेडक्रंब लॉग न दिखना

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

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

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

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

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

Crashlytics डैशबोर्ड में, Android ऐप्लिकेशन के लिए बिना सिंबल वाले स्टैक ट्रेस देखना

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

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

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

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

क्या Crashlytics का इस्तेमाल, IL2CPP का इस्तेमाल करने वाले ऐप्लिकेशन के साथ किया जा सकता है?

हां, 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 Analytics से मिलती हैं.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• जब कोई क्रैश होता है, तो Google Analytics एक app_exception इवेंट टाइप भेजता है. साथ ही, CRASHED_USERS उस इवेंट टाइप से जुड़े उपयोगकर्ताओं की संख्या दिखाता है.

• ALL_USERS, उस समयावधि के दौरान आपके ऐप्लिकेशन से जुड़ने वाले उपयोगकर्ताओं की कुल संख्या दिखाता है जिसे आपने Crashlytics डैशबोर्ड के सबसे ऊपर दाईं ओर मौजूद ड्रॉप-डाउन मेन्यू से चुना है.

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

क्रैश का अनुभव न करने वाले उपयोगकर्ताओं का प्रतिशत, समय के साथ इकट्ठा होने वाला डेटा होता है, न कि औसत.

उदाहरण के लिए, मान लें कि आपके ऐप्लिकेशन के तीन उपयोगकर्ता हैं. हम उन्हें उपयोगकर्ता A, उपयोगकर्ता B, और उपयोगकर्ता C कहेंगे. नीचे दी गई टेबल से पता चलता है कि हर दिन आपके ऐप्लिकेशन का इस्तेमाल करने वाले कौनसे उपयोगकर्ता थे और उनमें से किन उपयोगकर्ताओं के ऐप्लिकेशन में उस दिन क्रैश हुआ था:

	सोमवार	मंगलवार	बुधवार
आपके ऐप्लिकेशन से जुड़ने वाले उपयोगकर्ता	A, B, C	A, B, C	A, B
जिस उपयोगकर्ता के डिवाइस पर ऐप्लिकेशन क्रैश हुआ	C	B	A

• बुधवार को, आपके ऐप्लिकेशन क्रैश होने की समस्या का सामना न करने वाले उपयोगकर्ताओं का प्रतिशत 50% है (दो में से एक उपयोगकर्ता को ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं करना पड़ा).
  बुधवार को आपके ऐप्लिकेशन का इस्तेमाल करने वाले दो उपयोगकर्ताओं में से, सिर्फ़ एक उपयोगकर्ता (उपयोगकर्ता B) के डिवाइस पर ऐप्लिकेशन क्रैश नहीं हुआ.

• पिछले दो दिनों में, आपके ऐप्लिकेशन के बिना क्रैश हुए काम करने वाले उपयोगकर्ताओं का प्रतिशत 33.3% है. इसका मतलब है कि तीन में से एक उपयोगकर्ता को ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं करना पड़ा.
  आपके तीन उपयोगकर्ताओं ने पिछले दो दिनों में आपके ऐप्लिकेशन का इस्तेमाल किया. हालांकि, उनमें से सिर्फ़ एक उपयोगकर्ता (उपयोगकर्ता C) के ऐप्लिकेशन में कोई क्रैश नहीं हुआ.

• पिछले तीन दिनों में, आपके ऐप्लिकेशन के क्रैश न होने वाले उपयोगकर्ताओं का प्रतिशत 0% है. इसका मतलब है कि तीन में से कोई भी उपयोगकर्ता आपके ऐप्लिकेशन के क्रैश होने की समस्या से नहीं जुड़ा था.
  पिछले तीन दिनों में, आपके तीन उपयोगकर्ता आपके ऐप्लिकेशन से जुड़े, लेकिन उनमें से किसी के ऐप्लिकेशन क्रैश नहीं हुआ.

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

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

किसी समस्या के बारे में नोट कौन देख सकता है, कौन लिख सकता है, और कौन मिटा सकता है?

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

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

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

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

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

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

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

उन उपयोगकर्ताओं का हिसाब कैसे लगाया जाता है जिन्हें क्रैश का अनुभव नहीं हुआ?

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

किसी समस्या के बारे में नोट कौन देख सकता है, कौन लिख सकता है, और कौन मिटा सकता है?

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

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

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

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

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

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

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

इंटिग्रेशन

ऐप्लिकेशन में Google Mobile Ads SDK टूल का भी इस्तेमाल किया जाता है, लेकिन ऐप्लिकेशन क्रैश नहीं हो रहा

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

मेरा BigQuery डेटासेट कहां मौजूद है?

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

बेहतर होने के बजाय खराब हुई परफ़ॉर्मेंस से जुड़ी समस्याएं

पहले से मौजूद समस्या का मतलब क्या है?

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

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

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

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics किसी समस्या को तब रिग्रेशन के तौर पर कैटगरी में रखता था, जब वह समस्या ऐप्लिकेशन के किसी भी वर्शन में फिर से दिखती थी. यहां तक कि उन ऐप्लिकेशन वर्शन के लिए भी, जिनके बारे में हमें समस्या को ठीक करने के दौरान पता था. इस वजह से, कभी-कभी Crashlytics गलत तरीके से रेग्रेशन की पहचान करता है. अब हम ऊपर बताए गए कॉन्वेंशन का इस्तेमाल करते हैं.

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

मुझे ऐप्लिकेशन के पुराने वर्शन में, पहले से मौजूद समस्याएं क्यों दिख रही हैं?

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

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

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

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics किसी समस्या को रिग्रेशन के तौर पर तब कैटगरी में रखता था, जब वह समस्या ऐप्लिकेशन के किसी वर्शन में फिर से दिखती थी. भले ही, वह समस्या ठीक करने के बाद भी ऐप्लिकेशन के उन वर्शन में दिखती हो जिनके बारे में हमें पता था. इस वजह से, Crashlytics कभी-कभी गलत तरीके से रेग्रेशन की पहचान की जाती थी. अब हम ऊपर बताए गए कॉन्वेंशन का इस्तेमाल करते हैं.

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

गड़बड़ी को ठीक न कर पाने पर, उसे गंभीर गड़बड़ी के तौर पर रिपोर्ट करना

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

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

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

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

अहम जानकारी: बिना पकड़े गए अपवादों को फ़ैटल के तौर पर रिपोर्ट करने से, Android की ज़रूरी जानकारी पर कोई असर नहीं पड़ता. 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 Diagnostics को रिपोर्ट किया जाए.

ध्यान दें कि अगर आपको 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
    //
}