Alkalmazás crash: mi ez, a kidobások okai és észlelési módszerek

Mi az alkalmazás crash

Crash — a program váratlan leállása egy kivételes helyzet miatt, amelyet a kód nem kezelt. Mobil operációs rendszerekben a crash az alkalmazás azonnali bezárásához és a „Alkalmazás leállt“ képernyő megjelenítéséhez vagy a kezdőképernyőre való visszatéréshez vezet.

A crashek két nagy osztályba sorolhatók. Kezelt hibák — a try/catch blokkok elkapják a kivételt, az alkalmazás tovább működik, esetleg funkcionalitásvesztéssel. Nem kezelt crashek — a kivétel az operációs rendszer szintjéig terjed, és a rendszer megöli a folyamatot. A második típus különösen veszélyes, mert a felhasználó nem tudja menteni az adatokat.

Egy kétmillió felhasználós és 0,1%-os crash rate-tel rendelkező rendszer 2 000 felhasználót veszít minden kiadásnál. A Google Play Console (2024) szerint az 1,5% feletti crash rate-tel rendelkező alkalmazásokat kizárják az ajánlásokból, és akár 30%-os organikus forgalmat veszítenek.

A kidobások fő okai mobilalkalmazásokban

NullPointerException (NPE) — a crashek királya Java/Kotlinban. Metódus hívása null objektumon. Kotlinban az NPE ritkább a null safety miatt, de továbbra is lehetséges a !! operátor használatakor vagy Java kóddal való interakció során. Google (2024) becslése szerint: az NPE az Android-alkalmazások összes crashének 25%-át teszi ki.

IndexOutOfBoundsException — hozzáférés egy listaelemhez nem létező indexszel. Gyakori ok: az adatok váratlan formátumban érkeznek a szervertől, és a UI megpróbál megjeleníteni egy nem létező pozíciót. Megoldás — mindig ellenőrizd a gyűjtemény méretét, mielőtt indexen keresztül hozzáférsz.

ANR (Application Not Responding) — Android-specifikus probléma. Az UI szál több mint 5 másodpercig blokkolva van. Fő okok: hálózati kérések a főszálon, nehéz számítások, szinkronizálás az adatbázissal. StrictMode Androidban segít az UI szál blokkolásának észlelésében a fejlesztési szakaszban.

OutOfMemoryError (OOM) — az alkalmazás túllépte a memóriakorlátot. 2–4 GB RAM-mal rendelkező mobileszközökön az OOM gyakori probléma nagy képek vagy végtelen listák lapozás nélküli kezelésekor. Megoldás — Glide/Coil a képek betöltéséhez, LruCache a gyorsítótárazáshoz, ViewHolder a RecyclerView-ben.

Runtime kivételek és végzetes hibák

Runtime exceptions — hibák, amelyeket a fordító nem ellenőriz a build szakaszban. Csak egy adott eszközön, adott adatokkal történő kódvégrehajtáskor jelennek meg. Java-ban ezek RuntimeException és alosztályai: NullPointerException, IllegalArgumentException, ArithmeticException.

Végzetes hibák (FATAL) — nem runtime, hanem rendszerhibák. Signal 11 (SIGSEGV) — memóriaszegmentáció megsértése natív kódban. Signal 6 (SIGABRT) — az alkalmazás által az abort() segítségével okozott vészhelyzeti leállás. Az ilyen crasheket nehéz diagnosztizálni, mert a stack trace gyakran nem mutat érthető kontextust.

iOS-ben a fő okok NSInvalidArgumentException (váratlan nil paraméterben) és EXC_BAD_ACCESS (hozzáférés felszabadított memóriához). A Swift csökkentette a crashek számát az Objective-C-hez képest, de az ObjC futásidejű és C könyvtári hibák továbbra is leállásokhoz vezetnek.

Crash logok monitorozása és gyűjtése

Firebase Crashlytics — a mobilalkalmazások szabványa. Automatikusan gyűjti a stack trace-t, hozzáadja a naplókat, felhasználói azonosítót és eszköz metaadatokat. A crasheket aláírás szerint csoportosítja (hibaosztály + sor). Real-time alerts — értesítések, amikor a crash rate meghalad egy beállított küszöböt (pl. >0,1% óránként).

Sentry — egy rugalmasabb képességekkel rendelkező alternatíva. Lehetővé teszi egyéni kontextusok létrehozását, breadcrumbok hozzáadását, alkalmazáson belüli szűrés beállítását a nem fontos hibák kizárásához. Source maps Kotlin és Swift esetén lehetővé teszik a forráskód megtekintését, nem az elhomályosított neveket.

Best practices naplókhoz: küldj kulcsfontosságú metaadatokat a veszélyes művelet végrehajtása előtt. Adj hozzá egyéni kulcsokat (API verziószám, utolsó képernyő, bemeneti adatok mérete). Ez a használhatatlan stack trace-t használható információvá alakítja.

Példa: Crashlytics beállítása Androidban

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 és null safety — Kotlinban használj `?`-t nullable típusokhoz, `let`-et és `?:`-t a null biztonságos kezeléséhez. Swift-ben — optionals és guard let. Modern Kotlin (2024) hozzáadta a Contract annotációkat: a @ContractsDsl lehetővé teszi annak deklarálását, hogy egy függvény nem ad vissza null-t, és a fordító ezt ellenőrzi.

Error handling hálózatban — minden hálózati kérésnek kezelnie kell az időtúllépést, a feldolgozási hibákat és a szerver elutasítását. Retrofit Result típussal — egy sealed class, amely garantálja, hogy a hiba kezelésre kerül. No Exception stílus: try/catch helyett használj sealed Result-ot a siker és hiba explicit kezeléséhez.

Feature flags — kapcsold ki a problémás funkcionalitást távolról anélkül, hogy új verziót adnál ki. Firebase Remote Config lehetővé teszi az alkalmazás viselkedésének megváltoztatását a boltban történő közzététel nélkül.

Fokozatos bevezetés — add ki az új verziót a közönség 5%-ának, és figyeld a crash rate-t. Ha a rate a cél alatt marad (általában <0,1%), bővítsd 25%-ra, majd 50%-ra, majd 100%-ra. Google Play Console és az App Store Connect támogatja a szakaszos bevezetéseket a küszöbérték túllépése esetén történő automatikus leállításhoz.

Teendők hiba észlelésekor

1: Osztályozás — határozd meg a súlyosságot: Critical (crash a felhasználók >1%-ánál), High (0,1–1%), Medium (<0,1%). Critical crashek esetén — azonnali válasz. A Google Play Console automatikusan osztályozza a crasheket az érintett felhasználók száma alapján.

2: Stack trace elemzés — nyisd meg a naplót a Crashlytics-ben, nézd meg a hiba pontos helyét. Ellenőrizd az egyéni kulcsokat: melyik képernyő, milyen adatok, OS verzió. Hasonlítsd össze az utolsó telepítéssel — gyakran a crash-t a kód friss változtatása okozza, amely egy váratlan használati forgatókönyvet érintett.

3: Reprodukálás — próbáld reprodukálni a crash-t egy hasonló paraméterekkel rendelkező eszközön vagy emulátoron. Ha nem sikerül, ellenőrizd a crash naplót mintákra: konkrét modellek (Samsung A10), Android verziók (API < 26), locale. Megoldás — adj hozzá egy védőfeltételt, amely lefedi a forgatókönyvet.

4: Javítás és monitorozás — adj ki hotfix-et prioritással. A kiadás után győződj meg arról, hogy a crash rate erre a típusra nullára csökken. Írj regressziós tesztet amely lefedi a crash forgatókönyvet. Teszt nélkül ugyanaz a hiba visszatérhet a következő refaktoráláskor.