Android-də ANR: bu nədir, səbəbləri və aradan qaldırma üsulları

Android-də ANR nədir

ANR (Application Not Responding) — proqram girişə cavab verməyi dayandırdıqda işə düşən Android-də istifadəçi mühafizə mexanizmidir. Sistem hadisələrin işlənmə vaxtını izləyir: BroadcastReceiver 10 saniyə ərzində onReceive-i tamamlamazsa, Service 20 saniyə ərzində onCreate-dən qayıtmazsa, ContentProvider isə 15 saniyə ərzində cavab verməzsə — Android ANR yaradır.

ANR istifadəçi üçün necə görünür

ANR baş verdikdə, Android bütün pəncərələrin üzərində sistem dialoqu göstərir: «Proqram cavab vermir. Onu bağlamaq və ya gözləmək?». İstifadəçi proqramı bağlaya və ya onun bərpasını gözləyə bilər. ANR tez-tez təkrarlanırsa, istifadəçi proqramı silir. Google Play sıralama alqoritmlərində ANR dərəcəsini — ANR olan sessiyaların faizini — nəzərə alır.

ANR ilə iOS-dakı donmalar arasındakı fərq

iOS-da sistem dialoqu olan ANR analoqu yoxdur. Bunun əvəzinə Apple Watchdog istifadə edir, o, proqramı 0x8badf00d kodu ilə bağlayır. İstifadəçi dialoq görmür — proqram sadəcə əsas ekrana bağlanır. Bu, ANR-ni Android-də istifadəçi üçün daha nəzərə çarpan edir, lakin diaqnostika üçün sistemə daha çox məlumat verir.

ANR-nin əsas səbəbləri

ANR dörd komponent növündən biri üçün vaxt limiti izlənildikdə baş verir. Hər komponentin öz vaxt limiti var.

BroadcastReceiver-də bloklanma

BroadcastReceiver əsas axında işləyir. onReceive sinxron şəbəkə sorğusu, verilənlər bazasına uzun yazma əməliyyatı və ya bloklanmanı gözləyirsə — 10 saniyədən sonra ANR yaranır. Həll yolu: fon emalı üçün goAsync() və WorkManager istifadə edin. Tipik ssenari — FCM-dən Push bildirişi almaq və Room-da sinxron yazmaq.

Service-də uzun əməliyyat

Service.onCreate və Service.onStartCommand 20 saniyə limitinə malikdir. Xidmət əsas axında ağır inisiallaşdırma (kitabxanaların yüklənməsi, şəbəkədən konfiqurasiyanın oxunması) işə salırsa — ANR qaçılmazdır. Fon axınında zəmanətli icra üçün IntentService (köhnəlmiş) və ya WorkManager istifadə edin.

Uzun inisiallaşdırma ilə ContentProvider

ContentProvider.onCreate Application.onCreate çağırışından əvvəl işləyir və 15 saniyə limitinə malikdir. Provayder verilənlər bazası miqrasiyası, lüğətlərin yüklənməsi və ya şəbəkədən SDK inisiallaşdırması həyata keçirirsə — bu, proqram işə salındıqda ANR-yə səbəb olur. Həll yolu: lazy-inisiallaşdırma, ağır əməliyyatların WorkManager-ə köçürülməsi.

• BroadcastReceiver — onReceive üçün 10 saniyə; fon emalı üçün goAsync() istifadə edin
• Service — onCreate/onStartCommand üçün 20 saniyə; WorkManager və ya CoroutineWorker istifadə edin
• ContentProvider — onCreate üçün 15 saniyə; inisiallaşdırmanı gecikmiş başlatma ilə Application.onCreate-ə köçürün
• UI axını — hadisələrin işlənməsi olmadan 5 saniyə; 5 saniyədən uzun hər hansı bloklanma ANR-yə səbəb olur

ANR-ni necə diaqnostika etmək olar

Android sistem jurnallarından xüsusi kitabxanalara qədər ANR analizi üçün bir neçə alət təqdim edir.

traces.txt analizi

Hər ANR zamanı Android /data/anr/traces.txt faylını proqramın bütün axınlarının yığın atqısı ilə saxlayır. «Main» axınını tapın — yığındakı son metod səbəbi göstərir. Tipik nümunələr: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Faylı cihazdan çıxarmaq üçün superistifadəçi hüquqları ilə adb istifadə edin.

ANR hesabatları ilə Firebase Crashlytics

Firebase Crashlytics avtomatik olaraq ANR-ləri toplayır və onları izləmə ilə birlikdə panelində göstərir. Android 11+ üçün ANR hesabatları əsas axının tam yığını ilə gəlir. İnteqrasiya asılılığın əlavə edilməsini və Application.onCreate-də FirebaseApp inisiallaşdırmasını tələb edir.

Android Studio Profiler axın izləmə ilə

CPU Profiler Android Studio-da proqramın işini izləməyə və hansı metodların prosessor vaxtı apardığını görməyə imkan verir. «Record with method traces»-i aktivləşdirin və ANR-yə səbəb olan ssenarini təkrarlayın. Zaman qrafikində donma anında əsas axında hansı metodların icra olunduğu görünəcək.

Android-də ANR toplanması üçün Firebase Crashlytics inteqrasiyası nümunəsi:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        FirebaseCrashlytics.getInstance()
            .setCrashlyticsCollectionEnabled(true)
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build())
    }
}

ANR-nin aradan qaldırılması üsulları

ANR-nin aradan qaldırılması, ilk növbədə, bütün uzun əməliyyatların əsas axından fon axınlarına köçürülməsidir. Hər komponent növü üçün konkret texnikaları nəzərdən keçirək.

Fon tapşırıqları üçün WorkManager istifadəsi

WorkManager — Google tərəfindən fon işi üçün tövsiyə edilən həll yoludur. O, cihazın vəziyyətini nəzərə alaraq tapşırığın fon axınında icrasına zəmanət verir. Service-dən fərqli olaraq, WorkManager əsas axını bloklamır və proqramın yenidən başladılmasına davamlıdır. BroadcastReceiver üçün goAsync() istifadə edin və nəticəni PendingResult-i WorkManager-ə ötürün.

Düzgün dispetçerlərlə Kotlin Coroutines

Bütün şəbəkə sorğularını, verilənlər bazası ilə işi və fayl əməliyyatlarını Dispatchers.IO ilə işə salın. Əsas axın yalnız UI-ni yeniləməlidir. Activity məhv edildikdə korutinlərin avtomatik ləğvi üçün viewModelScope istifadə edin. İstənilən kontekstdə runBlocking()-dən çəkinin — bu, cari axının sinxron bloklanmasıdır.

ContentProvider-in Lazy-inisiallaşdırması

ContentProvider uzun inisiallaşdırma həyata keçirirsə, gecikmiş yükləmə mexanizmindən istifadə edin: dərhal məlumat qaytaran provayder yaradın, ağır inisiallaşdırmanı isə WorkManager vasitəsilə gecikmə ilə işə salın. Bu, sistemin gecikmələrə ən həssas olduğu proqram işə salınarkən ANR-nin qarşısını alır.

Android-də goAsync ilə BroadcastReceiver-dən düzgün istifadə nümunəsi:

class FcmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        val pendingResult = goAsync()
        WorkManager.getInstance(context!!)
            .enqueue(OneTimeWorkRequest.from(NotificationWorker::class.java))
        pendingResult.finish()
    }
}

İşləmə zamanı ANR profilaktikası

ANR ilə mübarizənin ən yaxşı yolu onların işləmə mərhələsində alətlər və memarlıq həlləri vasitəsilə qarşısını almaqdır.

Əsas axın bloklanmalarının aşkarlanması üçün StrictMode

StrictMode detectNetwork() və detectDiskReads()/detectDiskWrites() siyasətləri aktivləşdirilmiş şəkildə işləmə mərhələsində potensial ANR-ləri aşkarlayır. Debug quruluşunda penaltyDeath təyin edin — hər hansı pozuntu dərhal çökməyə səbəb olacaq və tərtibatçı təsdiqləmədən əvvəl problemi görəcək.

İstehsalat metrikaları üçün Firebase Performance Monitoring

Firebase Performance əsas əməliyyatların icra müddətini izləyir və hansı ssenarilərin ANR həddini aşdığını göstərir. Hər ekran və şəbəkə sorğusu üçün fərdi izləmə konfiqurasiya edin. İcra müddəti 3 saniyədən çox olarsa — bu, optimallaşdırma tələb edən potensial ANR-dir.

Şəbəkə və disk gecikmələri ilə sınaq

Yavaş şərtləri simulyasiya edin: iOS və ya Android Emulator-da Network Link Conditioner vasitəsilə şəbəkə sürətini məhdudlaşdırın. Yavaş yaddaş emulyasiyası vasitəsilə diskdən oxumanı yavaşladın. ANR tez-tez məhz belə şəraitdə özünü göstərir, tərtibatçının sürətli cihazlarında görünməzdir.

• BroadcastReceiver — 1 saniyədən uzun emal üçün həmişə goAsync() istifadə edin
• Service — WorkManager və ya fon dispetçeri ilə CoroutineWorker ilə əvəz edin
• ContentProvider — onCreate-də şəbəkə və verilənlər bazasından çəkinin, WorkManager ilə lazy-init istifadə edin
• UI axını — Debug-da penaltyDeath ilə StrictMode, istehsalat monitorinqi üçün Firebase Performance