Apple प्लैटफ़ॉर्म के लिए क्रैश रिपोर्ट को पसंद के मुताबिक बनाना

किसी समस्या के बारे में ज़्यादा जानकारी पाने के लिए, DevOps & Engagement > Crashlytics डैशबोर्ड में जाकर, इवेंट की ज़्यादा जानकारी वाली रिपोर्ट देखी जा सकती है.Firebase इन रिपोर्ट को अपनी ज़रूरत के हिसाब से बनाया जा सकता है. इससे आपको यह बेहतर ढंग से समझने में मदद मिलती है कि आपके ऐप्लिकेशन में क्या हो रहा है और इवेंट किन वजहों से हुए जिनकी रिपोर्ट Crashlytics को दी गई है.

• अपने ऐप्लिकेशन को इंस्ट्रूमेंट करें, ताकि कस्टम पासकोड, कस्टम लॉग मैसेज, और यूज़र आइडेंटिफ़ायर लॉग किए जा सकें.

• अपवादों को Crashlytics को रिपोर्ट करें.

• अगर आपका ऐप्लिकेशन, Firebase SDK टूल का इस्तेमाल करता है, तो ब्रेडक्रंब लॉग अपने-आप मिल जाते हैं.Google Analytics इन लॉग से आपको यह पता चलता है कि आपके ऐप्लिकेशन में, Crashlytics से इकट्ठा किए गए इवेंट से पहले, उपयोगकर्ताओं ने कौनसी कार्रवाइयां की थीं.

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

कस्टम पासकोड जोड़ना

कस्टम पासकोड की मदद से, ऐप्लिकेशन बंद होने से पहले की खास स्थिति के बारे में पता चलता है. ऐप्लिकेशन बंद होने की रिपोर्ट के साथ, अपनी पसंद के की-वैल्यू पेयर जोड़े जा सकते हैं. इसके बाद, ऐप्लिकेशन बंद होने की रिपोर्ट को खोजने और फ़िल्टर करने के लिए, कस्टम पासकोड का इस्तेमाल किया जा सकता है. DevOps & Engagement > Crashlytics डैशबोर्ड में, Firebase कंसोल का इस्तेमाल किया जा सकता है.

• कस्टम पासकोड से मेल खाने वाली समस्याओं को खोजा जा सकता है.

• कंसोल में किसी समस्या की समीक्षा करते समय, हर इवेंट के लिए उससे जुड़े कस्टम पासकोड देखे जा सकते हैं. इसके लिए, पासकोड सबटैब पर जाएं. इसके अलावा, पेज में सबसे ऊपर मौजूद फ़िल्टर मेन्यू में जाकर, इवेंट को कस्टम पासकोड के हिसाब से फ़िल्टर भी किया जा सकता है.

की-वैल्यू पेयर सेट करने के लिए, setCustomValue तरीके का इस्तेमाल करें. उदाहरण के लिए:

// Set int_key to 100.
Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

// Set str_key to "hello".
Crashlytics.crashlytics().setCustomValue("hello", forKey: "str_key")

// Set int_key to 100.
[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

// Set str_key to "hello".
[[FIRCrashlytics crashlytics] setCustomValue:@"hello" forKey:@"str_key"];

मौजूदा पासकोड की वैल्यू में भी बदलाव किया जा सकता है. इसके लिए, पासकोड को कॉल करें और उसे किसी दूसरी वैल्यू पर सेट करें. उदाहरण के लिए:

Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key")

// Set int_key to 50 from 100.
Crashlytics.crashlytics().setCustomValue(50, forKey: "int_key")

[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"];

// Set int_key to 50 from 100.
[[FIRCrashlytics crashlytics] setCustomValue:@(50) forKey:@"int_key"];

एक साथ कई की-वैल्यू पेयर जोड़ने के लिए, setCustomKeysAndValues तरीके का इस्तेमाल करें. इसमें NSDictionary को सिर्फ़ एक पैरामीटर के तौर पर इस्तेमाल किया जाता है:

let keysAndValues = [
                 "string key" : "string value",
                 "string key 2" : "string value 2",
                 "boolean key" : true,
                 "boolean key 2" : false,
                 "float key" : 1.01,
                 "float key 2" : 2.02
                ] as [String : Any]

Crashlytics.crashlytics().setCustomKeysAndValues(keysAndValues)

NSDictionary *keysAndValues =
    @{@"string key" : @"string value",
      @"string key 2" : @"string value 2",
      @"boolean key" : @(YES),
      @"boolean key 2" : @(NO),
      @"float key" : @(1.01),
      @"float key 2" : @(2.02)};

[[FIRCrashlytics crashlytics] setCustomKeysAndValues: keysAndValues];

कस्टम लॉग मैसेज जोड़ना

ऐप्लिकेशन बंद होने से पहले के इवेंट के बारे में ज़्यादा जानकारी पाने के लिए, अपने ऐप्लिकेशन में कस्टम Crashlytics लॉग जोड़े जा सकते हैं. Crashlytics लॉग को ऐप्लिकेशन बंद होने के डेटा से जोड़ता है और किसी समस्या की जानकारी देखते समय, उन्हें लॉग टैब में दिखाता है. Firebase कंसोल के DevOps & Engagement > Crashlytics डैशबोर्ड में, अपनी सभी समस्याएं देखी जा सकती हैं.

Crashlytics.crashlytics().log("Higgs-Boson detected! Bailing out…, \(attributesDict)")

Crashlytics.crashlytics().log(format: "%@, %@", arguments: getVaList(["Higgs-Boson detected! Bailing out…", attributesDict]))

[[FIRCrashlytics crashlytics] log:@"Simple string message"];

[[FIRCrashlytics crashlytics] logWithFormat:@"Higgs-Boson detected! Bailing out... %@", attributesDict];

[[FIRCrashlytics crashlytics] logWithFormat:@"Logging a variable argument list %@" arguments:va_list_arg];

यूज़र आइडेंटिफ़ायर सेट करना

किसी समस्या की पहचान करने के लिए, यह जानना अक्सर मददगार होता है कि आपके किन उपयोगकर्ताओं को ऐप्लिकेशन बंद होने की समस्या का सामना करना पड़ा. Crashlytics में, ऐप्लिकेशन बंद होने की रिपोर्ट में उपयोगकर्ताओं की पहचान गुमनाम तरीके से की जाती है.

अपनी रिपोर्ट में यूज़र आईडी जोड़ने के लिए, हर उपयोगकर्ता को आईडी नंबर, टोकन या हैश की गई वैल्यू के तौर पर एक यूनीक आइडेंटिफ़ायर असाइन करें:

Crashlytics.crashlytics().setUserID("123456789")

[[FIRCrashlytics crashlytics] setUserID:@"123456789"];

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

ऐप्लिकेशन बंद न होने की वजह से होने वाली गड़बड़ियों की रिपोर्ट करना

Crashlytics, आपके ऐप्लिकेशन के बंद होने की रिपोर्ट अपने-आप करता है. इसके अलावा, यह Crashlytics ऐप्लिकेशन बंद न होने की वजह से होने वाली गड़बड़ियों को भी रिकॉर्ड करता है और अगली बार ऐप्लिकेशन लॉन्च होने पर, आपको उनकी रिपोर्ट भेजता है.

ऐप्लिकेशन बंद न होने की वजह से होने वाली गड़बड़ियों को रिकॉर्ड करने के लिए, recordError तरीके से NSError ऑब्जेक्ट रिकॉर्ड करें. recordError , [NSThread callStackReturnAddresses] को कॉल करके, थ्रेड के कॉल स्टैक को कैप्चर करता है.

Crashlytics.crashlytics().record(error: error)

[[FIRCrashlytics crashlytics] recordError:error];

recordError तरीके का इस्तेमाल करते समय, NSError स्ट्रक्चर और Crashlytics ऐप्लिकेशन बंद होने की वजह से होने वाली गड़बड़ियों को ग्रुप करने के लिए, डेटा का इस्तेमाल कैसे करता है, यह समझना ज़रूरी है. recordError तरीके का गलत इस्तेमाल करने से, अनचाहे नतीजे मिल सकते हैं. साथ ही, ऐसा हो सकता है कि Crashlytics आपके ऐप्लिकेशन के लिए लॉग की गई गड़बड़ियों की रिपोर्टिंग को सीमित कर दे.

किसी NSError ऑब्जेक्ट में तीन तर्क होते हैं:

• domain: String
• code: Int
• userInfo: [AnyHashable : Any]? = nil

ऐप्लिकेशन बंद होने की वजह से होने वाली गड़बड़ियों को स्टैक ट्रेस के विश्लेषण के ज़रिए ग्रुप किया जाता है. वहीं, लॉग की गई गड़बड़ियों को domain और code के हिसाब से ग्रुप किया जाता है. ऐप्लिकेशन बंद होने की वजह से होने वाली गड़बड़ियों और लॉग की गई गड़बड़ियों के बीच यह एक अहम अंतर है. उदाहरण के लिए:

let userInfo = [
  NSLocalizedDescriptionKey: NSLocalizedString("The request failed.", comment: ""),
  NSLocalizedFailureReasonErrorKey: NSLocalizedString("The response returned a 404.", comment: ""),
  NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString("Does this page exist?", comment: ""),
  "ProductID": "123456",
  "View": "MainView"
]

let error = NSError.init(domain: NSCocoaErrorDomain,
                         code: -1001,
                         userInfo: userInfo)

NSDictionary *userInfo = @{
  NSLocalizedDescriptionKey: NSLocalizedString(@"The request failed.", nil),
  NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"The response returned a 404.", nil),
  NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Does this page exist?", nil),
  @"ProductID": @"123456",
  @"View": @"MainView",
};

NSError *error = [NSError errorWithDomain:NSCocoaErrorDomain
                                     code:-1001
                                 userInfo:userInfo];

ऊपर दी गई गड़बड़ी को लॉग करने पर, एक नई समस्या बनती है. इसे NSSomeErrorDomain और -1001 के हिसाब से ग्रुप किया जाता है. एक ही डोमेन और कोड वैल्यू का इस्तेमाल करके लॉग की गई अन्य गड़बड़ियों को भी इसी समस्या के तहत ग्रुप किया जाता है. userInfo ऑब्जेक्ट में मौजूद डेटा को की-वैल्यू पेयर में बदला जाता है और किसी समस्या की जानकारी में, पासकोड/लॉग सेक्शन में दिखाया जाता है.

लॉग और कस्टम पासकोड

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

परफ़ॉर्मेंस से जुड़ी बातें

ध्यान रखें कि NSError लॉग करना काफ़ी महंगा हो सकता है. कॉल करते समय, Crashlytics स्टैक अनवाइंडिंग नाम की प्रोसेस का इस्तेमाल करके, मौजूदा थ्रेड के कॉल स्टैक को कैप्चर करता है. यह प्रोसेस, सीपीयू और I/O के लिए काफ़ी मुश्किल हो सकती है. खास तौर पर, उन आर्किटेक्चर पर जो DWARF अनवाइंडिंग (arm64 और x86) को सपोर्ट करते हैं. अनवाइंडिंग पूरी होने के बाद, जानकारी को डिस्क पर सिंक्रोनस तरीके से लिखा जाता है. इससे, अगर अगली लाइन में कोई गड़बड़ी होती है, तो डेटा का नुकसान नहीं होता.

बैकग्राउंड थ्रेड पर इस एपीआई को कॉल करना सुरक्षित है. हालांकि, ध्यान रखें कि इस कॉल को किसी दूसरी क्यू में भेजने से, मौजूदा स्टैक ट्रेस का कॉन्टेक्स्ट खो जाता है.

NSExceptions के बारे में क्या कहा जा सकता है?

Crashlytics सीधे तौर पर NSException इंस्टेंस को लॉग और रिकॉर्ड करने की सुविधा नहीं देता. आम तौर पर, Cocoa और Cocoa Touch API, अपवादों से सुरक्षित नहीं होते. इसका मतलब है कि @catch का इस्तेमाल करने से, आपकी प्रोसेस में अनचाहे और गंभीर साइड इफ़ेक्ट हो सकते हैं. भले ही, इसका इस्तेमाल बहुत सावधानी से किया गया हो. आपको अपने कोड में @catch स्टेटमेंट का इस्तेमाल कभी नहीं करना चाहिए. इस विषय पर Apple का दस्तावेज़ देखें.

स्टैक ट्रेस को पसंद के मुताबिक बनाना

अगर आपका ऐप्लिकेशन, C++ या Unity जैसे नॉन-नेटिव एनवायरमेंट में चलता है, तो Exception Model API का इस्तेमाल करके, अपने ऐप्लिकेशन के नेटिव अपवाद फ़ॉर्मैट में, ऐप्लिकेशन बंद होने के मेटाडेटा की रिपोर्ट की जा सकती है. रिपोर्ट किए गए अपवादों को, ऐप्लिकेशन बंद न होने की वजह से होने वाली गड़बड़ियों के तौर पर मार्क किया जाता है.

var  ex = ExceptionModel(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame(symbol:"makeError", file:"handler.js", line:495),
  StackFrame(symbol:"then", file:"routes.js", line:102),
  StackFrame(symbol:"main", file:"app.js", line:12),
]

crashlytics.record(exceptionModel:ex)

FIRExceptionModel *model =
    [FIRExceptionModel exceptionModelWithName:@"FooException" reason:@"There was a foo."];
model.stackTrace = @[
  [FIRStackFrame stackFrameWithSymbol:@"makeError" file:@"handler.js" line:495],
  [FIRStackFrame stackFrameWithSymbol:@"then" file:@"routes.js" line:102],
  [FIRStackFrame stackFrameWithSymbol:@"main" file:@"app.js" line:12],
];

[[FIRCrashlytics crashlytics] recordExceptionModel:model];

कस्टम स्टैक फ़्रेम को सिर्फ़ पतों से भी शुरू किया जा सकता है:

var  ex = ExceptionModel.init(name:"FooException", reason:"There was a foo.")
ex.stackTrace = [
  StackFrame(address:0xfa12123),
  StackFrame(address:12412412),
  StackFrame(address:194129124),
]

crashlytics.record(exceptionModel:ex)

FIRExceptionModel *model =
    [FIRExceptionModel exceptionModelWithName:@"FooException" reason:@"There was a foo."];
model.stackTrace = @[
  [FIRStackFrame stackFrameWithAddress:0xfa12123],
  [FIRStackFrame stackFrameWithAddress:12412412],
  [FIRStackFrame stackFrameWithAddress:194129124],
];


[[FIRCrashlytics crashlytics] recordExceptionModel:model];

ब्रेडक्रंब लॉग पाना

ब्रेडक्रंब लॉग से आपको यह बेहतर ढंग से समझने में मदद मिलती है कि ऐप्लिकेशन बंद होने, ऐप्लिकेशन बंद न होने की वजह से होने वाली गड़बड़ी या ANR इवेंट से पहले, उपयोगकर्ता ने आपके ऐप्लिकेशन के साथ कौनसे इंटरैक्शन किए थे. किसी समस्या को फिर से बनाने और उसे डीबग करने की कोशिश करते समय, ये लॉग मददगार हो सकते हैं.

ब्रेडक्रंब लॉग, Google Analytics की मदद से जनरेट होते हैं. इसलिए, ब्रेडक्रंब लॉग पाने के लिए, आपको अपने Firebase प्रोजेक्ट के लिए Google Analytics की सुविधा चालू करनी होगी. साथ ही, अपने ऐप्लिकेशन में Google Analytics के लिए Firebase SDK टूल जोड़ना होगा. ये ज़रूरी शर्तें पूरी होने के बाद, किसी समस्या की जानकारी देखते समय, **लॉग** टैब में, इवेंट के डेटा के साथ ब्रेडक्रंब लॉग अपने-आप शामिल हो जाते हैं. Firebase कंसोल के **DevOps & Engagement** > **Crashlytics** डैशबोर्ड में, अपनी सभी समस्याएं देखी जा सकती हैं.Google AnalyticsCrashlyticsFirebase

Analytics SDK अपने-आप screen_view इवेंट को लॉग करता है. इससे ब्रेडक्रंब लॉग में, ऐप्लिकेशन बंद होने, ऐप्लिकेशन बंद न होने की वजह से होने वाली गड़बड़ी या ANR इवेंट से पहले देखी गई स्क्रीन की सूची दिखती है. screen_view ब्रेडक्रंब लॉग में, firebase_screen_class पैरामीटर शामिल होता है.

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

ध्यान दें कि डेटाGoogle Analytics को इकट्ठा करने और इस्तेमाल करने की प्रोसेस को कंट्रोल किया जा सकता है, इसमें, ब्रेडक्रंब लॉग जनरेट करने वाला डेटा भी शामिल है.

ऑप्ट-इन रिपोर्टिंग की सुविधा चालू करना

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

1. Info.plist फ़ाइल में एक नया पासकोड जोड़कर, डेटा इकट्ठा करने की सुविधा को अपने-आप चालू होने से रोकें:

   • पासकोड: FirebaseCrashlyticsCollectionEnabled
   • वैल्यू: false

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

   Swift

   Crashlytics.crashlytics().setCrashlyticsCollectionEnabled(true)

   Objective-C

   [[FIRCrashlytics crashlytics] setCrashlyticsCollectionEnabled:YES];

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

Crash Insights के डेटा को मैनेज करना

Crash Insights, आपकी गुमनाम स्टैक ट्रेस की तुलना, Firebase के अन्य ऐप्लिकेशन के ट्रेस से करके, समस्याओं को हल करने में आपकी मदद करता है. साथ ही, यह आपको बताता है कि आपकी समस्या, किसी बड़े ट्रेंड का हिस्सा है या नहीं. कई समस्याओं के लिए, Crash Insights, ऐप्लिकेशन बंद होने की वजह से होने वाली गड़बड़ी को डीबग करने में आपकी मदद करने के लिए संसाधन भी उपलब्ध कराता है.

Crash Insights, स्थिरता से जुड़े सामान्य ट्रेंड की पहचान करने के लिए, ऐप्लिकेशन बंद होने के एग्रीगेट किए गए डेटा का इस्तेमाल करता है. अगर आपको अपने ऐप्लिकेशन का डेटा शेयर नहीं करना है, तो Firebase कंसोल के DevOps & Engagement > Crashlytics डैशबोर्ड में, समस्याओं की सूची में सबसे ऊपर मौजूद Crash Insights मेन्यू में जाकर, Crash Insights से ऑप्ट-आउट किया जा सकता है.

अगले चरण

• गहराई से विश्लेषण करने और डेटा को क्वेरी करने, कस्टम डैशबोर्ड बनाने, और कस्टम अलर्ट सेट अप करने जैसी सुविधाओं के लिए, अपने डेटा को BigQuery या Cloud Logging में एक्सपोर्ट करें.