Firebase Crashlytics — यह क्या है, क्रैश और त्रुटि निदान

Firebase Crashlytics क्या है

Firebase Crashlytics मोबाइल एप्लिकेशन स्थिरता की निगरानी के लिए Google की एक मुफ्त सेवा है, जिसे Google ने 2017 में Fabric कंपनी के साथ अधिग्रहित किया था। Crashlytics स्वचालित रूप से प्रत्येक एप्लिकेशन क्रैश के बारे में जानकारी एकत्र करता है, समान क्रैश को स्टैक हस्ताक्षर द्वारा समूहित करता है, और उन्हें Firebase कंसोल में प्रभावित उपयोगकर्ताओं की संख्या के अनुसार प्राथमिकता के साथ प्रदर्शित करता है।

इतिहास और विकास

Crashlytics 2011 में Fabric प्लेटफ़ॉर्म के भाग के रूप में लॉन्च किया गया था और जल्दी ही iOS में क्रैश रिपोर्टिंग के लिए डी-फैक्टो मानक बन गया। 2017 में Google द्वारा अनुमानित 2 बिलियन डॉलर (पूरे Fabric) में अधिग्रहण के बाद, Crashlytics को Firebase SDK में एकीकृत किया गया। संस्करण 18.0.0 (2021) ने Kotlin Multiplatform समर्थन जोड़ा, और संस्करण 19.0.0 (2024) ने बिना अतिरिक्त कॉन्फ़िगरेशन के Android पर स्वचालित ANR संग्रह शुरू किया। Google (2026) के अनुसार, Crashlytics मासिक रूप से 10 बिलियन से अधिक क्रैश संसाधित करता है।

Crashlytics की मुफ्त सीमाएँ

Crashlytics प्रति Firebase प्रोजेक्ट प्रति दिन 500 हज़ार सत्रों की सीमा के साथ मुफ्त प्रदान किया जाता है। यह अधिकांश एप्लिकेशन के लिए पर्याप्त है — Google (2026) के अनुसार, 95% प्रोजेक्ट सीमा से अधिक नहीं होते। सीमा पार होने पर, डेटा संग्रह बंद नहीं होता, लेकिन रिपोर्ट अगले दिन तक अपडेट होना बंद कर देती हैं। उच्च ट्रैफ़िक वाले प्रोजेक्ट के लिए, Firebase के Spark और Blaze टैरिफ उपलब्ध हैं — Crashlytics दोनों टैरिफ पर मुफ्त रहता है, और सत्र सीमा अलग से गिनी जाती है।

Crashlytics क्रैश का पता कैसे लगाता है और एकत्र करता है

Crashlytics का संग्रह तंत्र प्लेटफ़ॉर्म और रनटाइम स्तर पर अपवादों को इंटरसेप्ट करने पर आधारित है। Android पर, SDK एक UncaughtExceptionHandler स्थापित करता है जो सभी अनहैंडल्ड Kotlin और Java अपवादों को पकड़ता है। iOS पर, Crashlytics Objective-C/Swift के लिए NSSetUncaughtExceptionHandler और नेटिव कोड क्रैश के लिए अपने स्वयं के Mach अपवाद हैंडलर का उपयोग करता है।

इंटरसेप्ट किए गए क्रैश के प्रकार

Crashlytics पाँच प्रकार के क्रैश को अलग करता है: fatal (घातक क्रैश), non-fatal (मैन्युअल रूप से पास किए गए गैर-घातक अपवाद), ANR (Android — एप्लिकेशन प्रतिक्रिया नहीं दे रहा), signal (OS सिग्नल — SIGSEGV, SIGABRT) और OOM (iOS पर मेमोरी खत्म)। प्रत्येक प्रकार को एक अलग तंत्र द्वारा संभाला जाता है और संबंधित लेबल के साथ कंसोल में प्रदर्शित किया जाता है।

क्रैश रिपोर्ट प्रारूप

प्रत्येक Crashlytics रिपोर्ट में व्यापक जानकारी होती है: क्लास नाम और लाइन नंबर के साथ पूर्ण स्टैक ट्रेस, एप्लिकेशन संस्करण (versionName + versionCode), डिवाइस मॉडल, OS संस्करण, खाली मेमोरी, स्क्रीन ओरिएंटेशन और लॉन्च के बाद का समय। यदि Firebase Analytics कनेक्टेड है, तो रिपोर्ट में क्रैश से पहले अंतिम 50 उपयोगकर्ता ईवेंट का पथ भी शामिल होता है — यह क्रैश पुनरुत्पादन के लिए महत्वपूर्ण है।

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Android प्रोजेक्ट में Crashlytics का एकीकरण

Android एप्लिकेशन में Crashlytics कनेक्ट करने के लिए build.gradle में दो निर्भरताएँ जोड़ने और Google Services प्लगइन कॉन्फ़िगर करने की आवश्यकता होती है। SDK बिना अतिरिक्त कोड के Firebase आरंभीकरण पर स्वचालित रूप से क्रैश रिपोर्टिंग सक्षम करता है। सही संचालन के लिए, google-services प्लगइन और Firebase कंसोल से google-services.json फ़ाइल भी आवश्यक है।

// build.gradle (प्रोजेक्ट-स्तर)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (एप्लिकेशन-स्तर)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Crashlytics प्लगइन कॉन्फ़िगरेशन

com.google.firebase.crashlytics प्लगइन दो कार्य करता है: अस्पष्ट स्टैक के मैपिंग के लिए एक अद्वितीय बिल्ड आईडी (build ID) उत्पन्न करता है और Crashlytics SDK के लिए स्वचालित रूप से संसाधन बनाता है। प्लगइन के बिना, क्रैश को "unmapped" के रूप में चिह्नित किया जाएगा — आप केवल अस्पष्ट क्लास नाम (a.b.c) देखेंगे, स्रोत कोड खोजने में असमर्थ रहेंगे। प्लगइन रूट build.gradle और एप्लिकेशन मॉड्यूल के build.gradle में जोड़ा जाता है।

एकीकरण सत्यापन

Crashlytics एकीकरण के परीक्षण के लिए विशेष विधि forceCrash() का उपयोग किया जाता है, जो एक परीक्षण अपवाद उत्पन्न करती है। यह विधि प्रोडक्शन बिल्ड में उपलब्ध नहीं है। परीक्षण क्रैश चलाने के बाद, रिपोर्ट 1-5 मिनट के भीतर Firebase कंसोल में दिखाई देती है। यदि रिपोर्ट दिखाई नहीं देती है, तो जाँचें कि google-services.json एप्लिकेशन पैकेज से मेल खाता है और AndroidManifest में डेटा संग्रह अक्षम करने वाले कोई फ़्लैग नहीं हैं।

क्रैश विश्लेषण और रिपोर्ट समूहीकरण

Crashlytics कंसोल देखने के दो स्तर प्रदान करता है: क्रैश प्रकार के अनुसार समूहित सभी क्रैश (Issues) की सूची, और ट्रेस, सांख्यिकी और कस्टम डेटा के साथ प्रत्येक Issue की विस्तृत रिपोर्ट। प्रत्येक Issue समान हस्ताक्षर वाले सभी क्रैश को जोड़ता है — समान अपवाद प्रकार और मेल खाता स्टैक ट्रेस।

Issues और समूहीकरण

क्रैश समूहीकरण Crashlytics की एक प्रमुख विशेषता है। हजारों अलग-अलग क्रैश दिखाने के बजाय, सेवा उन्हें फिंगरप्रिंट के आधार पर Issues में जोड़ती है — स्टैक ट्रेस का एक चेकसम। एक Issue में 1 से लेकर कई मिलियन क्रैश हो सकते हैं। प्रत्येक Issue प्रदर्शित करता है: घातक घटनाओं की संख्या, अद्वितीय उपयोगकर्ताओं की संख्या, एप्लिकेशन संस्करण जिसमें क्रैश दिखाई दिया, और समस्या का सामना करने वाले उपयोगकर्ताओं का प्रतिशत।

Google (2026) के अनुसार, औसतन 20% Issues सभी घातक एप्लिकेशन क्रैश का 80% (पेरेटो सिद्धांत) बनाते हैं। Crashlytics स्वचालित रूप से Issues को गंभीरता के अनुसार क्रमबद्ध करता है — जितने अधिक उपयोगकर्ता प्रभावित होंगे, प्राथमिकता उतनी ही अधिक होगी। यह डेवलपर को पहले सबसे व्यापक समस्याओं को ठीक करने की अनुमति देता है।

संस्करण आँकड़े

Crashlytics प्रत्येक एप्लिकेशन संस्करण की स्थिरता को अलग से ट्रैक करता है। क्रैश-मुक्त उपयोगकर्ताओं का ग्राफ़ प्रत्येक संस्करण में घातक क्रैश का सामना न करने वाले उपयोगकर्ताओं का प्रतिशत दिखाता है। यदि अपडेट पर प्रतिशत एक सीमा (डिफ़ॉल्ट 99%) से नीचे गिर जाता है, तो Crashlytics ईमेल और Firebase कंसोल में सूचना भेजता है। यह समस्याग्रस्त संस्करण को जल्दी से वापस लेने या हॉटफिक्स जारी करने की अनुमति देता है।

कस्टम कुंजियाँ, लॉग और Breadcrumbs

Crashlytics रिपोर्ट को संदर्भ से समृद्ध करने के लिए तीन तंत्र प्रदान करता है: संरचित डेटा के लिए कस्टम कुंजियाँ (keys), टेक्स्ट ट्रेसिंग के लिए लॉग (logs), और उपयोगकर्ता पथ के लिए Analytics से Breadcrumbs। तीनों प्रकार के डेटा क्रैश रिपोर्ट से जुड़े होते हैं और इसके विवरण कार्ड में दिखाई देते हैं।

कस्टम कुंजियाँ

Custom Keys कुंजी-मूल्य जोड़े हैं जो प्रत्येक क्रैश के साथ भेजे जाते हैं। अधिकतम 64 कुंजियाँ प्रति एप्लिकेशन, प्रत्येक कुंजी 1024 वर्णों तक की स्ट्रिंग। कुंजियाँ एप्लिकेशन स्थिति को लेबल करने के लिए उपयोगी हैं: सब्सक्रिप्शन स्तर, प्राधिकरण स्थिति, अंतिम स्क्रीन, VPN सक्षम है या नहीं। मान ओवरराइट हो जाते हैं — उसी नाम वाली नई कुंजी पुरानी को बदल देती है।

ईवेंट लॉगिंग

Custom Logs टेक्स्ट संदेश हैं जिन्हें Crashlytics 64 KB के रिंग बफर में संग्रहीत करता है। लॉग स्वचालित रूप से अगले क्रैश से जुड़ जाते हैं। यदि कोई क्रैश नहीं होता है, तो लॉग सर्वर पर नहीं भेजे जाते (ट्रैफ़िक खर्च नहीं करते)। लॉगिंग का उपयोग क्रैश से पहले उपयोगकर्ता कदमों को रिकॉर्ड करने के लिए किया जाता है: "payment_processing_started", "api_call_initiated", "response_received_200"।

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Analytics से Breadcrumbs

यदि प्रोजेक्ट में Firebase Analytics कनेक्टेड है, तो Crashlytics स्वचालित रूप से Breadcrumbs प्राप्त करता है — क्रैश से पहले अंतिम 50 analytics ईवेंट। प्रत्येक breadcrumb में ईवेंट का नाम और उसके पैरामीटर होते हैं। यह क्रैश का कारण बनने वाले कार्यों के सटीक अनुक्रम को पुनर्स्थापित करने की अनुमति देता है: उपयोगकर्ता ने स्क्रीन खोली → उत्पाद जोड़ा → भुगतान पर गया → क्रैश हुआ। Breadcrumbs Issue कार्ड में एक अलग "Logs" टैब पर प्रदर्शित होते हैं।

क्रैश के साथ काम करने के सर्वोत्तम अभ्यास

Crashlytics सबसे प्रभावी होता है जब संदर्भ और Issue प्रसंस्करण प्रक्रिया सही ढंग से कॉन्फ़िगर की गई हो। अभ्यास से पता चलता है कि जिन टीमों ने क्रैश प्रबंधन कार्यप्रवाह लागू किया है, वे महत्वपूर्ण बग फिक्सिंग समय को 60% तक कम कर देती हैं (Google डेटा, 2026)।

Issue प्राथमिकता निर्धारण

सभी क्रैश समान रूप से महत्वपूर्ण नहीं होते। उपयोगकर्ता संख्या और आवृत्ति के अनुसार प्राथमिकता निर्धारण सबसे महत्वपूर्ण समस्याओं पर ध्यान केंद्रित करने में मदद करता है। सामान्य नियम: 24 घंटों के भीतर 0.1% से अधिक उपयोगकर्ताओं को प्रभावित करने वाले Issues को ठीक करें। एकल घटनाओं वाले Issues (< 0.01%) को अगले नियोजित रिलीज़ तक स्थगित किया जा सकता है। Crashlytics स्वचालित रूप से प्रतिगमन को चिह्नित करता है — ऐसे Issues जो ठीक हो गए थे लेकिन नए संस्करण में फिर से दिखाई दिए।

CI/CD के साथ एकीकरण

Crashlytics API REST API या Firebase CLI के माध्यम से CI/CD पाइपलाइन में क्रैश रिपोर्ट को एकीकृत करने की अनुमति देता है। प्रत्येक नए रिलीज़ के साथ, आप स्वचालित रूप से जाँच सकते हैं कि क्रैश-मुक्त उपयोगकर्ताओं का प्रतिशत एक सीमा से अधिक है या नहीं। यदि सीमा पार हो जाती है, तो CI/CD रोलआउट को ब्लॉक कर देता है और टीम को सूचना भेजता है। Firebase CLI ProGuard/R8 मैपिंग फ़ाइलें अपलोड करने के लिए firebase crashlytics:builds:upload कमांड का समर्थन करता है — उनके बिना स्टैक अपठनीय होंगे।

Google (2026) के अनुसार, CI/CD में स्वचालित क्रैश-मुक्त सीमा जाँच का उपयोग करने वाले एप्लिकेशन प्रोडक्शन में 40% कम प्रतिगमन जारी करते हैं। अनुशंसित सीमा: महत्वपूर्ण रिलीज़ के लिए क्रैश-मुक्त उपयोगकर्ता >= 99.5% और सामान्य रिलीज़ के लिए >= 99.0%।