Firebase Crashlytics — چیست، کرش‌ها و تشخیص خرابی‌ها

Firebase Crashlytics چیست

Firebase Crashlytics — سرویس رایگان Google برای نظارت بر پایداری برنامه‌های موبایل است که در سال ۲۰۱۷ همراه با شرکت Fabric توسط Google خریداری شد. Crashlytics به طور خودکار اطلاعات مربوط به هر خرابی برنامه را جمع‌آوری می‌کند، کرش‌های یکسان را بر اساس امضای پشته گروه‌بندی می‌کند و آنها را در کنسول Firebase با اولویت‌بندی بر اساس تعداد کاربران آسیب‌دیده نمایش می‌دهد.

تاریخچه و تکامل

Crashlytics در سال ۲۰۱۱ به عنوان بخشی از پلتفرم Fabric راه‌اندازی شد و به سرعت به استاندارد واقعی گزارش کرش در iOS تبدیل شد. پس از خرید توسط Google در سال ۲۰۱۷ به ارزش تخمینی ۲ میلیارد دلار (کل Fabric)، Crashlytics در Firebase SDK ادغام شد. نسخه ۱۸.۰.۰ (۲۰۲۱) پشتیبانی از Kotlin Multiplatform را اضافه کرد و نسخه ۱۹.۰.۰ (۲۰۲۴) — جمع‌آوری خودکار ANR در Android بدون پیکربندی اضافی. بر اساس داده‌های Google (۲۰۲۶)، Crashlytics بیش از ۱۰ میلیارد کرش را ماهانه پردازش می‌کند.

محدودیت‌های رایگان Crashlytics

Crashlytics با محدودیت ۵۰۰ هزار جلسه در روز برای یک پروژه Firebase به صورت رایگان ارائه می‌شود. برای اکثر برنامه‌ها این کافی است — بر اساس داده‌های Google (۲۰۲۶)، ۹۵٪ پروژه‌ها از محدودیت تجاوز نمی‌کنند. در صورت تجاوز، جمع‌آوری داده متوقف نمی‌شود، اما گزارش‌ها تا روز بعد به‌روزرسانی نمی‌شوند. برای پروژه‌های با بار بالا، تعرفه‌های Spark و Blaze Firebase در دسترس است — Crashlytics در هر دو تعرفه رایگان باقی می‌ماند و محدودیت جلسات جداگانه محاسبه می‌شود.

Crashlytics چگونه خرابی‌ها را تشخیص و جمع‌آوری می‌کند

مکانیسم جمع‌آوری Crashlytics بر اساس رهگیری استثناها در سطح پلتفرم و زمان اجرا است. در Android، SDK یک UncaughtExceptionHandler پیاده‌سازی می‌کند که تمام استثناهای مدیریت‌نشده Kotlin و Java را می‌گیرد. در iOS، Crashlytics از NSSetUncaughtExceptionHandler برای Objective-C/Swift و handler مخصوص استثناهای Mach برای کرش‌های کد بومی استفاده می‌کند.

انواع خرابی‌های رهگیری‌شده

Crashlytics پنج نوع خرابی را تشخیص می‌دهد: fatal (کرش‌های مهلک)، non-fatal (استثناهای غیرمهلک که به صورت دستی ارسال شده‌اند)، ANR (Android — برنامه پاسخ نمی‌دهد)، signal (سیگنال‌های OS — SIGSEGV، SIGABRT) و OOM (کمبود حافظه در iOS). هر نوع توسط یک مکانیسم جداگانه پردازش می‌شود و در کنسول با برچسب مربوطه نمایش داده می‌شود.

فرمت گزارش خرابی

هر گزارش Crashlytics حاوی اطلاعات کاملی است: ردیابی کامل پشته با نام کلاس‌ها و شماره خطوط، نسخه برنامه (versionName + versionCode)، مدل دستگاه، نسخه OS، میزان حافظه آزاد، جهت صفحه و زمان از راه‌اندازی. اگر Firebase Analytics متصل باشد، گزارش همچنین شامل مسیر ۵۰ رویداد آخر کاربر قبل از خرابی است — این برای بازتولید کرش حیاتی است.

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")
    }
}

ادغام Crashlytics در پروژه Android

اتصال Crashlytics به برنامه Android نیاز به افزودن دو وابستگی در build.gradle و پیکربندی پلاگین Google Services دارد. SDK به طور خودکار گزارش کرش را هنگام مقداردهی Firebase بدون کد اضافی فعال می‌کند. برای عملکرد صحیح، پلاگین google-services و فایل google-services.json از کنسول Firebase نیز لازم است.

// build.gradle (project-level)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (app-level)
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() استفاده می‌شود که یک استثنای آزمایشی ایجاد می‌کند. در بیلدهای تولیدی این متد در دسترس نیست. پس از اجرای کرش آزمایشی، گزارش در عرض ۱-۵ دقیقه در کنسول Firebase ظاهر می‌شود. اگر گزارش نمایش داده نشد — بررسی کنید که google-services.json با بسته برنامه مطابقت دارد و در AndroidManifest پرچم‌هایی که جمع‌آوری داده را غیرفعال می‌کنند وجود نداشته باشد.

تحلیل کرش‌ها و گروه‌بندی گزارش‌ها

کنسول Crashlytics دو سطح مشاهده را فراهم می‌کند: لیست تمام کرش‌ها (Issues) با گروه‌بندی بر اساس نوع خرابی و گزارش جزئیات برای هر Issue با ردیابی، آمار و داده‌های کاربر. هر Issue تمام کرش‌های با امضای مشابه را ترکیب می‌کند — همان نوع استثنا و ردیابی پشته منطبق.

Issues و گروه‌بندی

گروه‌بندی کرش‌ها — ویژگی کلیدی Crashlytics. به جای نمایش هزاران کرش جداگانه، سرویس آنها را بر اساس fingerprint — جمع کنترلی ردیابی پشته — در Issues ترکیب می‌کند. یک Issue می‌تواند از ۱ تا چند میلیون کرش را شامل شود. برای هر Issue نمایش داده می‌شود: تعداد موارد مهلک، تعداد کاربران یکتا، نسخه برنامه‌ای که کرش در آن ظاهر شده و درصد کاربرانی که با مشکل مواجه شده‌اند.

بر اساس داده‌های Google (۲۰۲۶)، به طور متوسط ۲۰٪ Issues باعث ۸۰٪ تمام کرش‌های مهلک برنامه می‌شوند (اصل پارتو). Crashlytics به طور خودکار Issues را بر اساس شدت مرتب می‌کند — هر چه کاربران بیشتری تحت تأثیر قرار گرفته باشند، اولویت بالاتر است. این به توسعه‌دهنده اجازه می‌دهد ابتدا گسترده‌ترین مشکلات را برطرف کند.

آمار بر اساس نسخه‌ها

Crashlytics پایداری هر نسخه از برنامه را جداگانه追踪 می‌کند. نمودار crash-free users درصد کاربرانی را نشان می‌دهد که با کرش مهلک در هر نسخه مواجه نشده‌اند. اگر در به‌روزرسانی درصد از آستانه (پیش‌فرض ۹۹٪) پایین‌تر بیفتد، Crashlytics از طریق ایمیل و Firebase Console اعلان ارسال می‌کند. این امکان را می‌دهد که نسخه مشکل‌دار را سریعاً برگردانید یا hotfix منتشر کنید.

کلیدهای سفارشی، لاگ‌ها و Breadcrumbs

Crashlytics سه مکانیسم برای غنی‌سازی گزارش‌ها با زمینه فراهم می‌کند: کلیدهای سفارشی (keys) برای داده‌های ساختاریافته، لاگ‌ها (logs) برای ردیابی متنی و Breadcrumbs از Analytics برای مسیر کاربر. هر سه نوع داده به گزارش کرش پیوست می‌شوند و در کارت جزئیات آن قابل مشاهده هستند.

کلیدهای سفارشی

Custom Keys — جفت‌های «کلید-مقدار» هستند که همراه با هر کرش ارسال می‌شوند. حداکثر ۶۴ کلید برای هر برنامه، هر کلید — رشته‌ای با طول تا ۱۰۲۴ کاراکتر. کلیدها برای علامت‌گذاری وضعیت برنامه مفید هستند: سطح اشتراک، وضعیت احراز هویت، آخرین صفحه، فعال بودن VPN. مقادیر بازنویسی می‌شوند — کلید جدید با همان نام جایگزین کلید قدیمی می‌شود.

لاگ‌گیری رویدادها

Custom Logs — پیام‌های متنی هستند که Crashlytics در بافر حلقوی با اندازه ۶۴ کیلوبایت ذخیره می‌کند. لاگ‌ها به طور خودکار به کرش بعدی پیوست می‌شوند. اگر کرش رخ ندهد — لاگ‌ها به سرور ارسال نمی‌شوند (ترافیک مصرف نمی‌کنند). لاگ‌گیری برای ثبت مراحل کاربر قبل از خرابی استفاده می‌شود: "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)
        }
    }
}

Breadcrumbs از Analytics

اگر Firebase Analytics در پروژه متصل باشد، Crashlytics به طور خودکار Breadcrumbs — آخرین ۵۰ رویداد تحلیلی قبل از کرش — را دریافت می‌کند. هر breadcrumb شامل نام رویداد و پارامترهای آن است. این امکان را می‌دهد که توالی دقیق اقدامات منجر به خرابی را بازسازی کنید: کاربر صفحه را باز کرد → محصول را اضافه کرد → به پرداخت رفت → کرش رخ داد. Breadcrumbs در کارت Issue در برگه جداگانه "Logs" نمایش داده می‌شوند.

بهترین روش‌های کار با خرابی‌ها

Crashlytics با پیکربندی صحیح زمینه و فرآیند پردازش Issues بیشترین کارایی را دارد. تجربه نشان می‌دهد که تیم‌هایی که آیین‌نامه کار با کرش‌ها را پیاده‌سازی کرده‌اند، زمان رفع باگ‌های بحرانی را ۶۰٪ کاهش می‌دهند (داده‌های Google، ۲۰۲۶).

اولویت‌بندی Issues

همه کرش‌ها به یک اندازه مهم نیستند. اولویت‌بندی بر اساس تعداد کاربران و فراوانی وقوع به تمرکز بر بحرانی‌ترین مشکلات کمک می‌کند. قانون: Issues تأثیرگذار بر بیش از ۰.۱٪ کاربران را در عرض ۲۴ ساعت رفع کنید. Issues با وقوع منفرد (< ۰.۰۱٪) را می‌توان تا انتشار برنامه‌ریزی‌شده بعدی به تعویق انداخت. Crashlytics به طور خودکار پسرفت‌ها را علامت‌گذاری می‌کند — Issues که رفع شده‌اند اما دوباره در نسخه جدید ظاهر شده‌اند.

ادغام با CI/CD

Crashlytics API امکان ادغام گزارش‌های خرابی در pipeline CI/CD را از طریق REST API یا Firebase CLI فراهم می‌کند. در هر انتشار جدید می‌توان به طور خودکار بررسی کرد که آیا درصد crash-free users از آستانه تجاوز می‌کند یا خیر. اگر آستانه exceeded شود — CI/CD استقرار را مسدود کرده و به تیم اعلان می‌فرستد. Firebase CLI از دستور firebase crashlytics:builds:upload برای بارگذاری فایل‌های نگاشت ProGuard/R8 پشتیبانی می‌کند — بدون آنها پشته‌ها قابل خواندن نخواهند بود.

بر اساس داده‌های Google (۲۰۲۶)، برنامه‌هایی که از بررسی خودکار آستانه crash-free در CI/CD استفاده می‌کنند، ۴۰٪ پسرفت کمتری به محیط تولید منتشر می‌کنند. آستانه توصیه‌شده: crash-free users >= ۹۹.۵٪ برای انتشارهای بحرانی و >= ۹۹.۰٪ برای انتشارهای معمولی.