Firebase Crashlytics — یہ کیا ہے، کریش اور خرابیوں کی تشخیص

Firebase Crashlytics کیا ہے

Firebase Crashlytics موبائل ایپلیکیشنز کے استحکام کی نگرانی کے لیے Google کی ایک مفت سروس ہے، جسے Google نے 2017 میں Fabric کمپنی کے ساتھ حاصل کیا تھا۔ Crashlytics ہر ایپلیکیشن کریش کے بارے میں خود بخود معلومات جمع کرتا ہے، ایک جیسے کریشوں کو اسٹیک دستخط کے مطابق گروپ کرتا ہے اور انہیں Firebase کنسول میں متاثرہ صارفین کی تعداد کے مطابق ترجیح دے کر دکھاتا ہے۔

تاریخ اور ارتقاء

Crashlytics 2011 میں Fabric پلیٹ فارم کے حصے کے طور پر لانچ کیا گیا تھا اور iOS پر کریش رپورٹنگ کے لیے فوری طور پر حقیقی معیار بن گیا۔ Google کے ذریعہ 2017 میں تقریباً 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 کس طرح کریشوں کا پتہ لگاتا اور جمع کرتا ہے

اکٹھا کرنے کا طریقہ کار پلیٹ فارم اور runtime کی سطح پر استثنیات کو روکنے پر مبنی ہے۔ 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 کا انضمام

Crashlytics کو Android ایپلیکیشن سے منسلک کرنے کے لیے 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 کے لیے خود بخود وسائل تخلیق کرتا ہے۔ پلگ ان کے بغیر، کریش "غیر میپ شدہ" کے طور پر نشان زد ہوں گے — آپ صرف مبہم کلاس نام (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% بناتے ہیں (Pareto اصول)۔ Crashlytics خود بخود Issues کو شدت کے مطابق ترتیب دیتا ہے — جتنے زیادہ صارفین متاثر ہوں گے، ترجیح اتنی ہی زیادہ ہوگی۔ یہ ڈویلپر کو پہلے سب سے عام مسائل حل کرنے کی اجازت دیتا ہے۔

ورژن کے مطابق اعدادوشمار

Crashlytics ہر ایپلیکیشن ورژن کے استحکام کو علیحدہ سے ٹریک کرتا ہے۔ Crash-free users گراف ہر ورژن میں مہلک کریش کا سامنا نہ کرنے والے صارفین کا فیصد دکھاتا ہے۔ اگر اپ ڈیٹ کے دوران فیصد حد سے نیچے گر جاتا ہے (پہلے سے طے شدہ 99%) تو، Crashlytics ای میل اور Firebase Console کے ذریعے اطلاع بھیجتا ہے۔ یہ مسئلہ والے ورژن کو فوری طور پر واپس لینے یا ہاٹ فکس جاری کرنے کی اجازت دیتا ہے۔

حسب ضرورت کیز، لاگز اور 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 تجزیہ واقعات۔ ہر breadcrumb میں واقعہ کا نام اور اس کے پیرامیٹرز شامل ہوتے ہیں۔ یہ کریش کا باعث بننے والی اعمال کی صحیح ترتیب کو دوبارہ تشکیل دینے کی اجازت دیتا ہے: صارف نے اسکرین کھولی → پروڈکٹ شامل کیا → ادائیگی کی طرف بڑھا → کریش ہوا۔ Breadcrumbs Issue کارڈ میں علیحدہ "لاگز" ٹیب میں دکھائے جاتے ہیں۔

کریشوں کے ساتھ کام کرنے کے بہترین طریقے

Crashlytics سیاق و سباق کی صحیح ترتیب اور Issue پروسیسنگ کے عمل کے ساتھ سب سے زیادہ مؤثر ہے۔ پریکٹس سے پتہ چلتا ہے کہ جن ٹیموں نے کریش مینجمنٹ کے ضوابط نافذ کیے ہیں وہ اہم بگز کی اصلاح کے وقت میں 60% کمی لاتی ہیں (Google, 2026 ڈیٹا)۔

Issues کو ترجیح دینا

تمام کریش ایک جتنے اہم نہیں ہوتے۔ صارفین کی تعداد اور تعدد کے مطابق ترجیح دینا سب سے اہم مسائل پر توجہ مرکوز کرنے میں مدد کرتا ہے۔ اصول: 0.1% سے زیادہ صارفین کو متاثر کرنے والے Issues کو 24 گھنٹوں میں حل کریں۔ واحد واقعات والے Issues (< 0.01%) کو اگلی منصوبہ بند ریلیز تک ملتوی کیا جا سکتا ہے۔ Crashlytics خود بخود رجعت کو نشان زد کرتا ہے — Issues جو حل ہو چکے تھے لیکن نئے ورژن میں دوبارہ ظاہر ہوتے ہیں۔

CI/CD کے ساتھ انضمام

Crashlytics API REST API یا Firebase CLI کے ذریعے کریش رپورٹوں کو CI/CD پائپ لائن میں ضم کرنے کی اجازت دیتا ہے۔ ہر نئی ریلیز پر، آپ خود بخود چیک کر سکتے ہیں کہ کیا crash-free صارفین کا فیصد حد سے تجاوز کر گیا ہے۔ اگر حد سے تجاوز ہو جائے تو، CI/CD ڈپلائمنٹ کو روک دیتا ہے اور ٹیم کو اطلاع بھیجتا ہے۔ Firebase CLI ProGuard/R8 میپنگ فائلوں کو اپ لوڈ کرنے کے لیے firebase crashlytics:builds:upload کمانڈ کو سپورٹ کرتا ہے — ان کے بغیر اسٹیک ناقابل پڑھ ہوں گے۔

Google (2026) کے مطابق، CI/CD میں خودکار crash-free حد کی جانچ استعمال کرنے والی ایپلیکیشنز پروڈکشن میں 40% کم رجعت جاری کرتی ہیں۔ تجویز کردہ حد: اہم ریلیز کے لیے crash-free users >= 99.5% اور عام ریلیز کے لیے >= 99.0%۔