Firebase Crashlytics — что это такое, краши и диагностика сбоев

Что такое Firebase Crashlytics

Firebase Crashlytics — это бесплатный сервис Google для мониторинга стабильности мобильных приложений, приобретённый Google в 2017 году вместе с компанией Fabric. Crashlytics автоматически собирает информацию о каждом сбое приложения, группирует идентичные краши по сигнатуре стека и отображает их в консоли Firebase с приоритизацией по количеству пострадавших пользователей.

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

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

Бесплатные лимиты 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-исключений для крашей native-кода.

Типы перехватываемых сбоев

Crashlytics различает пять типов сбоев: fatal (фатальные краши), non-fatal (нефатальные исключения, переданные вручную), ANR (Android — приложение не отвечает), signal (сигналы ОС — SIGSEGV, SIGABRT) и OOM (out of memory на iOS). Каждый тип обрабатывается отдельным механизмом и отображается в консоли с соответствующей меткой.

Формат отчёта о сбое

Каждый отчёт Crashlytics содержит исчерпывающую информацию: полную трассировку стека с названиями классов и номерами строк, версию приложения (versionName + versionCode), модель устройства, версию ОС, объём свободной памяти, ориентацию экрана и время с момента запуска. Если подключён 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")
    }
}

Интеграция Crashlytics в Android проект

Подключение Crashlytics к Android-приложению требует добавления двух зависимостей в build.gradle и настройки плагина Google Services. SDK автоматически подключает crash-репортинг при инициализации 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(), который генерирует тестовое исключение. В production-сборках этот метод недоступен. После запуска тестового краша отчёт появляется в консоли Firebase в течение 1-5 минут. Если отчёт не отображается — проверьте, что google-services.json соответствует пакету приложения и что в AndroidManifest нет флагов, отключающих сбор данных.

Анализ крашей и группировка отчётов

Консоль Crashlytics предоставляет два уровня просмотра: список всех крашей (Issues) с группировкой по типу сбоя, и детальный отчёт по каждому Issue с трассировкой, статистикой и пользовательскими данными. Каждый Issue объединяет все краши с одинаковой сигнатурой — одинаковым типом исключения и совпадающей трассировкой стека.

Issues и группировка

Группировка крашей — ключевая особенность Crashlytics. Вместо того чтобы показывать тысячи отдельных крашей, сервис объединяет их в Issues на основе fingerprint — контрольной суммы трассировки стека. Один Issue может содержать от 1 до нескольких миллионов крашей. Для каждого Issue отображается: количество фатальных случаев, количество уникальных пользователей, версия приложения, в которой краш появился, и процент пользователей, столкнувшихся с проблемой.

По данным Google (2026), в среднем 20% Issues составляют 80% всех фатальных крашей приложения (принцип Парето). Crashlytics автоматически сортирует Issues по severity — чем больше пользователей затронуто, тем выше приоритет. Это позволяет разработчику в первую очередь исправлять самые массовые проблемы.

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

Crashlytics отслеживает стабильность каждой версии приложения отдельно. График crash-free users показывает процент пользователей, не столкнувшихся с фатальным крашем в каждой версии. Если при обновлении процент падает ниже порога (по умолчанию 99%), Crashlytics отправляет уведомление по email и в Firebase Console. Это позволяет быстро откатить проблемную версию или выпустить hotfix.

Пользовательские ключи, логи и Breadcrumbs

Crashlytics предоставляет три механизма для обогащения отчётов контекстом: пользовательские ключи (keys) для структурированных данных, логи (logs) для текстовой трассировки и Breadcrumbs из Analytics для пути пользователя. Все три типа данных привязываются к отчёту о краше и видны в его детальной карточке.

Пользовательские ключи

Custom Keys — это пары "ключ-значение", которые передаются вместе с каждым крашем. Максимум 64 ключа на приложение, каждый ключ — строка длиной до 1024 символов. Ключи удобно использовать для маркировки состояния приложения: уровень подписки, статус авторизации, последний экран, включён ли VPN. Значения перезаписываются — новый ключ с тем же именем заменяет старый.

Логирование событий

Custom Logs — это текстовые сообщения, которые Crashlytics сохраняет в кольцевом буфере размером 64 КБ. Логи автоматически прикрепляются к следующему крашу. Если краша не происходит — логи не передаются на сервер (не расходуют трафик). Логирование используется для записи шагов пользователя перед сбоем: "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 событий аналитики перед крашем. Каждый breadcrumb содержит название события и его параметры. Это позволяет восстановить точную последовательность действий, приведших к сбою: пользователь открыл экран → добавил товар → перешёл к оплате → произошёл краш. Breadcrumbs отображаются в карточке Issue на отдельной вкладке "Logs".

Лучшие практики работы со сбоями

Crashlytics наиболее эффективен при правильной настройке контекста и процесса обработки Issues. Практика показывает, что команды, внедрившие регламент работы с крашами, сокращают время исправления критических багов на 60% (данные Google, 2026).

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

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

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

Crashlytics API позволяет интегрировать отчёты о крашах в пайплайн CI/CD через 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% для обычных.