Crash ng app: ano ito, mga sanhi ng pag-crash at mga paraan ng pag-detect

Ano ang crash ng app

Crash — hindi inaasahang pagtatapos ng programa sanhi ng isang exception na hindi na-handle ng code. Sa mobile OS, ang crash ay nagdudulot ng agarang pagsasara ng app at pagpapakita ng screen na “App ay huminto” o pagbabalik sa home screen.

Ang mga crash ay nahahati sa dalawang malaking klase. Na-handle na error — hinuhuli ng try/catch blocks ang exception, nagpapatuloy ang app, posible na may pagkawala ng functionality. Hindi na-handle na crash — umaakyat ang exception hanggang sa level ng OS at pinapatay ng system ang process. Ang ikalawang uri ay lubhang mapanganib dahil hindi mai-save ng user ang data.

Ang system na may dalawang milyong user at 0.1% crash rate ay nawawalan ng 2,000 user sa bawat release. Ayon sa Google Play Console (2024), ang mga app na may crash rate na higit sa 1.5% ay hindi kasama sa rekomendasyon at nawawalan ng hanggang 30% ng organic traffic.

Mga pangunahing sanhi ng pag-crash sa mobile apps

NullPointerException (NPE) — hari ng crash sa Java/Kotlin. Pagtawag ng method sa null object. Sa Kotlin, mas bihira ang NPE dahil sa null safety, ngunit posible pa rin gamit ang operator !! o pakikipag-ugnayan sa Java code. tantiya: NPE ay 25% ng lahat ng crash ng Android apps.

IndexOutOfBoundsException — pag-access sa list element na may hindi umiiral na index. Karaniwang sanhi: ang data ay galing sa server sa hindi inaasahang format at sinusubukan ng UI na magpakita ng posisyong wala. Solusyon — laging suriin ang laki ng collection bago mag-access sa pamamagitan ng index.

ANR (Application Not Responding) — problemang spesipiko sa Android. Ang UI thread ay naka-block ng higit sa 5 segundo. Pangunahing sanhi: network requests sa main thread, mabibigat na kalkulasyon, synchronization sa database. StrictMode sa Android tumutulong na matukoy ang pag-block ng UI thread sa yugto ng development.

OutOfMemoryError (OOM) — nalampasan ng app ang limitasyon ng memory. Sa mobile devices na may 2–4 GB RAM, karaniwan ang OOM sa pagtatrabaho sa malalaking larawan o walang katapusang listahan nang walang pagination. Solusyon — Glide/Coil para sa pag-load ng larawan, LruCache para sa caching, ViewHolder sa RecyclerView.

Runtime exceptions at fatal error

Runtime exceptions — mga error na hindi nache-check ng compiler sa build stage. Lumalabas lamang ang mga ito sa pag-execute ng code sa isang partikular na device na may partikular na data. Sa Java, ito ay RuntimeException at mga subclass nito: NullPointerException, IllegalArgumentException, ArithmeticException.

Fatal error (FATAL) — hindi runtime, kundi system failures. Signal 11 (SIGSEGV) — paglabag sa memory segmentation sa native code. Signal 6 (SIGABRT) — emergency na pagtatapos na dulot ng app mismo sa pamamagitan ng abort(). Mahirap i-diagnose ang mga ganitong crash dahil ang stack trace ay madalas na hindi nagpapakita ng naiintindihang konteksto.

Sa iOS, ang mga pangunahing sanhi ay NSInvalidArgumentException (hindi inaasahang nil sa parameter) at EXC_BAD_ACCESS (pag-access sa freed memory). Binawasan ng Swift ang bilang ng crash kumpara sa Objective-C, ngunit ang mga error sa ObjC runtime at C libraries ay nagdudulot pa rin ng pag-crash.

Monitoring at koleksyon ng crash logs

Firebase Crashlytics — ang standard para sa mobile apps. Awtomatikong nangongolekta ng stack trace, nagdaragdag ng logs, user ID, at device metadata. Nag-grupo ng crash ayon sa signature (error class + line). Real-time alerts — mga notification kapag ang crash rate ay lumampas sa itinakdang threshold (hal. >0.1% bawat oras).

Sentry — alternatibo na may mas flexible na kakayahan. Pinapayagan ang paggawa ng custom contexts, pagdagdag ng breadcrumbs, pag-configure ng in-app filtering para i-exclude ang hindi importanteng error. Source maps para sa Kotlin at Swift ay nagbibigay-daan na makita ang source code, hindi ang obfuscated names.

Best practices para sa logs: magpadala ng mahahalagang metadata bago magsagawa ng mapanganib na operasyon. Magdagdag ng custom keys (numero ng API version, huling screen, laki ng input data). Ginagawa nitong kapaki-pakinabang na impormasyon ang walang kwentang stack trace.

Halimbawa: pag-setup ng Crashlytics sa Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

undefined

Optional binding at null safety — sa Kotlin gamitin ang `?` para sa nullable types, `let` at `?:` para sa safe na pag-handle ng null. Sa Swift — optionals at guard let. Modern Kotlin (2024) nagdagdag ng Contract annotations: ang @ContractsDsl ay nagpapahintulot na ideklara na ang function ay hindi nagbabalik ng null, at ito ay nire-check ng compiler.

Error handling sa network — bawat network request ay dapat mag-handle ng timeout, parsing errors, at pagtanggi ng server. Retrofit na may Result type — isang sealed class na ginagarantiyang mahahandle ang error. No Exception style: sa halip na try/catch, gumamit ng sealed Result para sa explicit na pag-handle ng tagumpay at error.

Feature flags — i-disable ang problematikong functionality nang malayuan nang hindi nagrerelease ng bagong version. Firebase Remote Config nagbibigay-daan na baguhin ang behavior ng app nang walang publikasyon sa store.

Unti-unting pag-release — i-release ang bagong version sa 5% ng audience at subaybayan ang crash rate. Kung mananatiling mababa ang rate sa target (karaniwang <0.1%), palawakin sa 25%, pagkatapos 50%, pagkatapos 100%. Google Play Console at App Store Connect ay sumusuporta sa staged rollouts para sa automatic na paghinto kapag nalampasan ang threshold.

Plano ng aksyon sa pagtuklas ng error

1: Pag-uuri — tukuyin ang severity: Critical (crash sa >1% ng users), High (0.1–1%), Medium (<0.1%). Para sa Critical crash — agarang tugon. Awtomatikong inuuri ng Google Play Console ang crash ayon sa bilang ng apektadong user.

2: Stack trace analysis — buksan ang log sa Crashlytics, tingnan ang eksaktong lokasyon ng failure. Suriin ang custom keys: anong screen, anong data, OS version. Ikumpara sa huling deployment — kadalasan ang crash ay sanhi ng bagong pagbabago sa code na nakaapekto sa hindi inaasahang scenario ng paggamit.

3: Reproduction — subukang i-reproduce ang crash sa device o emulator na may katulad na parameter. Kung hindi magtagumpay, suriin ang crash log para sa patterns: specific models (Samsung A10), Android versions (API < 26), locale. Solusyon — magdagdag ng protective condition na sumasaklaw sa scenario.

4: Fix at monitoring — mag-release ng hotfix na may priyoridad. Pagkatapos ng release, tiyaking bumaba sa zero ang crash rate para sa ganitong uri. Sumulat ng regression test na sumasaklaw sa crash scenario. Kapag walang test, ang parehong bug ay maaaring bumalik sa susunod na refactoring.