ANR în Android: ce este, cauze și metode de remediere

Ce este ANR în Android

ANR (Application Not Responding) — este un mecanism de protecție a utilizatorului în Android care se activează atunci când aplicația încetează să răspundă la intrări. Sistemul urmărește timpul de procesare a evenimentelor: dacă BroadcastReceiver nu finalizează onReceive în 10 secunde, Service nu revine din onCreate în 20 de secunde, iar ContentProvider nu răspunde în 15 secunde — Android generează ANR.

Cum arată ANR pentru utilizator

Când apare ANR, Android afișează un dialog de sistem deasupra tuturor ferestrelor: „Aplicația nu răspunde. Doriți să o închideți sau să așteptați?”. Utilizatorul poate închide aplicația sau poate aștepta recuperarea acesteia. Dacă ANR se repetă frecvent, utilizatorul șterge aplicația. Google Play ia în considerare rata ANR — procentul sesiunilor cu ANR — în algoritmii de clasare.

Diferența dintre ANR și înghețările pe iOS

Pe iOS nu există un echivalent al ANR cu dialog de sistem. În schimb, Apple folosește Watchdog, care termină procesul aplicației cu codul 0x8badf00d. Utilizatorul nu vede niciun dialog — aplicația se închide pur și simplu pe ecranul principal. Acest lucru face ca ANR pe Android să fie mai vizibil pentru utilizator, dar oferă sistemului mai multe informații pentru diagnostic.

Cauze principale ale ANR

ANR apare atunci când sistemul urmărește timeout-ul pentru unul dintre cele patru tipuri de componente. Fiecare componentă are propria limită de timp.

Blocarea în BroadcastReceiver

BroadcastReceiver se execută în thread-ul principal. Dacă onReceive lansează o cerere de rețea sincronă, o operație lungă de scriere în baza de date sau așteaptă o blocare — după 10 secunde apare ANR. Soluție: utilizați goAsync() și WorkManager pentru procesarea în fundal. Scenariu tipic — primirea unei notificări Push de la FCM și salvarea sincronă în Room.

Operație lungă în Service

Service.onCreate și Service.onStartCommand au o limită de 20 de secunde. Dacă serviciul lansează o inițializare grea (încărcarea bibliotecilor, citirea configurației din rețea) în thread-ul principal — ANR este inevitabil. Utilizați IntentService (învechit) sau WorkManager pentru execuția garantată în thread-ul de fundal.

ContentProvider cu inițializare lungă

ContentProvider.onCreate se execută înainte de apelul Application.onCreate și are o limită de 15 secunde. Dacă providerul execută migrarea bazei de date, încărcarea dicționarelor sau inițializarea SDK din rețea — acest lucru provoacă ANR la pornirea aplicației. Soluție: inițializare lazy, mutarea operațiilor grele în WorkManager.

• BroadcastReceiver — 10 secunde pentru onReceive; utilizați goAsync() pentru procesarea în fundal
• Service — 20 secunde pentru onCreate/onStartCommand; utilizați WorkManager sau CoroutineWorker
• ContentProvider — 15 secunde pentru onCreate; mutați inițializarea în Application.onCreate cu pornire întârziată
• Thread UI — 5 secunde fără procesarea evenimentelor; orice blocare mai lungă de 5 secunde provoacă ANR

Cum să diagnosticați ANR

Android oferă mai multe instrumente pentru analiza ANR: de la jurnale de sistem până la biblioteci specializate.

Analiza traces.txt

La fiecare ANR, Android salvează fișierul /data/anr/traces.txt cu dump-ul stivelor tuturor thread-urilor aplicației. Găsiți thread-ul „main” — ultima metodă din stivă indică cauza. Modele tipice: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Pentru extragerea fișierului de pe dispozitiv, utilizați adb cu drepturi de superutilizator.

Firebase Crashlytics cu rapoarte ANR

Firebase Crashlytics colectează automat ANR-urile și le afișează în dashboard împreună cu trasarea. Pentru Android 11+, rapoartele ANR vin cu stiva completă a thread-ului principal. Integrarea necesită adăugarea dependenței și inițializarea FirebaseApp în Application.onCreate.

Android Studio Profiler cu trasarea thread-urilor

CPU Profiler din Android Studio vă permite să înregistrați trasarea funcționării aplicației și să vedeți ce metode ocupă timp CPU. Activați „Record with method traces” și reproduceți scenariul care provoacă ANR. Pe axa temporală va fi vizibil ce metode se executau în thread-ul principal în momentul înghețării.

Exemplu de integrare Firebase Crashlytics pentru colectarea ANR pe Android:

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

Metode de remediere a ANR

Remedierea ANR înseamnă în primul rând mutarea tuturor operațiilor lungi din thread-ul principal în cele de fundal. Să analizăm tehnicile specifice pentru fiecare tip de componentă.

Utilizarea WorkManager pentru sarcini de fundal

WorkManager — soluția recomandată de Google pentru munca în fundal. Garantează execuția sarcinii în thread-ul de fundal ținând cont de starea dispozitivului. Spre deosebire de Service, WorkManager nu blochează thread-ul principal și este rezistent la repornirea aplicației. Pentru BroadcastReceiver, utilizați goAsync() și transmiteți rezultatul PendingResult către WorkManager.

Kotlin Coroutines cu dispatcheri corecți

Lansați toate cererile de rețea, lucrul cu baza de date și operațiile cu fișiere cu Dispatchers.IO. Thread-ul principal ar trebui să actualizeze doar UI. Utilizați viewModelScope pentru anularea automată a corutinelor la distrugerea Activity. Evitați runBlocking() în orice context — aceasta este o blocare sincronă a thread-ului curent.

Inițializarea lazy a ContentProvider

Dacă ContentProvider execută o inițializare lungă, utilizați mecanismul de încărcare întârziată: creați un provider care returnează datele imediat, iar inițializarea grea lansați-o prin WorkManager cu întârziere. Aceasta previne ANR la pornirea aplicației, când sistemul este cel mai sensibil la întârzieri.

Exemplu de utilizare corectă a BroadcastReceiver cu goAsync în Android:

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

Prevenirea ANR în dezvoltare

Cea mai bună modalitate de a lupta cu ANR este prevenirea apariției lor în faza de dezvoltare prin instrumente și soluții arhitecturale.

StrictMode pentru detectarea blocărilor thread-ului principal

StrictMode cu politicile detectNetwork() și detectDiskReads()/detectDiskWrites() activate detectează potențialele ANR în faza de dezvoltare. În compilarea Debug, setați penaltyDeath — orice încălcare va duce la o cădere imediată, iar dezvoltatorul va vedea problema înainte de commit.

Firebase Performance Monitoring pentru metrici de producție

Firebase Performance urmărește timpul de execuție al operațiilor cheie și arată care scenarii depășesc pragul ANR. Configurați trasări personalizate pentru fiecare ecran și cerere de rețea. Dacă timpul de execuție depășește 3 secunde — acesta este un ANR potențial care necesită optimizare.

Testarea cu întârzieri de rețea și disc

Simulați condiții lente: limitați viteza rețelei prin Network Link Conditioner pe iOS sau Android Emulator. Încetiniți citirea de pe disc prin emularea memoriei lente. ANR apare adesea tocmai în astfel de condiții, pe dispozitivele rapide ale dezvoltatorului nefiind vizibile.

• BroadcastReceiver — utilizați întotdeauna goAsync() pentru procesarea mai lungă de 1 secundă
• Service — înlocuiți cu WorkManager sau CoroutineWorker cu dispatcher de fundal
• ContentProvider — evitați rețeaua și baza de date în onCreate, utilizați lazy-init cu WorkManager
• Thread UI — StrictMode cu penaltyDeath în Debug, Firebase Performance pentru monitorizare în producție