| प्लैटफ़ॉर्म चुनें: | iOS+ Android Flutter Unity |
किसी समस्या के बारे में ज़्यादा जानकारी पाने के लिए, DevOps & Engagement > Crashlytics डैशबोर्ड में जाकर, इवेंट की ज़्यादा जानकारी वाली रिपोर्ट देखी जा सकती है.Firebase इन रिपोर्ट को अपनी ज़रूरत के हिसाब से बनाया जा सकता है. इससे आपको यह बेहतर ढंग से समझने में मदद मिलती है कि आपके ऐप्लिकेशन में क्या हो रहा है और इवेंट किन वजहों से हुए जिनकी रिपोर्ट Crashlytics को दी गई है.
अपने ऐप्लिकेशन को इंस्ट्रूमेंट करें, ताकि कस्टम पासकोड, कस्टम लॉग मैसेज, और यूज़र आइडेंटिफ़ायर लॉग किए जा सकें.
अपवादों को Crashlytics को रिपोर्ट करें.
अगर आपका ऐप्लिकेशन, Firebase SDK टूल का इस्तेमाल करता है, तो आपको ब्रेडक्रंब लॉग अपने-आप मिल जाएंगे Google Analytics. इन लॉग से आपको यह पता चलता है कि आपके ऐप्लिकेशन में, Crashlytics से इकट्ठा किए गए इवेंट से पहले, उपयोगकर्ताओं ने कौनसी कार्रवाइयां की थीं.
ऐप्लिकेशन के क्रैश होने की रिपोर्ट अपने-आप जनरेट होने की सुविधा बंद करें और उपयोगकर्ताओं के लिए, ऑप्ट-इन रिपोर्टिंग की सुविधा चालू करें. ध्यान दें कि डिफ़ॉल्ट रूप से, Crashlytics आपके ऐप्लिकेशन के सभी उपयोगकर्ताओं के लिए, क्रैश रिपोर्ट अपने-आप इकट्ठा करता है.
कस्टम पासकोड जोड़ना
कस्टम पासकोड की मदद से, आपको यह पता चलता है कि ऐप्लिकेशन के क्रैश होने से पहले उसकी स्थिति क्या थी. क्रैश रिपोर्ट के साथ, की-वैल्यू पेयर जोड़े जा सकते हैं. इसके बाद, क्रैश रिपोर्ट को खोजने और फ़िल्टर करने के लिए, कस्टम पासकोड का इस्तेमाल किया जा सकता है. यह Firebase कंसोल के DevOps & Engagement > Crashlytics डैशबोर्ड में उपलब्ध है. Firebase
कस्टम पासकोड से मेल खाने वाली समस्याओं को खोजा जा सकता है.
कंसोल में किसी समस्या की समीक्षा करते समय, हर इवेंट के लिए उससे जुड़े कस्टम पासकोड देखे जा सकते हैं. इसके लिए, Keys सबटैब पर जाएं. साथ ही, पेज में सबसे ऊपर मौजूद फ़िल्टर मेन्यू में जाकर, इवेंट को कस्टम पासकोड के हिसाब से फ़िल्टर भी किया जा सकता है.
की-वैल्यू पेयर सेट करने के लिए, setCustomValue तरीके का इस्तेमाल करें. उदाहरण के लिए:
Swift
// Set int_key to 100. Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key") // Set str_key to "hello". Crashlytics.crashlytics().setCustomValue("hello", forKey: "str_key")
Objective-C
इंटीजर, बूलियन या फ़्लोट सेट करते समय, वैल्यू को @(value) के तौर पर बॉक्स करें.
// Set int_key to 100. [[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"]; // Set str_key to "hello". [[FIRCrashlytics crashlytics] setCustomValue:@"hello" forKey:@"str_key"];
मौजूदा पासकोड की वैल्यू में भी बदलाव किया जा सकता है. इसके लिए, पासकोड को कॉल करें और उसकी वैल्यू को किसी दूसरी वैल्यू पर सेट करें. उदाहरण के लिए:
Swift
Crashlytics.crashlytics().setCustomValue(100, forKey: "int_key") // Set int_key to 50 from 100. Crashlytics.crashlytics().setCustomValue(50, forKey: "int_key")
Objective-C
[[FIRCrashlytics crashlytics] setCustomValue:@(100) forKey:@"int_key"]; // Set int_key to 50 from 100. [[FIRCrashlytics crashlytics] setCustomValue:@(50) forKey:@"int_key"];
एक साथ कई की-वैल्यू पेयर जोड़ने के लिए, setCustomKeysAndValues तरीके का इस्तेमाल करें. इसमें, NSDictionary को सिर्फ़ एक पैरामीटर के तौर पर इस्तेमाल किया जाता है:
Swift
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)
Objective-C
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 लॉग को क्रैश डेटा से जोड़ता है और किसी समस्या की जानकारी देखते समय, उन्हें Logs टैब में दिखाता है. Firebase कंसोल के DevOps & Engagement > Crashlytics डैशबोर्ड में जाकर, सभी समस्याएं देखी जा सकती हैं.
CrashlyticsSwift
समस्याओं का पता लगाने के लिए, log() या log(format:, arguments:) का इस्तेमाल करें. अगर आपको मैसेज के साथ काम का लॉग आउटपुट चाहिए, तो
log() को पास किया गया ऑब्जेक्ट,
CustomStringConvertible
प्रॉपर्टी के मुताबिक होना चाहिए. log() , ऑब्जेक्ट के लिए तय की गई ब्यौरा प्रॉपर्टी दिखाता है. उदाहरण के लिए:
Crashlytics.crashlytics().log("Higgs-Boson detected! Bailing out…, \(attributesDict)")
.log(format:, arguments:) , getVaList() को कॉल करने पर मिलने वाली वैल्यू को फ़ॉर्मैट करता है. उदाहरण के लिए:
Crashlytics.crashlytics().log(format: "%@, %@", arguments: getVaList(["Higgs-Boson detected! Bailing out…", attributesDict]))
log() या log(format:, arguments:) का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, Crashlytics
रेफ़रंस दस्तावेज़ देखें.
Objective-C
समस्याओं का पता लगाने के लिए, log या logWithFormat का इस्तेमाल करें. ध्यान दें कि अगर आपको मैसेज के साथ काम का लॉग आउटपुट चाहिए, तो किसी भी तरीके को पास किया गया ऑब्जेक्ट, description इंस्टेंस प्रॉपर्टी को बदलता है.
उदाहरण के लिए:
[[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];
log और logWithFormat का इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, Crashlytics रेफ़रंस दस्तावेज़ देखें.
यूज़र आइडेंटिफ़ायर सेट करना
किसी समस्या की पहचान करने के लिए, यह जानना अक्सर मददगार होता है कि आपके किन उपयोगकर्ताओं को कोई क्रैश हुआ. Crashlytics में, क्रैश रिपोर्ट में उपयोगकर्ताओं की पहचान गुमनाम तरीके से करने की सुविधा शामिल है.
अपनी रिपोर्ट में यूज़र आईडी जोड़ने के लिए, हर उपयोगकर्ता को आईडी नंबर, टोकन या हैश की गई वैल्यू के तौर पर एक यूनीक आइडेंटिफ़ायर असाइन करें:
Swift
Crashlytics.crashlytics().setUserID("123456789")
Objective-C
[[FIRCrashlytics crashlytics] setUserID:@"123456789"];
अगर आपको यूज़र आइडेंटिफ़ायर सेट करने के बाद उसे मिटाना है, तो वैल्यू को खाली स्ट्रिंग पर रीसेट करें. यूज़र आइडेंटिफ़ायर मिटाने से, मौजूदा Crashlytics रिकॉर्ड नहीं हटते. अगर आपको किसी यूज़र आईडी से जुड़े रिकॉर्ड मिटाने हैं, तो Firebase की सहायता टीम से संपर्क करें.
ऐसी गड़बड़ियों की रिपोर्ट करना जो ऐप्लिकेशन को बंद नहीं करतीं
Crashlytics, आपके ऐप्लिकेशन के क्रैश होने की रिपोर्ट अपने-आप जनरेट करने के अलावा, Crashlytics ऐसी गड़बड़ियों को भी रिकॉर्ड करता है जो ऐप्लिकेशन को बंद नहीं करतीं. साथ ही, अगली बार ऐप्लिकेशन लॉन्च होने पर, ये रिपोर्ट आपको भेजता है.
NSError ऑब्जेक्ट को recordError तरीके से रिकॉर्ड करके, ऐसी गड़बड़ियों को रिकॉर्ड किया जा सकता है जो ऐप्लिकेशन को बंद नहीं करतीं. recordError , [NSThread callStackReturnAddresses] को कॉल करके, थ्रेड के कॉल स्टैक को कैप्चर करता है.
Swift
Crashlytics.crashlytics().record(error: error)
Objective-C
[[FIRCrashlytics crashlytics] recordError:error];
recordError तरीके का इस्तेमाल करते समय, NSError
स्ट्रक्चर और Crashlytics क्रैश को ग्रुप करने के लिए डेटा का इस्तेमाल कैसे करता है, यह समझना ज़रूरी है. recordError तरीके का गलत
इस्तेमाल करने से, अनचाहे नतीजे मिल सकते हैं. साथ ही, ऐसा हो सकता है कि Crashlytics आपके ऐप्लिकेशन के लिए लॉग की गई गड़बड़ियों की रिपोर्टिंग को सीमित कर दे.
किसी NSError ऑब्जेक्ट में तीन तर्क होते हैं:
domain: Stringcode: IntuserInfo: [AnyHashable : Any]? = nil
ऐप्लिकेशन के क्रैश होने की रिपोर्ट को स्टैक ट्रेस के विश्लेषण के ज़रिए ग्रुप किया जाता है. वहीं, लॉग की गई गड़बड़ियों
को domain और code के हिसाब से ग्रुप किया जाता है. ऐप्लिकेशन के क्रैश होने की रिपोर्ट और लॉग की गई गड़बड़ियों में यह एक अहम अंतर है. उदाहरण के लिए:
Swift
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)
Objective-C
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 स्टैक अनवाइंडिंग नाम की
प्रोसेस का इस्तेमाल करके, मौजूदा थ्रेड के कॉल स्टैक को कैप्चर करता है. यह प्रोसेस, सीपीयू और आई/ओ इंटेंसिव हो सकती है. खास तौर पर, उन आर्किटेक्चर पर जो DWARF अनवाइंडिंग (arm64 और x86) को सपोर्ट करते हैं.
अनवाइंडिंग पूरी होने के बाद, जानकारी को डिस्क पर सिंक्रोनस तरीके से लिखा जाता है.
इससे, अगर अगली लाइन क्रैश होती है, तो डेटा का नुकसान नहीं होता.
बैकग्राउंड थ्रेड पर इस एपीआई को कॉल करना सुरक्षित है. हालांकि, ध्यान रखें कि इस कॉल को किसी दूसरी क्यू में भेजने से, मौजूदा स्टैक ट्रेस का संदर्भ खत्म हो जाता है.
NSExceptions के बारे में क्या?
Crashlytics सीधे NSException
इंस्टेंस को लॉग और रिकॉर्ड करने की सुविधा नहीं देता. आम तौर पर, Cocoa और Cocoa Touch API, अपवादों से सुरक्षित नहीं होते. इसका मतलब है कि @catch का इस्तेमाल करने से, आपकी प्रोसेस में अनचाहे साइड इफ़ेक्ट हो सकते हैं. भले ही, इसका इस्तेमाल बहुत सावधानी से किया गया हो. आपको अपने कोड में @catch स्टेटमेंट का इस्तेमाल कभी नहीं करना चाहिए. इस विषय पर
Apple का दस्तावेज़
देखें.
स्टैक ट्रेस को पसंद के मुताबिक बनाना
अगर आपका ऐप्लिकेशन, C++ या Unity जैसे नॉन-नेटिव एनवायरमेंट में चलता है, तो Exception Model API का इस्तेमाल करके, अपने ऐप्लिकेशन के नेटिव अपवाद फ़ॉर्मैट में क्रैश मेटाडेटा की रिपोर्ट की जा सकती है. रिपोर्ट किए गए अपवादों को, ऐसी गड़बड़ियों के तौर पर मार्क किया जाता है जो ऐप्लिकेशन को बंद नहीं करतीं.
Swift
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)
Objective-C
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];
कस्टम स्टैक फ़्रेम को सिर्फ़ पतों से भी शुरू किया जा सकता है:
Swift
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)
Objective-C
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 टूल जोड़ना होगा. इन ज़रूरी शर्तों को पूरा करने के बाद, किसी समस्या की जानकारी देखते समय, Logs टैब में, इवेंट के डेटा के साथ ब्रेडक्रंब लॉग अपने-आप शामिल हो जाते हैं. Firebase कंसोल के DevOps & Engagement > Crashlytics dashboard में जाकर, सभी समस्याएं देखी जा सकती हैं.Google AnalyticsFirebase
Analytics SDK
अपने-आप screen_view इवेंट को लॉग करता है
. इससे ब्रेडक्रंब लॉग में, ऐप्लिकेशन के क्रैश होने, ऐसी गड़बड़ी होने जो ऐप्लिकेशन को बंद नहीं करती या ANR इवेंट से पहले देखी गई स्क्रीन की सूची दिखती है.
screen_view ब्रेडक्रंब लॉग में, firebase_screen_class पैरामीटर होता है.
ब्रेडक्रंब लॉग में, उपयोगकर्ता के सेशन में मैन्युअल तरीके से लॉग किए गए सभी कस्टम इवेंट भी शामिल होते हैं. इनमें, इवेंट का पैरामीटर डेटा भी शामिल होता है. इस डेटा से, ऐप्लिकेशन के क्रैश होने, ऐसी गड़बड़ी होने जो ऐप्लिकेशन को बंद नहीं करती या ANR इवेंट से पहले, उपयोगकर्ता की कार्रवाइयों की सीरीज़ दिखाई जा सकती है.
ध्यान दें कि डेटा को इकट्ठा करने और इस्तेमाल करने की प्रोसेस को कंट्रोल किया जा सकता हैGoogle Analytics. इसमें, ब्रेडक्रंब लॉग में दिखने वाला डेटा भी शामिल है .
ऑप्ट-इन रिपोर्टिंग की सुविधा चालू करना
डिफ़ॉल्ट रूप से, Crashlytics आपके ऐप्लिकेशन के सभी उपयोगकर्ताओं के लिए, क्रैश रिपोर्ट अपने-आप इकट्ठा करता है. उपयोगकर्ताओं को उनके भेजे गए डेटा पर ज़्यादा कंट्रोल देने के लिए, रिपोर्टिंग की सुविधा अपने-आप चालू होने की सुविधा बंद करके, ऑप्ट-इन रिपोर्टिंग की सुविधा चालू की जा सकती है. साथ ही, अपने कोड में तय करने पर ही, Crashlytics को डेटा भेजा जा सकता है.
Info.plistफ़ाइल में एक नया पासकोड जोड़कर, डेटा इकट्ठा करने की सुविधा अपने-आप चालू होने की सुविधा बंद करें:- पासकोड:
FirebaseCrashlyticsCollectionEnabled - वैल्यू:
false
- पासकोड:
रनटाइम में, 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 में एक्सपोर्ट करें, ताकि ज़्यादा बेहतर विश्लेषण और सुविधाएं मिल सकें. जैसे, अपने डेटा के लिए क्वेरी करना, कस्टम डैशबोर्ड बनाना, और कस्टम अलर्ट सेट अप करना.