Firebase Crashlytics — шта је то, крашеви и дијагностика отказа

Шта је Firebase Crashlytics

Firebase Crashlytics — то је бесплатни Google сервис за праћење стабилности мобилних апликација, који је Google купио 2017. године заједно са компанијом Fabric. Crashlytics аутоматски прикупља информације о сваком отказу апликације, групише идентичне крашеве по потпису стека и приказује их у Firebase конзоли са приоритизацијом према броју погођених корисника.

Историја и еволуција

Crashlytics је покренут 2011. године као део платформе Fabric и брзо је постао де факто стандард за извештавање о крашевима у 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 (OS сигнали — SIGSEGV, SIGABRT) и OOM (недостатак меморије на iOS-у). Сваки тип обрађује посебан механизам и приказује се у конзоли са одговарајућом ознаком.

Формат извештаја о отказу

Сваки Crashlytics извештај садржи исцрпне информације: потпуно праћење стека са именима класа и бројевима линија, верзију апликације (versionName + versionCode), модел уређаја, верзију OS-а, количину слободне меморије, оријентацију екрана и време од покретања. Ако је 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 аутоматски активира извештавање о крашевима при иницијализацији 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 по озбиљности — што је више корисника погођено, то је виши приоритет. Ово омогућава програмеру да прво поправи најмасовније проблеме.

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

Crashlytics прати стабилност сваке верзије апликације посебно. Графикон crash-free users приказује проценат корисника који нису наишли на фатални краш у свакој верзији. Ако при ажурирању проценат падне испод прага (подразумевано 99%), Crashlytics шаље обавештење путем е-поште и у Firebase Console. Ово омогућава брзо повлачење проблематичне верзије или издавање hotfix-а.

Кориснички кључеви, логови и Breadcrumbs

Crashlytics пружа три механизма за обогаћивање извештаја контекстом: корисничке кључеве (keys) за структуриране податке, логове (logs) за текстуално праћење и Breadcrumbs из Analytics-а за пут корисника. Све три врсте података се прикачују извештају о крашу и видљиве су у његовој детаљној картици.

Кориснички кључеви

Custom Keys — то су парови „кључ-вредност" који се преносе заједно са сваким крашем. Максимално 64 кључа по апликацији, сваки кључ — низ дужине до 1024 карактера. Кључеви су погодни за означавање стања апликације: ниво претплате, статус ауторизације, последњи екран, да ли је VPN укључен. Вредности се преписују — нови кључ са истим именом замењује стари.

Логовање догађаја

Custom Logs — то су текстуалне поруке које Crashlytics чува у кружном баферу величине 64 KB. Логови се аутоматски прикачу следећем крашу. Ако се краш не догоди — логови се не преносе на сервер (не троше саобраћај). Логовање се користи за бележење корака корисника пре отказа: „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 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% за обична.