ANR sa Android: ano ito, sanhi at mga paraan ng pag-aayos

Ano ang ANR sa Android

ANR (Application Not Responding) — ito ay isang mekanismo ng proteksyon ng gumagamit sa Android na na-activate kapag huminto ang application sa pagtugon sa input. Sinusubaybayan ng system ang oras ng pagproseso ng mga kaganapan: kung ang BroadcastReceiver ay hindi makumpleto ang onReceive sa loob ng 10 segundo, ang Service ay hindi bumalik mula sa onCreate sa loob ng 20 segundo, at ang ContentProvider ay hindi tumugon sa loob ng 15 segundo — bubuo ang Android ng ANR.

Paano lumilitaw ang ANR para sa gumagamit

Kapag naganap ang ANR, nagpapakita ang Android ng system dialog sa ibabaw ng lahat ng window: "Hindi Tumutugon ang Application. Isara o maghintay?". Maaaring isara ng gumagamit ang application o hintayin ang pagbawi nito. Kung madalas na umuulit ang ANR, tatanggalin ng gumagamit ang application. Isinasaalang-alang ng Google Play ang ANR rate — porsyento ng mga session na may ANR — sa mga algorithm ng pagraranggo.

Pagkakaiba ng ANR at pag-freeze sa iOS

Sa iOS, walang katumbas ng ANR na may system dialog. Sa halip, gumagamit ang Apple ng Watchdog na nagtatapos sa proseso ng application na may code na 0x8badf00d. Hindi nakikita ng gumagamit ang dialog — ang application ay basta na lang nagsasara sa pangunahing screen. Ginagawa nitong mas nakikita ang ANR sa Android para sa gumagamit, ngunit nagbibigay ito ng mas maraming impormasyon sa system para sa diagnosis.

Mga pangunahing sanhi ng ANR

Ang ANR ay nangyayari kapag sinusubaybayan ng system ang timeout para sa isa sa apat na uri ng mga component. Bawat component ay may sariling limitasyon sa oras.

Pagharang sa BroadcastReceiver

BroadcastReceiver ay isinasagawa sa pangunahing thread. Kung ang onReceive ay maglunsad ng isang synchronous network request, mahabang operasyon ng pagsulat sa database, o maghintay para sa isang pagharang — pagkatapos ng 10 segundo ay lilitaw ang ANR. Solusyon: gumamit ng goAsync() at WorkManager para sa pagproseso sa background. Karaniwang senaryo — pagtanggap ng Push notification mula sa FCM at synchronous na pag-save sa Room.

Mahabang operasyon sa Service

Service.onCreate at Service.onStartCommand ay may limitasyon na 20 segundo. Kung ang serbisyo ay maglunsad ng mabigat na pagsisimula (pag-load ng mga library, pagbabasa ng configuration mula sa network) sa pangunahing thread — hindi maiiwasan ang ANR. Gumamit ng IntentService (luma na) o WorkManager para sa garantisadong pagpapatupad sa background thread.

ContentProvider na may mahabang pagsisimula

ContentProvider.onCreate ay isinasagawa bago ang tawag sa Application.onCreate at may limitasyon na 15 segundo. Kung ang provider ay nagsasagawa ng database migration, pag-load ng mga diksyunaryo, o pagsisimula ng SDK mula sa network — ito ay nagdudulot ng ANR sa pagsisimula ng application. Solusyon: lazy-inisyalisasyon, paglipat ng mabibigat na operasyon sa WorkManager.

• BroadcastReceiver — 10 segundo para sa onReceive; gumamit ng goAsync() para sa background processing
• Service — 20 segundo para sa onCreate/onStartCommand; gumamit ng WorkManager o CoroutineWorker
• ContentProvider — 15 segundo para sa onCreate; ilipat ang pagsisimula sa Application.onCreate na may naantalang pagsisimula
• UI thread — 5 segundo nang walang pagproseso ng kaganapan; anumang pagharang na mas mahaba sa 5 segundo ay nagdudulot ng ANR

Paano i-diagnose ang ANR

Ang Android ay nagbibigay ng ilang mga tool para sa pagsusuri ng ANR: mula sa system logs hanggang sa mga espesyalisadong library.

Pagsusuri ng traces.txt

Sa bawat ANR, sine-save ng Android ang file na /data/anr/traces.txt na may dump ng mga stack ng lahat ng thread ng application. Hanapin ang thread na "main" — ang huling method sa stack ay nagpapahiwatig ng sanhi. Mga tipikal na pattern: Thread.sleep(), InputStream.read(), BinderProxy.transact(). Para kunin ang file mula sa device, gumamit ng adb na may mga karapatan ng superuser.

Firebase Crashlytics na may mga ulat ng ANR

Firebase Crashlytics ay awtomatikong nangongolekta ng ANR at ipinapakita ang mga ito sa dashboard kasama ng pagsubaybay. Para sa Android 11+, ang mga ulat ng ANR ay dumarating na may kumpletong stack ng pangunahing thread. Ang pagsasama ay nangangailangan ng pagdaragdag ng dependency at pagsisimula ng FirebaseApp sa Application.onCreate.

Android Studio Profiler na may pagsubaybay sa thread

CPU Profiler sa Android Studio ay nagpapahintulot sa iyo na mag-record ng pagsubaybay sa trabaho ng application at makita kung aling mga method ang kumukuha ng oras ng CPU. I-activate ang "Record with method traces" at i-reproduce ang senaryo na nagdudulot ng ANR. Sa timeline ay makikita kung aling mga method ang isinasagawa sa pangunahing thread sa sandali ng pag-freeze.

Halimbawa ng pagsasama ng Firebase Crashlytics para sa pagkolekta ng ANR sa Android:

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

Mga paraan ng pag-aayos ng ANR

Ang pag-aayos ng ANR ay pangunahing paglipat ng lahat ng mahabang operasyon mula sa pangunahing thread patungo sa mga background thread. Tingnan natin ang mga tiyak na teknik para sa bawat uri ng component.

Paggamit ng WorkManager para sa mga gawain sa background

WorkManager — ang inirerekomendang solusyon ng Google para sa trabaho sa background. Ginagarantiyahan nito ang pagpapatupad ng gawain sa background thread na isinasaalang-alang ang estado ng device. Hindi tulad ng Service, hindi hinaharangan ng WorkManager ang pangunahing thread at lumalaban sa pag-restart ng application. Para sa BroadcastReceiver, gumamit ng goAsync() at ipasa ang resulta na PendingResult sa WorkManager.

Kotlin Coroutines na may tamang dispatcher

Lunsarin ang lahat ng network request, trabaho sa database, at file operations na may Dispatchers.IO. Ang pangunahing thread ay dapat lamang mag-update ng UI. Gumamit ng viewModelScope para sa awtomatikong pagkansela ng mga coroutine kapag nawasak ang Activity. Iwasan ang runBlocking() sa anumang konteksto — ito ay isang synchronous na pagharang sa kasalukuyang thread.

Lazy-inisyalisasyon ng ContentProvider

Kung ang ContentProvider ay nagsasagawa ng mahabang pagsisimula, gumamit ng mekanismo ng naantalang pag-load: lumikha ng provider na agad na nagbabalik ng data, at patakbuhin ang mabigat na pagsisimula sa pamamagitan ng WorkManager na may pagkaantala. Ito ay pumipigil sa ANR sa pagsisimula ng application, kapag ang sistema ay pinaka-sensitive sa mga pagkaantala.

Halimbawa ng tamang paggamit ng BroadcastReceiver na may goAsync sa 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()
    }
}

Pag-iwas sa ANR sa pag-develop

Ang pinakamahusay na paraan upang labanan ang ANR ay pigilan ang kanilang paglitaw sa yugto ng pag-develop sa pamamagitan ng mga tool at solusyon sa arkitektura.

StrictMode para sa pagtuklas ng mga pagharang sa pangunahing thread

StrictMode na may mga naka-activate na patakaran na detectNetwork() at detectDiskReads()/detectDiskWrites() ay tumutuklas ng mga potensyal na ANR sa yugto ng pag-develop. Sa Debug build, itakda ang penaltyDeath — anumang paglabag ay hahantong sa agarang pag-crash, at makikita ng developer ang problema bago ang commit.

Firebase Performance Monitoring para sa mga metrika ng produksyon

Firebase Performance ay sumusubaybay sa oras ng pagpapatupad ng mga pangunahing operasyon at nagpapakita kung aling mga senaryo ang lumalampas sa threshold ng ANR. I-configure ang mga custom na pagsubaybay para sa bawat screen at network request. Kung ang oras ng pagpapatupad ay lumampas sa 3 segundo — ito ay isang potensyal na ANR na nangangailangan ng optimisasyon.

Pagsubok na may mga pagkaantala sa network at disk

Gayahin ang mabagal na kondisyon: limitahan ang bilis ng network sa pamamagitan ng Network Link Conditioner sa iOS o Android Emulator. Pabagalin ang pagbabasa mula sa disk sa pamamagitan ng emulasyon ng mabagal na memorya. ANR ay madalas na lilitaw sa mga ganitong kondisyon, sa mabilis na device ng developer ay hindi nakikita.

• BroadcastReceiver — palaging gumamit ng goAsync() para sa pagproseso na mas mahaba sa 1 segundo
• Service — palitan ng WorkManager o CoroutineWorker na may background dispatcher
• ContentProvider — iwasan ang network at database sa onCreate, gumamit ng lazy-init na may WorkManager
• UI thread — StrictMode na may penaltyDeath sa Debug, Firebase Performance para sa pagsubaybay sa produksyon