Firebase Crashlytics — ano ito, mga crash at diagnosis ng pagkasira

Ano ang Firebase Crashlytics

Firebase Crashlytics ay isang libreng serbisyo ng Google para sa pagsubaybay sa katatagan ng mga mobile application, na binili ng Google noong 2017 kasama ng kumpanyang Fabric. Awtomatikong kinokolekta ng Crashlytics ang impormasyon tungkol sa bawat pagkasira ng application, pinag-grupo ang magkakaparehong crash ayon sa lagda ng stack, at ipinapakita ang mga ito sa Firebase console na may prayoridad batay sa bilang ng mga apektadong user.

Kasaysayan at ebolusyon

Ang Crashlytics ay inilunsad noong 2011 bilang bahagi ng platform ng Fabric at mabilis na naging de facto standard para sa pag-uulat ng crash sa iOS. Pagkatapos bilhin ng Google noong 2017 sa tinatayang 2 bilyong dolyar (buong Fabric), ang Crashlytics ay isinama sa Firebase SDK. Ang bersyon 18.0.0 (2021) ay nagdagdag ng suporta para sa Kotlin Multiplatform, at ang bersyon 19.0.0 (2024) — awtomatikong pagkolekta ng ANR sa Android nang walang karagdagang configuration. Ayon sa datos ng Google (2026), ang Crashlytics ay nagpoproseso ng mahigit 10 bilyong crash buwan-buwan.

Mga libreng limitasyon ng Crashlytics

Crashlytics ay ibinibigay nang libre na may limitasyon na 500 libong session bawat araw bawat proyekto ng Firebase. Para sa karamihan ng mga application ito ay sapat — ayon sa datos ng Google (2026), 95% ng mga proyekto ay hindi lumalagpas sa limitasyon. Kapag lumagpas, ang pagkolekta ng datos ay hindi humihinto, ngunit ang mga ulat ay humihinto sa pag-update hanggang sa susunod na araw. Para sa mga proyektong may mataas na karga, available ang mga taripa ng Spark at Blaze ng Firebase — ang Crashlytics ay nananatiling libre sa parehong taripa, at ang limitasyon ng session ay kinakalkula nang hiwalay.

Paano natutukoy at kinokolekta ng Crashlytics ang mga pagkasira

Ang mekanismo ng pagkolekta ng Crashlytics ay batay sa pagharang ng mga exception sa antas ng platform at runtime. Sa Android, ipinapatupad ng SDK ang UncaughtExceptionHandler na humaharang sa lahat ng hindi nakitang exception ng Kotlin at Java. Sa iOS, ginagamit ng Crashlytics ang NSSetUncaughtExceptionHandler para sa Objective-C/Swift at sarili nitong handler ng Mach exception para sa crash ng native code.

Mga uri ng pagkasira na hinaharang

Ang Crashlytics ay nag-iiba ng limang uri ng pagkasira: fatal (nakamamatay na crash), non-fatal (hindi nakamamatay na exception na manu-manong ipinadala), ANR (Android — hindi tumutugon ang application), signal (mga signal ng OS — SIGSEGV, SIGABRT) at OOM (kakulangan ng memorya sa iOS). Ang bawat uri ay pinoproseso ng hiwalay na mekanismo at ipinapakita sa console na may kaukulang label.

Format ng ulat ng pagkasira

Ang bawat ulat ng Crashlytics ay naglalaman ng kumpletong impormasyon: buong stack trace na may mga pangalan ng klase at numero ng linya, bersyon ng application (versionName + versionCode), modelo ng device, bersyon ng OS, dami ng libreng memorya, oryentasyon ng screen, at oras mula noong startup. Kung nakakonekta ang Firebase Analytics, kasama rin sa ulat ang landas ng huling 50 kaganapan ng user bago ang pagkasira — ito ay kritikal para sa pag-reproduce ng 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")
    }
}

Pagsasama ng Crashlytics sa proyekto ng Android

Pagkonekta ng Crashlytics sa isang Android app ay nangangailangan ng pagdagdag ng dalawang dependency sa build.gradle at pag-configure ng Google Services plugin. Awtomatikong ina-activate ng SDK ang pag-uulat ng crash sa pagsisimula ng Firebase nang walang karagdagang code. Para sa tamang operasyon, kinakailangan din ang google-services plugin at ang file na google-services.json mula sa Firebase console.

// 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")
}

Configuration ng Crashlytics plugin

Ang plugin na com.google.firebase.crashlytics ay gumaganap ng dalawang gawain: bumubuo ng natatanging build ID para sa pagma-map ng mga obfuscated na stack at awtomatikong lumilikha ng mga resource para sa Crashlytics SDK. Kung wala ang plugin, ang mga crash ay mamarkahan bilang "unmapped" — makikita mo lamang ang mga obfuscated na pangalan ng klase (a.b.c) nang walang kakayahang mahanap ang source code. Ang plugin ay idinaragdag sa root build.gradle at sa build.gradle ng module ng application.

Pagsuri ng pagsasama

Para sa pagsubok ng pagsasama ng Crashlytics, ginagamit ang espesyal na paraan na forceCrash() na bumubuo ng test exception. Sa mga build ng produksyon, ang paraang ito ay hindi available. Pagkatapos patakbuhin ang test crash, lumalabas ang ulat sa Firebase console sa loob ng 1-5 minuto. Kung hindi lumalabas ang ulat — suriin kung ang google-services.json ay tumutugma sa package ng application at kung walang mga flag sa AndroidManifest na nagde-deactivate ng pagkolekta ng datos.

Pagsusuri ng crash at pag-grupo ng mga ulat

Ang Crashlytics console ay nagbibigay ng dalawang antas ng pagtingin: listahan ng lahat ng crash (Issues) na naka-grupo ayon sa uri ng pagkasira, at detalyadong ulat para sa bawat Issue na may stack trace, estadistika, at datos ng user. Pinagsasama ng bawat Issue ang lahat ng crash na may parehong lagda — parehong uri ng exception at tugmang stack trace.

Issues at pag-grupo

Ang pag-grupo ng crash — pangunahing tampok ng Crashlytics. Sa halip na magpakita ng libu-libong indibidwal na crash, pinagsasama ng serbisyo ang mga ito sa Issues batay sa fingerprint — checksum ng stack trace. Ang isang Issue ay maaaring maglaman mula 1 hanggang ilang milyong crash. Para sa bawat Issue ay ipinapakita: bilang ng mga nakamamatay na kaso, bilang ng mga natatanging user, bersyon ng application kung saan lumitaw ang crash, at porsyento ng mga user na nakatagpo ng problema.

Ayon sa datos ng Google (2026), sa karaniwan 20% ng Issues ay bumubuo ng 80% ng lahat ng nakamamatay na crash ng application (prinsipyo ng Pareto). Awtomatikong ini-sort ng Crashlytics ang Issues ayon sa severity — mas maraming user ang apektado, mas mataas ang prayoridad. Ito ay nagpapahintulot sa developer na unang ayusin ang pinakamalalang problema.

Estadistika ayon sa bersyon

Crashlytics ay sinusubaybayan ang katatagan ng bawat bersyon ng application nang hiwalay. Ang graph na crash-free users ay nagpapakita ng porsyento ng mga user na hindi nakatagpo ng nakamamatay na crash sa bawat bersyon. Kung sa pag-update ay bumaba ang porsyento sa ibaba ng threshold (default 99%), nagpapadala ang Crashlytics ng abiso sa pamamagitan ng email at sa Firebase Console. Ito ay nagpapahintulot ng mabilis na pagbawi ng problematikong bersyon o paglabas ng hotfix.

Mga custom na key, log, at Breadcrumbs

Crashlytics ay nagbibigay ng tatlong mekanismo para pagyamanin ang mga ulat ng konteksto: mga custom na key para sa structured na datos, log para sa textual na pagsubaybay, at Breadcrumbs mula sa Analytics para sa landas ng user. Lahat ng tatlong uri ng datos ay naka-attach sa ulat ng crash at makikita sa detalyadong card nito.

Mga custom na key

Custom Keys — ay mga pares na "key-value" na ipinapadala kasama ng bawat crash. Maximum na 64 key bawat application, bawat key — string na may haba hanggang 1024 character. Ang mga key ay maginhawa para sa pagmamarka ng estado ng application: antas ng subscription, status ng awtorisasyon, huling screen, kung naka-on ang VPN. Ang mga halaga ay na-o-overwrite — ang bagong key na may parehong pangalan ay pumapalit sa luma.

Pag-log ng mga kaganapan

Custom Logs — ay mga text message na iniimbak ng Crashlytics sa circular buffer na may sukat na 64 KB. Ang mga log ay awtomatikong naka-attach sa susunod na crash. Kung walang crash na nangyari — ang mga log ay hindi ipinapadala sa server (hindi gumagamit ng trapiko). Ang pag-log ay ginagamit para sa pagtala ng mga hakbang ng user bago ang pagkasira: "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 mula sa Analytics

Kung ang Firebase Analytics ay konektado sa proyekto, awtomatikong natatanggap ng Crashlytics ang Breadcrumbs — huling 50 analytics na kaganapan bago ang crash. Ang bawat breadcrumb ay naglalaman ng pangalan ng kaganapan at mga parameter nito. Ito ay nagpapahintulot ng rekonstruksyon ng eksaktong pagkakasunod-sunod ng mga aksyon na humantong sa pagkasira: binuksan ng user ang screen → nagdagdag ng produkto → nagpatuloy sa pagbabayad → nangyari ang crash. Ang Breadcrumbs ay ipinapakita sa card ng Issue sa isang hiwalay na tab na "Logs".

Pinakamahuhusay na kasanayan sa pagtatrabaho sa mga pagkasira

Crashlytics ay pinakamabisa sa tamang configuration ng konteksto at proseso ng paghawak ng Issues. Ipinapakita ng praktika na ang mga team na nagpatupad ng mga patakaran sa pagtatrabaho sa crash ay binabawasan ang oras ng pag-aayos ng mga kritikal na bug ng 60% (datos ng Google, 2026).

Prayoritisasyon ng Issues

Hindi lahat ng crash ay pantay na mahalaga. Ang prayoritisasyon batay sa bilang ng mga user at dalas ng paglitaw ay tumutulong na tumuon sa mga pinaka-kritikal na problema. Patakaran: ayusin ang Issues na nakakaapekto sa higit sa 0.1% ng mga user sa loob ng 24 na oras. Ang Issues na may iisang paglitaw (< 0.01%) ay maaaring ipagpaliban hanggang sa susunod na naka-iskedyul na release. Awtomatikong minamarkahan ng Crashlytics ang mga regression — Issues na naayos na ngunit lumitaw muli sa bagong bersyon.

Pagsasama sa CI/CD

Ang Crashlytics API ay nagpapahintulot ng pagsasama ng mga ulat ng pagkasira sa CI/CD pipeline sa pamamagitan ng REST API o Firebase CLI. Sa bawat bagong release, maaaring awtomatikong suriin kung ang porsyento ng crash-free users ay hindi lumalagpas sa threshold. Kung lumagpas ang threshold — hinaharangan ng CI/CD ang pag-deploy at nagpapadala ng abiso sa team. Ang Firebase CLI ay sumusuporta sa command na firebase crashlytics:builds:upload para sa pag-upload ng ProGuard/R8 mapping file — kung wala ang mga ito, ang mga stack ay hindi mababasa.

Ayon sa datos ng Google (2026), ang mga application na gumagamit ng awtomatikong pagsusuri ng crash-free threshold sa CI/CD ay naglalabas ng 40% na mas kaunting regression sa produksyon. Inirerekomendang threshold: crash-free users >= 99.5% para sa mga kritikal na release at >= 99.0% para sa mga ordinaryong release.