Tətbiqin crash-i: bu nədir, qəzaların səbəbləri və aşkarlama üsulları

Tətbiqin crash-i nədir

Crash — kodun işləmədiyi müstəsna vəziyyət nəticəsində proqramın gözlənilənməz şəkildə bağlanmasıdır. Mobil ƏS-lərdə crash tətbiqin dərhal bağlanmasına və “Tətbiq dayandırıldı” ekranının və ya ana ekrana qayıdışın göstərilməsinə səbəb olur.

Crash-lər iki böyük sinfə bölünür. İşlənmiş səhvlər — try/catch blokları istisnanı tətbiq edir, tətbiq işləməyə davam edir, ehtimal ki, funksionallıq itkisi ilə. İşlənməmiş crash-lər — istisna ƏS səviyyəsinə qədər yüksəlir və sistem prosesi öldürür. İkinci tip xüsusilə təhlükəlidir, çünki istifadəçi məlumatları saxlaya bilmir.

İki milyon istifadəçisi və 0,1% crash rate olan bir sistem hər buraxılışda 2 000 istifadəçi itirir. Google Play Console (2024) məlumatlarına görə, crash rate-i 1,5% -dən yüksək olan tətbiqlər tövsiyələrdən çıxarılır və üzvi trafikin 30% -ə qədərini itirir.

Mobil tətbiqlərdə qəzaların əsas səbəbləri

NullPointerException (NPE) — Java/Kotlin-də crash-lərin şahı. Null obyektdə metod çağırmaq cəhdi. Kotlin-də NPE null safety sayəsində daha az rast gəlinir, lakin !! operatorundan istifadə və ya Java kodu ilə qarşılıqlı əlaqədə hələ də mümkündür. Google (2024) qiymətləndirir: NPE Android tətbiqlərinin bütün crash-lərinin 25% -ni təşkil edir.

IndexOutOfBoundsException — siyahının mövcud olmayan indeksinə müraciət. Tez-tez səbəb: məlumatlar gözlənilənməz formatda serverdən gəlir və UI mövcud olmayan mövqeyi göstərməyə çalışır. Həll — indekslə əlaqə saxlamaqdan əvvəl həmişə kolleksiyanın ölçüsünü yoxla.

ANR (Application Not Responding) — Android-ə xas problem. UI thread-i 5 saniyədən çox bloklanır. Əsas səbəblər: əsas thread-də şəbək sorğuları, ağır hesablamalar, verilənlər bazası ilə sinxronizasiya. Android-də StrictMode inkişaf mərhələsində UI thread blokadalarını aşkarlamağa kömək edir.

OutOfMemoryError (OOM) — tətbiq yaddaş limitini keçdi. 2–4 GB RAM olan mobil cihazlarda OOM böyük şəkillər və ya səhifələmə olmadan sonsuz siyahılarla işləyərkən tez-tez rast gəlinən problemdir. Həll — şəkilləri yükləmək üçün Glide/Coil, keşləmə üçün LruCache, RecyclerView-dɘ ViewHolder.

Runtime exceptions və ölücül səhvlər

Runtime exceptions — kompilyatorun qurma mərhələsində yoxlamadığı səhvlər. Onlar yalnız xüsusi bir cihazda xüsusi məlumatlarla kodun icrası zamanı üzə çıxır. Java-da bunlar RuntimeException və onun alt sinifləridir: NullPointerException, IllegalArgumentException, ArithmeticException.

Ölücül səhvlər (FATAL) — runtime yox, sistem nasazlıqları. Signal 11 (SIGSEGV) — native kodda yaddaş seqmentasiyasının pozulması. Signal 6 (SIGABRT) — tətbiqin özü tərəfindən abort() vasitəsilə qəza nəticəsində bağlanması. Belə crash-ləri diaqnoz etmək çötin, çünki stack trace çox vaxt aydın kontekst göstərmir.

iOS-da əsas səbəblər NSInvalidArgumentException (parametrdə gözlənilənməz nil) və EXC_BAD_ACCESS (azad edilmiş yaddaşa giriş) dir. Swift Objective-C ilə müqayisədə crash-lərin sayını azaldıb, lakin ObjC runtime və C kitabxanalarındakı səhvlər hələ də qəzalara səbəb olur.

Crash-logların monitorinqi və toplanması

Firebase Crashlytics — mobil tətbiqlər üçün standart. Avtomatik olaraq stack trace toplayır, loglar, istifadəçi ID və cihaz metadata əlavə edir. Crash-ləri imza üzrə qruplaşdırır (səhv sinifi + sətir). Real-time alerts — crash rate müəyyən edilmiş həddi aşdıqda bildirişlər (məs. saatda >0,1%).

Sentry — daha çevik imkanları olan alternativ. Xüsusi kontekstlər yaratmağa, breadcrumbs əlavə etməyə, əhəmiyyətsiz səhvləri istisna etmək üçün in-app filtering konfiqurasiya etməyə imkan verir. Kotlin və Swift üçün Source maps gizlədilmiş adları deyil, mənbə kodunu görməyə imkan verir.

Loglar üçün best practices: təhlükəli əməliyyatı yerinə yetirməzdən əvvəl əsas metadatanı göndər — beləliklə, logda istifadəçinin crash-dan əvvəl nə etdiyi görünəcək. Custom keys əlavə edin (API versiya nömrəsi, son ekran, giriş məlumatlarının ölçüsü). Bu, faydasız stack trace-i fəaliyyətə yararlı məlumata çevirir.

Nümunə: Android-də Crashlytics-in qurulması

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

Crash-lərin qarşısını alma strategiyaları

Optional binding və null safety — Kotlin-də nullable tiplər üçün `?`, null-ın təhlükəsiz işlənməsi üçün `let` və `?:` istifadə edin. Swift-də — optionals və guard let. Modern Kotlin (2024) Contract annotasiyaları əlavə etdi: `@ContractsDsl` funksiyanın null qaytarmadığını bəyan etməyə imkan verir və kompilyator bunu yoxlayır.

Şəbəkədə səhv idarəetməsi — hər şəbək sorğusu timeout, pars xətalari və server imtinasını idarə etməlidir. Result tipi ilə Retrofit — səhvin idarə olunacağına zəmanət verən sealed class. No Exception stili: try/catch əvəzinə uğur və səhvi açıq şəkildə idarə etmək üçün sealed Result istifadə edin.

Feature flags — yeni versiya buraxmadan problemli funksionallığı uzaqdan söndürün. Server əməliyyatı köhnə cihazlarda crash-a səbəb olarsa, flag bu qrup üçün onu söndürür. Firebase Remote Config mağazada dərc etmədən tətbiqin davranışını dəyişməyə imkan verir.

Tədrici rollout — yeni versiyanı auditoriyanın 5% -də buraxın və crash rate-i izləyin. Rate hədəfdən aşağı qalırsa (adətən <0,1%), 25%, sonra 50%, sonra 100% -ə qədər genişləndirin. Google Play Console və App Store Connect hədd aşıldıqda avtomatik dayandırma üçün staged rollouts dəstəkləyir.

Səhv aşkar edildikdə fəaliyyət planı

Addım 1: Təsnifat — severity-i müəyyənləşdirin: Critical (>1% istifadəçilərdə crash), High (0,1–1%), Medium (<0,1%). Critical crash-lər üçün — dərhal cavab. Qalanları üçün — cari sprint-də standart bugfix prosesi. Google Play Console təsirlənmiş istifadəçilərin sayına görə crash-ləri avtomatik təsnif edir.

Addım 2: Stack trace-in təhlili — Crashlytics-də logu açın, qəzanın dəqiq yerini görün. Custom keys-i yoxlayın: hansı ekran, hansı məlumatlar, ƏS versiyası. Son yerləşdirmə ilə müqayisə edin — tez-tez crash gözlənilməyən istifadə ssenarisinə təsir edən koddakı təzə dəyişiklikdən qaynaqlanır.

Addım 3: Reproduksiya ‘— crash-i oxşar parametrləri olan cihazda və ya emulyatorda təkrarlamağa çalışın. Alınmazsa, crash log-u nümunələr üçün yoxlayın: konkret modellər (Samsung A10), Android versiyaları (API < 26), locale. Həll — ssenarini əhatə edən qoruyucu şərt əlavə edin.

Addım 4: Fix və monitorinq — prioritetlə hotfix buraxın. Buraxılışdan sonra bu tip üzrə crash rate-in sıfıra düşdüyünə əmin olun. Crash ssenarisini əhatə edən reqressiya testi yazın. Test olmadan eyni səhv növbəti refaktoringdə qayıda bilər.