Ilova crash-i: bu nima, chiqib ketish sabablari va ushlash usullari

Ilova crash-i nima

Crash — kod ishlov bermagan istisno holati tufayli dasturning kutilmagan tugatilishi. Mobil OTlarda crash dasturni darhol yopilishiga va “Ilova to‘xtatildi” ekrani yoki asosiy ekranga qaytishga olib keladi

Crash-lar ikkita katta sinfga bo‘linadi. Ishlov berilgan xatolar — try/catch bloklari istisnoni tutadi, ilova ishlashda davom etadi, ehtimol funksionallik yo‘qolishi bilan. Ishlov berilmagan crash-lar — istisno OT darajasigacha ko‘tariladi va tizim jarayonni o‘ldiradi. Ikkinchi tur ayniqsa xavfli, chunki foydalanuvchi ma'lumotlarni saqlay olmaydi.

Ikki million foydalanuvchisi va 0,1% crash rate bo‘lgan tizim har bir relizda 2 000 foydalanuvchini yo‘qotadi. Google Play Console (2024) ma'lumotlariga ko‘ra, crash rate 1,5% dan yuqori bo‘lgan ilovalar tavsiyalardan chiqariladi va organik trafikning 30% gacha yo‘qotadi.

Mobil ilovalarda chiqib ketishning asosiy sabablari

NullPointerException (NPE) — Java/Kotlin-da crash-larning shohi. Null obyektda metod chaqirishga urinish. Kotlin-da NPE null safety tufayli kamroq uchraydi, lekin hali ham !! operatoridan foydalanishda !! yoki Java kodi bilan o‘zaro aloqada mumkin. Google (2024) hisoblaydi: NPE Android ilovalarining barcha crash-larining 25% ni tashkil qiladi.

IndexOutOfBoundsException — mavjud bo‘lmagan indeks bo‘yicha ro‘yxat elementiga murojaat. Tez-tez sabab: ma'lumotlar serverdan kutilmagan formatda keladi va UI mavjud bo‘lmagan pozitsiyani ko‘rsatishga harakat qiladi. undefined — indeks bo‘yicha kirishdan oldin har doim kolleksiya hajmini tekshiring.

ANR (Application Not Responding) — Android-ga xos muammo. UI thread 5 soniyadan ko‘proq bloklanadi. Asosiy sabablar: asosiy threadda tarmoq so‘rovlari, og‘ir hisoblar, ma'lumotlar bazasi bilan sinxronizatsiya. StrictMode Android-da ishlab chiqish bosqichida UI thread bloklanishlarini aniqlashga yordam beradi.

OutOfMemoryError (OOM) — ilova xotira limitidan oshib ketdi. 2–4 GB RAM li mobil qurilmalarda OOM katta rasmlar yoki paginatsiyasiz cheksiz ro‘yxatlar bilan ishlashda tez-tez uchraydigan muammo. undefined — rasmlarni yuklash uchun Glide/Coil, keshlash uchun LruCache, RecyclerView-da ViewHolder.

Runtime exceptions va halokatli xatolar

Runtime exceptions — kompilyator qurish bosqichida tekshirmaydigan xatolar. Ular faqat ma'lum bir qurilmada ma'lum ma'lumotlar bilan kod bajarilganda namoyon bo‘ladi. Java-da bular RuntimeException va uning pastki sinflari: NullPointerException, IllegalArgumentException, ArithmeticException.

Halokatli xatolar (FATAL) — runtime emas, balki tizim nosozliklari. Signal 11 (SIGSEGV) — native kodda xotira segmentatsiyasining buzilishi. Signal 6 (SIGABRT) — ilovaning o‘zi tomonidan abort() orqali favqulodda tugatilishi. Bunday crash-larni diagnostika qilish qiyin, chunki stack trace ko‘pincha tushunarli kontekstni ko‘rsatmaydi.

iOS-da asosiy sabablar NSInvalidArgumentException (parametrda kutilmagan nil) va EXC_BAD_ACCESS (bo‘shatilgan xotiraga kirish). Swift Objective-C ga nisbatan crash-lar sonini kamaytirdi, ammo ObjC runtime va C kutubxonalaridagi xatolar hali ham nosozliklarga olib keladi.

Crash loglarini monitoring qilish va yig‘ish

Firebase Crashlytics — mobil ilovalar uchun standart. Avtomatik ravishda stack trace yig‘adi, loglar, foydalanuvchi ID va qurilma metama'lumotlarini qo‘shadi. Crash-larni imzo bo‘yicha guruhlaydi (xato sinfi + satr). Real-time alerts — crash rate belgilangan chegaradan oshganda bildirishnomalar (masalan, soatiga >0,1%).

Sentry — moslashuvchan imkoniyatlarga ega muqobil. Custom contexts yaratish, breadcrumbs qo‘shish, muhim bo‘lmagan xatolarni istisno qilish uchun in-app filtering sozlash imkonini beradi. Source maps Kotlin va Swift uchun manba kodini ko‘rish imkonini beradi, shifrlangan nomlarni emas.

Best practices loglar uchun: xavfli operatsiyani bajarishdan oldin asosiy metama'lumotlarni yuboring. Custom keys qo‘shing (API versiya raqami, oxirgi ekran, kirish ma'lumotlari hajmi). Bu foydasiz stack trace-ni harakatga yaroqli ma'lumotga aylantiradi.

Misol: Android-da Crashlytics sozlamasi

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 undefined null safety — Kotlin-da nullable turlar uchun `?`, xavfsiz null ishlov berish uchun `let` va `?:` dan foydalaning. Swift-da — optionals va guard let. Modern Kotlin (2024) Contract annotatsiyalarini qoshdi: @ContractsDsl funksiya null qaytarmasligini e‘lon qilish imkonini beradi va kompilyator buni tekshiradi.

Error handling undefined — har bir tarmoq so‘rovi timeout, pars xatolari va server rad etishini boshqarishi kerak. Retrofit undefined — xato boshqarilishini kafolatlaydigan sealed class. No Exception uslubi: try/catch o‘rniga muvaffaqiyat va xatoni aniq boshqarish uchun sealed Result dan foydalaning.

Feature flags — muammoli funksionallikni yangi versiya chiqarmasdan masofadan o‘chiring. Firebase Remote Config ilova harakatini do‘konda chop etmasdan o‘zgartirish imkonini beradi.

Bosqichma-bosqich chiqarish — yangi versiyani auditoriyaning 5% ga chiqaring va crash rate-ni kuzating. Agar rate maqsaddan past bo‘lsa (odatda <0,1%), 25%, keyin 50%, keyin 100% gacha kengaytiring. Google Play Console va App Store Connect chegara oshib ketganda avtomatik to‘xtatish uchun bosqichli chiqarishlarni qo‘llab-quvvatlaydi.

Xato aniqlanganda harakat rejasi

1: Tasniflash — severity-ni aniqlang: Critical (>1% foydalanuvchilarda crash), High (0,1–1%), Medium (<0,1%). Critical crash-lar uchun — zudlik bilan javob. Google Play Console crash-larni zarar ko‘rgan foydalanuvchilar soni bo‘yicha avtomatik tasniflaydi.

2: Stack trace tahlili — Crashlytics-da logni oching, nosozlikning aniq joyini ko‘ring. Custom keys-ni tekshiring: qaysi ekran, qanday ma'lumotlar, OT versiyasi. Oxirgi joylashtirish bilan solishtiring — ko‘pincha crash kutilmagan foydalanish stsenariysiga ta'sir qilgan koddagi yangi o‘zgarish tufayli yuzaga keladi.

3: Qayta tiklash — crash-ni o‘xshash parametrlarga ega qurilma yoki emulyatorda takrorlashga harakat qiling. Agar muvaffaqiyatsiz bo‘lsa, crash log-ni naqshlar bo‘yicha tekshiring: aniq modellar (Samsung A10), Android versiyalari (API < 26), locale. undefined — stsenariyni qamrab oluvchi himoya shartini qo‘shing.

4: Tuzatish va monitoring — hotfix-ni prioritet bilan chiqaring. Chiqarishdan so‘ng ushbu turdagi crash rate nolga tushishiga ishonch hosil qiling. Regressiya testini yozing crash stsenariysini qamrab oluvchi. Test bo‘lmasa, xuddi shu xato keyingi refaktoringda qaytishi mumkin.