Firebase Crashlytics — какво е това, crashes и диагностика на повреди

Какво е Firebase Crashlytics

Firebase Crashlytics е безплатна услуга на Google за мониторинг на стабилността на мобилни приложения, придобита от Google през 2017 г. заедно с компанията Fabric. Crashlytics автоматично събира информация за всяка повреда на приложението, групира идентични crashes по сигнатура на стека и ги показва в конзолата на Firebase с приоритизация според броя на засегнатите потребители.

История и еволюция

Crashlytics стартира през 2011 г. като част от платформата Fabric и бързо стана де факто стандарт за отчитане на crashes в iOS. След придобиването от Google през 2017 г. за оценени 2 милиарда долара (целият Fabric), Crashlytics беше интегриран в Firebase SDK. Версия 18.0.0 (2021) добави поддръжка за Kotlin Multiplatform, а версия 19.0.0 (2024) — автоматично събиране на ANR на Android без допълнителна конфигурация. Според данни на Google (2026), Crashlytics обработва повече от 10 милиарда crashes месечно.

Безплатни лимити на Crashlytics

Crashlytics се предоставя безплатно с лимит от 500 хиляди сесии на ден на проект Firebase. За повечето приложения това е достатъчно — според данни на Google (2026), 95% от проектите не надвишават лимита. При надвишаване събирането на данни не спира, но отчетите спират да се актуализират до следващия ден. За проекти с високо натоварване са достъпни тарифите Spark и Blaze на Firebase — Crashlytics остава безплатен и на двете тарифи, а лимитът на сесиите се изчислява отделно.

Как Crashlytics открива и събира повреди

Механизмът на събиране на Crashlytics се основава на прихващане на изключения на ниво платформа и runtime. На Android, SDK имплементира UncaughtExceptionHandler, който прихваща всички необработени Kotlin и Java изключения. На iOS, Crashlytics използва NSSetUncaughtExceptionHandler за Objective-C/Swift и собствен Mach обработчик на изключения за crashes на native код.

Типове прихванати повреди

Crashlytics различава пет типа повреди: fatal (фатални crashes), non-fatal (нефатални изключения, предадени ръчно), ANR (Android — приложението не отговаря), signal (OS сигнали — SIGSEGV, SIGABRT) и OOM (недостиг на памет на iOS). Всеки тип се обработва от отделен механизъм и се показва в конзолата със съответен етикет.

Формат на отчета за повреда

Всеки отчет на Crashlytics съдържа изчерпателна информация: пълно проследяване на стека с имена на класове и номера на редове, версия на приложението (versionName + versionCode), модел на устройството, версия на OS, количество свободна памет, ориентация на екрана и време от стартиране. Ако Firebase Analytics е свързан, отчетът също включва пътя на последните 50 събития на потребителя преди повредата — това е критично за възпроизвеждане на crash-а.

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 автоматично активира отчитането на crashes при инициализация на 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. Без плъгина, crashes ще бъдат маркирани като „unmapped" — ще видите само объркани имена на класове (a.b.c) без възможност за намиране на изходния код. Плъгинът се добавя в кореновия build.gradle и в build.gradle на модула на приложението.

Проверка на интеграцията

За тестване на интеграцията на Crashlytics се използва специалният метод forceCrash(), който генерира тестово изключение. В production компилации този метод не е достъпен. След стартиране на тестовия crash, отчетът се появява в конзолата на Firebase в рамките на 1-5 минути. Ако отчетът не се показва — проверете дали google-services.json съответства на пакета на приложението и дали в AndroidManifest няма флагове, изключващи събирането на данни.

Анализ на crashes и групиране на отчети

Конзолата на Crashlytics предоставя две нива на преглед: списък на всички crashes (Issues) с групиране по тип повреда и подробен отчет за всеки Issue с проследяване, статистика и потребителски данни. Всеки Issue обединява всички crashes с еднаква сигнатура — еднакъв тип изключение и съответстващо проследяване на стека.

Issues и групиране

Групирането на crashes — ключова характеристика на Crashlytics. Вместо да показва хиляди отделни crashes, услугата ги обединява в Issues на базата на fingerprint — контролна сума на проследяването на стека. Един Issue може да съдържа от 1 до няколко милиона crashes. За всеки Issue се показва: брой фатални случаи, брой уникални потребители, версия на приложението, в която се е появил crash-ът, и процент потребители, които са се сблъскали с проблема.

Според данни на Google (2026), средно 20% от Issues съставляват 80% от всички фатални crashes на приложението (принцип на Парето). Crashlytics автоматично сортира Issues по тежест — колкото повече потребители са засегнати, толкова по-висок е приоритетът. Това позволява на разработчика първо да поправи най-масовите проблеми.

Статистика по версии

Crashlytics проследява стабилността на всяка версия на приложението отделно. Графиката crash-free users показва процента потребители, които не са се сблъскали с фатален crash във всяка версия. Ако при актуализация процентът падне под прага (по подразбиране 99%), Crashlytics изпраща известие по имейл и в Firebase Console. Това позволява бързо изтегляне на проблемната версия или пускане на hotfix.

Потребителски ключове, логове и Breadcrumbs

Crashlytics предоставя три механизма за обогатяване на отчети с контекст: потребителски ключове (keys) за структурирани данни, логове (logs) за текстово проследяване и Breadcrumbs от Analytics за пътя на потребителя. И трите типа данни се прикрепят към отчета за crash и са видими в неговата детайлна карта.

Потребителски ключове

Custom Keys — това са двойки „ключ-стойност", които се предават заедно с всеки crash. Максимум 64 ключа на приложение, всеки ключ — низ с дължина до 1024 символа. Ключовете са удобни за маркиране на състоянието на приложението: ниво на абонамент, статус на оторизация, последен екран, дали VPN е включен. Стойностите се презаписват — нов ключ със същото име замества стария.

Логване на събития

Custom Logs — това са текстови съобщения, които Crashlytics съхранява в кръгъл буфер с размер 64 KB. Логовете автоматично се прикрепят към следващия crash. Ако не настъпи crash — логовете не се предават на сървъра (не изразходват трафик). Логването се използва за записване на стъпките на потребителя преди повреда: „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 — последните 50 аналитични събития преди crash-а. Всяка breadcrumb съдържа името на събитието и неговите параметри. Това позволява възстановяване на точната последователност от действия, довели до повредата: потребителят отвори екрана → добави продукт → премина към плащане → настъпи crash. Breadcrumbs се показват в картата на Issue в отделен раздел „Logs".

Най-добри практики за работа с повреди

Crashlytics е най-ефективен при правилно конфигуриране на контекста и процеса на обработка на Issues. Практиката показва, че екипите, въвели правила за работа с crashes, намаляват времето за поправка на критични грешки с 60% (данни на Google, 2026).

Приоритизация на Issues

Не всички crashes са еднакво важни. Приоритизацията според броя на потребителите и честотата на поява помага да се съсредоточите върху най-критичните проблеми. Правило: поправяйте Issues, засягащи повече от 0.1% от потребителите, в рамките на 24 часа. Issues с единични появявания (< 0.01%) могат да бъдат отложени до следващото планирано издание. Crashlytics автоматично маркира регресии — Issues, които са били поправени, но са се появили отново в нова версия.

Интеграция с CI/CD

Crashlytics API позволява интегриране на отчети за повреди в CI/CD pipeline чрез REST API или Firebase CLI. При всяко ново издание можете автоматично да проверявате дали процентът crash-free users не надвишава праговата стойност. Ако прагът е надвишен — CI/CD блокира пускането и изпраща известие на екипа. Firebase CLI поддържа командата firebase crashlytics:builds:upload за качване на файлове за картографиране ProGuard/R8 — без тях стековете ще бъдат нечетливи.

Според данни на Google (2026), приложенията, използващи автоматична проверка на crash-free прагове в CI/CD, пускат 40% по-малко регресии в production. Препоръчителен праг: crash-free users >= 99.5% за критични издания и >= 99.0% за обикновени издания.