Crash Reporting в мобилното развитие — какво е, услуги и настройка

Какво е Crash Reporting?

Crash Reporting — е процес на автоматично събиране на техническа информация за сривове на приложението и централизираното ѝ изпращане на сървър за анализ. За разлика от логване, crash-reporting записва точно аварийните ситуации — момента, в който приложението е било принудително прекратено от системата или ОС.

Всеки crash отчет съдържа три ключови компонента: тип на изключението (NullPointerException, SIGSEGV, NSInternalInconsistencyException), пълен стек на повикванията с номера на редове и информация за средата — версия на ОС, модел на устройството, количество свободна памет. Според Sentry Engineering, 2024, именно комбинацията от тези три елемента позволява възпроизвеждане и поправка на 85% от критичните грешки.

Съвременните crash-reporting системи разширяват функционалността отвъд обикновените сривове. Firebase Crashlytics автоматично групира повтарящи се сривове в issues, Sentry проследява регресии между версиите, а Bugsnag показва потребителския път към грешката. И трите услуги поддържат iOS, Android, React Native и Flutter.

Според Google I/O 2024, приложенията без crash-reporting отделят средно 3–5 работни дни за диагностика на една критична грешка, докато с Crashlytics — 15–30 минути. Икономията на време е над 90% за всеки инцидент.

Как работи системата за събиране на crash отчети

Архитектура на crash-reporting системата се състои от три слоя: клиентски SDK, инсталиран в приложението, сървърен API за приемане и обработка на отчети и уеб табло за анализ. Клиентският SDK прихваща необработени изключения, сериализира ги в JSON и ги изпраща на сървъра при следващото стартиране на приложението.

Изпращането на crash отчет става асинхронно след рестартиране на приложението. Това е принципен момент: в момента на срив приложението не може да гарантира успешно изпращане на данни по мрежата. SDK записва отчета в локално хранилище и при следващо стартиране го изпраща във фонов поток. Според Firebase Engineering, 2024, този подход осигурява доставка на 99.7% от crash отчетите.

За non-fatal изключения (handled exceptions в try-catch) SDK изпраща отчета незабавно, тъй като приложението продължава да работи. Non-fatal отчетите съдържат същите данни като crash, но не прекъсват потребителската сесия. Това е особено полезно за проследяване на грешки в API заявки, валидация на данни и бизнес логика.

Групиране на сривове — сървърен алгоритъм, който обединява идентични сривове на базата на хеш от последните 5–10 рамки на стека. Това позволява на разработчика да вижда не 1000 отделни отчета, а един issue с 1000 прояви, обхващащи различни устройства и версии на ОС.

Firebase Crashlytics: интеграция и възможности

Firebase Crashlytics — най-популярната услуга за crash-reporting за мобилни приложения, използвана в над 3 милиона проекта по целия свят. Безплатният план включва неограничен брой отчети, интеграция с Google Analytics и автоматично групиране на сривове.

Интеграция на Crashlytics на Android

Свързване на Crashlytics на Android е минимално: добавете зависимост в build.gradle и инициализирайте SDK в Application.onCreate. Crashlytics автоматично задава собствен Thread.setDefaultUncaughtExceptionHandler, прихващайки всички необработени изключения.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

Ключова възможност на Crashlytics — custom keys и logs. Разработчикът може да добави до 64 двойки ключ-стойност към всеки crash отчет: състояние на екрана, избран тариф, потребителско ниво. Също така е наличен запис на персонализирани лог съобщения, които попадат в отчета в хронологичен ред.

Velocity Alert — автоматично откриване на регресии

Velocity Alert — функция на Crashlytics, която следи рязко нарастване на броя сривове за конкретен issue. Ако след нова версия броят на сривовете надхвърли праговата стойност, екипът получава push известие и имейл 5–15 минути преди масови потребителски оплаквания.

Настройка на прага на задействане: 2x за 1 час за критични issues. Според Google, 2024, екипите с активиран Velocity Alert пускат hotfix версии средно с 40% по-бързо от екипите, разчитащи на ръчно наблюдение на таблото.

Интеграция на Crashlytics на iOS

На iOS Crashlytics SDK се интегрира чрез CocoaPods или Swift Package Manager. SDK прихваща както Objective-C изключения (чрез NSSetUncaughtExceptionHandler), така и OS сигнали (SIGSEGV, SIGABRT) чрез собствен mach exception handler.

Според Apple Developer, 2024, Crashlytics за iOS обработва до 98% от всички типове сривове, включително ниско ниво грешки в паметта, които не се прихващат от стандартните механизми. Това прави Crashlytics де факто стандарт за iOS разработка.

Sentry и Bugsnag: алтернативни платформи

Sentry — платформа с отворен код за наблюдение на грешки, поддържаща 80+ езика и рамки. За разлика от Crashlytics, Sentry е насочена към backend разработчици, но предоставя пълноценен SDK за iOS, Android, React Native и Flutter.

Ключовото предимство на Sentry — Performance Monitoring в единно табло. Разработчикът вижда не само сривове, но и транзакциите, които са довели до тях: бавни мрежови заявки, замръзвания на UI, дълги операции с база данни. Според Sentry, 2024, 40% от сривовете имат предшестващи проблеми с производителността, които остават незабелязани без такъв подход.

Bugsnag се отличава с подхода си за групиране на грешки — вместо стек на повикванията, анализира потребителския път (user journey). Всеки crash отчет съдържа последователност от екрани и действия на потребителя, довели до грешката. Това е особено полезно за сложни бизнес процеси: поръчка, регистрация, плащане.

Цената на услугите варира: Crashlytics е безплатен в рамките на Firebase, Sentry предлага безплатен план за 5000 събития на месец, Bugsnag — от $29 на месец. И трите платформи предоставят SDK с отворен код. Изборът на услуга зависи от размера на екипа, бюджета и изискванията за сигурност на данните.

Crash Reporting на iOS: характеристики и NSException

Характеристика на iOS — многослойна архитектура за обработка на грешки. Crash-reporting SDK трябва да прихващат Objective-C изключения (NSException), Swift грешки (Error), POSIX сигнали (SIGSEGV, SIGBUS) и mach-изключения. Всеки тип изисква отделен механизъм за прихващане.

NSException — най-простият тип за прихващане чрез NSSetUncaughtExceptionHandler. Въпреки това, според Apple, 2024, само 30% от сривовете в съвременните Swift приложения са NSException. Останалите 70% са OS сигнали и Swift runtime грешки, които изискват механизъм mach exception handler.

Разработчиците на iOS трябва да тестват crash-reporting чрез локално генериране на сривове от различен тип: __builtin_trap() за сигнали, [NSException raise:...] за изключения, fatalError() за Swift. Само така могат да се уверят, че SDK покрива всички типове сривове.

Crash Reporting на Android: ANR и native crashes

Android добавя два специфични типа сривове, които не съществуват на iOS: ANR (Application Not Responding) и native crash в C/C++ код. ANR възниква, когато UI нишката е блокирана за повече от 5 секунди — системата показва диалог „Приложението не отговаря" и предлага да го затвори.

Стандартният Thread.setDefaultUncaughtExceptionHandler не прихваща ANR, тъй като това не е изключение, а сигнал от ActivityManager. За проследяване на ANR Crashlytics и Sentry използват watchdog нишка във фонов режим, която проверява отзивчивостта на UI нишката на всеки 5 секунди. Според Firebase, 2024, 15% от всички проблеми на Android са ANR, а не срив.

Native crash на Android възникват в C/C++ код, стартиран чрез JNI (Java Native Interface). Тези сривове не са Java изключения и не се прихващат от Thread.setDefaultUncaughtExceptionHandler. За тяхната обработка се използват Google Breakpad или Crashpad, които инсталират sigaction обработчици за сигналите SIGSEGV, SIGABRT, SIGBUS.

Според Google I/O 2024, броят на native crash расте с разпространението на игрови двигатели (Unity, Unreal Engine) и библиотеки за компютърно зрение (ML Kit, OpenCV). На разработчиците на хибридни приложения се препоръчва винаги да включват native crash-reporting.