Crash Reporting у мобилном развоју — шта је, сервиси и подешавање

Шта је Crash Reporting?

Crash Reporting — је процес автоматског прикупљања техничких информација о падовима апликације и њиховог централизованог слања на сервер ради анализе. За разлику од логовања, crash-reporting билежи управо хитне ситуације — тренутак када је апликација принудно заустављена од стране система или OS-а.

Сваки crash извештај садржи три кључне компоненте: тип изузетка (NullPointerException, SIGSEGV, NSInternalInconsistencyException), пун стек позива са бројевима редова и информације о окружењу — верзија OS-а, модел уређаја, количина слободне меморије. Према Sentry Engineering, 2024, управо комбинација ова три елемента омогућава репродукцију и поправку 85% критичних грешака.

Савремени crash-reporting системи проширују функционалност изван обичних crash-ова. 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 извештаја одвија се асинхроно након поновног покретања апликације. Ово је кључни тренутак: у тренутку crash-а, апликација не може да гарантује успешно слање података путем мреже. SDK чува извештај у локалном складишту и при сљедећем покретању га шаље у позадини. Према Firebase Engineering, 2024, овакав приступ осигурава испоруку 99.7% crash извештаја.

За non-fatal изузетке (handled exceptions унутар try-catch) SDK шаље извештај одмах, јер апликација наставља да ради. Non-fatal извештаји садрже исте податке као и crash, али не прекидају корисничку сесију. Ово је посебно корисно за праћење грешака API захтева, валидације података и пословне логике.

Груписање crash-ова — серверски алгоритам који спаја идентичне crash-ове на основу хеша последњих 5–10 оквира стека. Ово омогућава програмеру да види не 1000 појединачних извештаја, већ један issue са 1000 појава, који обухвата различите уређаје и верзије OS-а.

Firebase Crashlytics: интеграција и могућности

Firebase Crashlytics — најпопуларнији crash-reporting сервис за мобилне апликације, који се користи у преко 3 милиона пројеката широм света. Бесплатни пакет укључује неограничен број извештаја, интеграцију са Google Analytics и автоматско груписање crash-ова.

Интеграција 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 извештају: стање екрана, изабрани тариф, ниво корисника. Такође је омогућено снимање custom log порука које доспевају у извештај у хронолошком редоследу.

Velocity Alert — автоматско откривање регресија

Velocity Alert — функција Crashlytics-а која прати нагли пораст броја crash-ова за одређени 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 — open-source платформа за праћење грешака, која подржава 80+ језика и фрејмворка. За разлику од Crashlytics-а, Sentry је оријентисана ка backend програмерима, али пружа пун SDK за iOS, Android, React Native и Flutter.

Кључна предност Sentry-а — Performance Monitoring у јединственом дашборду. Програмер види не само crash, већ и транзакције које су довеле до њих: споре мрежне захтеве, замрзавања UI-ја, дуге операције са базом података. Према Sentry, 2024, 40% crash-ова има претходне перформансне проблеме које остају непримећене без оваквог приступа.

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% crash-ова у савременим Swift апликацијама су NSException. Преосталих 70% су OS сигнали и Swift runtime грешке, које захтевају механизам mach exception handler-а.

ИОС програмери треба да тестирају crash-reporting кроз локално генерисање crash-ова различитих типова: __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, а не crash.

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.