Mobil ishlanmada Crash: nima, turlari va oldini olish usullari

Muallif: IT Sectr Nashr etilgan: 2026-03-29 O'qish vaqti: 9 daq

Crash — boshqarilmagan istisno yoki halokatli tizim xatosi tufayli mobil ilovaning favqulodda to'xtatilishi. Firebase Crashlytics ma'lumotlariga ko'ra, foydalanuvchilarning taxminan 2% har kuni buzilishlarga duch keladi va har bir buzilish retensionni 10–20% ga kamaytiradi. Sabablarni tushunish va buzilishlarning oldini olish usullari mobil dasturchi uchun majburiy mahoratdir.

Asosiy fikrlar

  • Crash — jarayonning favqulodda to'xtatilishiga olib keladigan boshqarilmagan istisno
  • NullPointerException — Java/Kotlin ilovalarida eng keng tarqalgan buzilish turi
  • Buzilish hisobotchilari stack trace, qurilma holati va foydalanuvchi ma'lumotlarini to'playdi
  • Firebase Crashlytics — mobil ishlanmada buzilishlarni kuzatish uchun standart vosita
  • Oldini olish xatolarni to'g'ri boshqarish, test qilish va null-xavfsizligini tekshirishni o'z ichiga oladi

Crash nima

Crash — bu ilova kodida boshqarilmagan istisno yoki halokatli tizim signali tufayli ilonaning favqulodda to'xtatilishidir. Tizim yoki virtual mashina (JVM, ART) halokatli holatni aniqlaganda — NullPointerException, IndexOutOfBoundsException, OutOfMemoryError — darhol jarayonni to'xtatadi va xotiradan chiqaradi. Foydalanuvchi hech qanday tizim xato bildirishnomasisiz ilovaning to'satdan yopilganini ko'radi. Google ma'lumotlariga ko'ra, crash-free darajasi 99% dan past bo'lgan ilovalar oyiga faol foydalanuvchilarning 20% gacha yo'qotadi.

Android da buzilishlarni boshqarish mexanizmi ish stoli tizimlaridan farq qiladi. Stack trace bilan tuzatish dialogi o'rniga Android shunchaki jarayonni o'ldiradi va batafsil ma'lumotni saqlamaydi. Buzilish haqida ma'lumot to'plash — jarayon tugashidan oldin Thread.setDefaultUncaughtExceptionHandler orqali istisnolarni tutadigan uchinchi tomon kutubxonalarining (Crashlytics, Sentry, Bugsnag) vazifasidir.

iOS halokatli xatolarni boshqarish uchun NSException va Mach exceptions bilan o'xshash mexanizmdan foydalanadi. Boshqarilmagan istisno holatida tizim ilovani tugatadi va hisobot .crash fayli shaklida saqlanadi. iOS da buzilishlarni to'plash Crashlytics bilan integratsiya yoki Xcode Organizer orqali o'rnatilgan hisobotni talab qiladi.

Buzilishlarning asosiy turlari

Besh kategoriya buzilish mobil ilovalardagi barcha buzilishlarning 90% ini qamrab oladi. Har bir turni tushunish ishlab chiqarish muhitida muammolarni tezroq tashxislash va tuzatishga yordam beradi.

NullPointerException — buzilishlar qiroli

NullPointerException (NPE) — barcha Java/Kotlin ilovalarida eng keng tarqalgan buzilish turi. Null bo'lgan ob'ektning metodini chaqirishga yoki maydoniga kirishga urinishda yuzaga keladi. Oddiy stsenariylar: ekranni aylantirishda Activity ning ishga tushirilmagan maydoni, JSON deserializatsiyasida serverdan null javob, RecyclerView adapteri orqali ehtiyotsiz navigatsiya.

Kotlin NPE muammosini til darajasida null-xavfsiz turlar orqali hal qiladi: String? aniq tekshiruvsiz ishlatilmaydi. Biroq, Java muvofiqligi va Reflection hali ham xavf tug'diradi. @NonNull va @Nullable annotatsiyalaridan foydalaning va statik tahlil vositalarida strictNullChecks ni yoqing.

kotlin
fun safeLength(text: String?): Int {
    return text?.length ?: 0 // null ni xavfsiz qayta ishlash
}

IndexOutOfBoundsException va to'plam xatolari

IndexOutOfBoundsException ro'yxat yoki massivning mavjud bo'lmagan indeksiga kirishda yuzaga keladi. Keng tarqalgan stsenariy: adapter bilan sinxronizatsiyasiz RecyclerView dan elementni o'chirish, blokirovkasiz ArrayList ni ko'p tarmoqli o'zgartirish, ViewPager da pozitsiyani noto'g'ri hisoblash. ConcurrentModificationException — to'plamlarni bir vaqtning o'zida takrorlash va o'zgartirishda yaqin qarindoshdir.

Ko'p tarmoqli kirish uchun CopyOnWriteArrayList yoki java.util.concurrent dan Lock-free to'plamlaridan foydalaning. UI bilan sinxronizatsiya uchun DiffUtil ni qo'llang, u eski va yangi ro'yxat orasidagi farqni xavfsiz va samarali hisoblaydi.

ClassCastException — tip muammolari

ClassCastException ob'ektni mos kelmaydian tipga o'tkazishda yuzaga keladi. Android da odatiy sabablar: RecyclerView da noto'g'ri ViewHolder tipi (to'g'ri getItemViewType holda turli hujayra turlari), navigatsiyada Fragment ni noto'g'ri o'tkazish, turli sinf versiyalariga ega Serializable ob'ektlar.

Kotlin ning xavfsiz o'tkazish operatori as? dan foydalaning, tip nomuvofiqligida null qaytaradi. Java da — o'tkazishdan oldin instanceof orqali tekshiring. Parcelable ob'ektlar uchun har bir sinfda CREATOR ni e'lon qilish majburiydir.

IllegalStateException va mantiqiy xatolar

IllegalStateException metodning ob'ektning mos kelmaydigan holatida chaqirilganini bildiradi. Android da odatiy misol — onSaveInstanceState dan keyin getSupportFragmentManager(), fragmentning commit() ruxsat etilmaganda. Yana bir keng tarqalgan holat — allaqachon yopilgan dialogda dismiss() chaqirish.

FragmentManager bilan operatsiyalardan oldin hayot aylanishi holatini tekshiring. commitAllowingStateLoss() dan faqat holat yo'qotilishi muhim emasligiga ishonchingiz komil bo'lganda foydalaning. Kotlin da tip darajasida noto'g'ri holatlarni istisno qiladigan DSL-ga o'xshash quruvchilar yarating.

Native Crash (SIGSEGV, SIGABRT signallari)

Native Crash C/C++ mahalliy kodida xotira buzilishida yuzaga keladi: null ko'rsatgich bilan ishlash, double-free, stek buferining toshishi. Android da bunday buzilishlar NDK kutubxonalarida, o'yin dvigatellarida (Unity, Unreal) va tizim bog'liqliklarida sodir bo'ladi. Native Crash Thread.setDefaultUncaughtExceptionHandler tomonidan TUTILMAYDI — jarayonni darhol o'ldiradi.

Mahalliy buzilishlarni tashxislash uchun minidump fayllari (Breakpad) yoki Android tombstone laridan foydalaning. Firebase Crashlytics NDK SDK orqali mahalliy buzilishlarni to'plashni qo'llab-quvvatlaydi. iOS da o'xshash muammo PLCrashReporter orqali hal qilinadi.

Buzilish hisoboti vositalari

Uch vosita mobil buzilish hisoboti bozorida hukmronlik qiladi. Har biri stack trace to'plash, ilova versiyalari bo'yicha agregatsiya va yangi buzilishlar haqida bildirishnomalarni ta'minlaydi.

Firebase Crashlytics

Crashlytics — Firebase ekotizimiga kiruvchi mobil ilovalar uchun eng mashhur buzilish hisobotidir. U avtomatik ravishda stack trace, qurilma ma'lumotlari, OT versiyasi va foydalanuvchining maxsus kalitlarini to'playdi. Integratsiya Firebase Console va Gradle Plugin orqali 10 daqiqa davom etadi. Crashlytics shuningdek real jurnallar (Logcat) va maxsus kuzatuvni qo'llab-quvvatlaydi.

kotlin
FirebaseCrashlytics.getInstance()
    .setCustomKey("current_screen", "ProfileFragment")

FirebaseCrashlytics.getInstance()
    .log("User tapped login button")

Sentry

Sentry — Crashlytics ga alternativa bo'lib, moslashuvchan filtrlash tizimi va 90+ platformani qo'llab-quvvatlaydi. Firebase dan farqli o'laroq, Sentry ma'lumotlarga qattiq talablarga ega kompaniyalar uchun o'z-o'zidan joylashtiriladigan server (self-hosted) ni taqdim etadi. Sentry distributiv kuzatuv, breadcrumbs va CI/CD quvurlari bilan integratsiyani qo'llab-quvvatlaydi.

Bugsnag va AppCenter

Bugsnag jiddiylikka asoslangan ogohlantirishlarni qo'llab-quvvatlash bilan ajralib turadi: buzilishlarni muhim, xato va ogohlantirishga ajratadi. Microsoft dan AppCenter — kichik loyihalar uchun asosiy funksionallikka ega bepul vosita. Ikkalasi ham Android, iOS, React Native va Flutter ni qo'llab-quvvatlaydi.

Buzilishni qanday tahlil qilish

Tahlil — sodir bo'lgan hodisaning to'liq manzarasini tiklash jarayoni. Stack trace faqat oxirgi muvaffaqiyatsizlik nuqtasini ko'rsatadi, ammo muammoga olib kelgan kontekstni bermaydi. Professional yondashuv to'rt bosqichni o'z ichiga oladi.

Birinchi bosqich — stack trace ni o'qish. Istisno sodir bo'lgan sinf, metod va kod qatorini aniqlang. Qo'ng'iroqlar zanjirini yuqori ramkadan pastga kuzatib boring: stekdagi oxirgi qator — buzilish joyi, yuqori qatorlar esa qo'ng'iroqlar ketma-ketligi. Deobfuskatsiya (ProGuard/R8 mapping) ishlab chiqarish qurilmalari uchun majburiydir.

Ikkinchi bosqich — qurilma konteksti. Crashlytics qurilma modelini, OT versiyasini, mavjud xotirani va ilova versiyasini ko'rsatadi. Masalan, faqat Samsung Galaxy S10 da Android 11 bilan sodir bo'lgan buzilish One UI ning muayyan versiyasi bilan muammoni ko'rsatadi, umumiy kod xatosini emas.

Uchinchi bosqich — test qurilmasida takrorlash. Agar buzilish barqaror takrorlanmasa, foydalanuvchidan aniq qadamlarni so'rang yoki muammoli kod qismidan oldin loglash uchun Remote Config dan foydalaning. AB-test auditoriyaning bir qismida tuzatishni sinab ko'rish yechimni tasdiqlashga yordam beradi.

To'rtinchi bosqich — tuzatishdan keyin kuzatish. Tuzatish nashr etilgandan so'ng, buzilish chastotasini 3-5 kun davomida kuzating. Agar buzilish butunlay yo'qolsa — tuzatish ishladi. Agar chastota kamaygan bo'lsa, lekin nolga tushmagan bo'lsa — alohida tahlil talab qiladigan ikkinchi stsenariy mavjud.

Buzilishlarning oldini olish amaliyotlari

Tizimli yondashuv buzilishlarning oldini olish statik tahlil vositalarini, chegara holatlarini majburiy test qilishni va ilonaning barcha darajalarida xatolarni to'g'ri boshqarishni o'z ichiga oladi.

Statik kod tahlili

Detekt (Kotlin) va Lint (Android) kompilyatsiya bosqichida potentsial muammolarni topadi: foydalanilmagan o'zgaruvchilar, potentsial NPE, API ni noto'g'ri ishlatish. Ushbu vositalarni CI quvurida xato chegarasi bilan yoqing. Masalan, Detekt 30+ ogohlantirish yoki har qanday error-blocking konfiguratsiyasi bilan qurilmani o'tkazmaydi.

Unit-testlar va UI-testlar

Qamrov asosiy foydalanish stsenariylarini unit-testlar bilan test qilish regressiv buzilishlardan asosiy himoyadir. Ma'lumot modellarini, ViewModel va UseCase qatlamlarini chegara holatlari bilan test qiling: null qiymatlar, bo'sh ro'yxatlar, noto'g'ri JSON. Espresso yoki Compose Test orqali UI-testlar muhim flowlarni qamrab oladi: avtorizatsiya, to'lov, onboarding.

Graceful Degradation

Ilovani shunday loyihalashtiringki, bir moduldagi nosozlik butun ekranni buzmasin. ViewModel darajasida catch bloklaridan zaxira holatini qaytarish bilan foydalaning: ro'yxat o'rniga placeholder ko'rsatish, tarmoq yo'qligida keshlangan ma'lumotlar, yuklash xatosida zaxira rasm. Bu potentsial buzilishni boshqariladigan UX stsenariysiga aylantiradi.

Kuzatuv bilan bosqichma-bosqich chiqarish

Staged rollouts — Google Play va App Store ning standart amaliyoti: yangi versiya avval 5%, keyin 20% va nihoyat 100% auditoriyaga 1-3 kun oralig'ida tarqatiladi. Har bir bosqichda buzilish chastotasi kuzatiladi: agar crash-free darajasi 99.5% dan pastga tushsa, chiqarish avtomatik to'xtatiladi. Firebase Remote Config muammoli funksiyalarni yangi versiya nashr etmasdan o'chirish imkonini beradi.

Bog'liqlik versiyalarini nazorat qilish

Renovate yoki Dependabot CI da kutubxonalarni ma'lum zaifliklar va muhim xatolar uchun avtomatik tekshiradi. Bitta bog'liqlikni yangilash butun bir buzilish sinfini bartaraf etishi mumkin. Biroq, yangilanishlarni ishlab chiqarishga chiqarishdan oldin staging muhitida sinab ko'ring — kutubxonaning yangi versiyasi mos kelmaydigan o'zgarishlarni o'z ichiga olishi mumkin.

Tez-tez beriladigan savollar

Buzilishlarning 100% oldini olish mumkinmi?

Yo'q. Buzilishlarning bir qismi dasturchi nazoratidan tashqari omillar tufayli yuzaga keladi: tizim xatolari, apparat muammolari, proshivka nomuvofiqligi. Maqsad chastotani 0.1% va undan pastga tushirish, qolgan buzilishlarni esa reaksiya vaqti bo'yicha minimalizatsiya qilish.

Buzilish hisobotchisi analitikadan nima bilan farq qiladi?

Buzilish hisobotchisi buzilish paytida stack trace, xotira holati va qurilma ma'lumotlarini to'playdi. Analitika foydalanuvchining xatti-harakatlari ma'lumotlarini to'playdi. Crashlytics ikkala yondashuvni birlashtirib, buzilish kontekstini foydalanuvchining maxsus kalitlari bilan ta'minlaydi.

Nega stack trace xiralashtirilgan?

ProGuard va R8 intellektual mulkni himoya qilish uchun kodni xiralashtiradi. Deobfuskatsiya uchun nashr paytida Crashlytics ga mapping faylini yuklang. Mapping faylisiz stack trace haqiqiy sinf va metod nomlari o'rniga a.a(), b.b() ko'rsatadi.

Buzilish hisobotchisi istisnolarni qanday tutadi?

Android da Thread.setDefaultUncaughtExceptionHandler orqali: kutubxona o'z ishlov beruvchisini ro'yxatdan o'tkazadi, u boshqarilmagan istisnoni birinchi bo'lib oladi, ma'lumotlarni saqlaydi va shundan keyingina jarayonni tugatadi. iOS da NSException uchun NSSetUncaughtExceptionHandler va signallar uchun Mach exception handler ishlatiladi.

Fatal va non-fatal buzilish nima?

Fatal — ilova tugadi. Non-fatal (tutilgan istisno) — dasturchi istisnoni try-catch orqali tutdi, ammo bu potentsial muammoni ko'rsatishi mumkin. Crashlytics bu turlarni farqlaydi va panelni ifloslantirmaslik uchun non-fatal ni alohida filtrlash imkonini beradi.

Xulosa

  • Crash — boshqarilmagan istisno yoki halokatli signal tufayli ilonaning favqulodda to'xtatilishi
  • NullPointerException mobil ilovalarda eng keng tarqalgan buzilish turi bo'lib qolmoqda
  • Firebase Crashlytics — ishlab chiqarishda buzilishlarni to'plash va tahlil qilish uchun standart vosita
  • Buzilish tahlili stack trace ni o'qish, qurilma konteksti va test muhitida takrorlashni o'z ichiga oladi
  • Statik tahlil (Detekt, Lint) kompilyatsiya bosqichida buzilishlarning bir qismini oldini oladi
  • Graceful degradation potentsial buzilishlarni zaxira ma'lumotlar bilan boshqariladigan stsenariylarga aylantiradi
  • Mapping fayllari ishlab chiqarish qurilmalarida stack trace ni deobfuskatsiya qilish uchun majburiydir

Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz

IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.

Loyihani muhokama qilish

Shuningdek o'qing