Android中的ANR：它是什么、原因及解决方法

Android中的ANR是什么

ANR (Application Not Responding) — 是Android中的用户保护机制，当应用停止响应输入时激活。系统跟踪事件处理时间：如果BroadcastReceiver未在10秒内完成onReceive、Service未在20秒内从onCreate返回、ContentProvider未在15秒内响应——Android生成ANR。

ANR对用户的样子

当发生ANR时，Android在所有窗口之上显示系统对话框：“应用无响应。关闭还是等待？”用户可以关闭应用或等待其恢复。如果ANR频繁重复，用户将删除应用。Google Play在排序算法中考虑ANR率——有ANR的会话百分比。

ANR与iOS冻结的区别

iOS上没有带系统对话框的ANR对应物。相反，Apple使用Watchdog，它以代码0x8badf00d终止应用进程。用户看不到对话框——应用只是关闭到主屏幕。这使得Android上的ANR对用户更明显，但为系统提供了更多用于诊断的信息。

ANR的主要原因

当系统跟踪四种组件类型之一的超时时，就会发生ANR。每个组件都有自己的时间限制。

BroadcastReceiver中阻塞

BroadcastReceiver在主线程中执行。如果onReceive启动同步网络请求、长时间数据库写入操作或等待阻塞——10秒后出现ANR。解决方案：使用goAsync()和WorkManager进行后台处理。典型场景——从FCM接收推送通知并在Room中同步保存。

Service中的长时间操作

Service.onCreate和Service.onStartCommand有20秒的限制。如果服务在主线程中启动重型初始化（加载库、从网络读取配置）——ANR不可避免。使用IntentService（已过时）或WorkManager确保在后台线程中执行。

ContentProvider长时间初始化

ContentProvider.onCreate在调用Application.onCreate之前执行，有15秒的限制。如果提供程序执行数据库迁移、加载字典或从网络初始化SDK——这会在应用启动时引起ANR。解决方案：延迟初始化，将重型操作转移到WorkManager。

• BroadcastReceiver — onReceive有10秒；使用goAsync()进行后台处理
• Service — onCreate/onStartCommand有20秒；使用WorkManager或CoroutineWorker
• ContentProvider — onCreate有15秒；将初始化转移到Application.onCreate并延迟启动
• UI线程 — 5秒无事件处理；任何超过5秒的阻塞都会引起ANR

如何诊断ANR

Android提供了几种用于ANR分析的工具：从系统日志到专门的库。

分析traces.txt

每次ANR时，Android保存文件/data/anr/traces.txt，包含应用所有线程的堆栈转储。找到“main”线程——堆栈中的最后一个方法指示原因。典型模式：Thread.sleep()、InputStream.read()、BinderProxy.transact()。要从设备提取文件，请使用具有超级用户权限的adb。

Firebase Crashlytics与ANR报告

Firebase Crashlytics自动收集ANR并在仪表板中与跟踪一起显示。对于Android 11+，ANR报告随主线程的完整堆栈一起提供。集成需要添加依赖项并在Application.onCreate中初始化FirebaseApp。

Android Studio Profiler线程跟踪

Android Studio中的CPU Profiler允许您记录应用活动的跟踪，并查看哪些方法占用了CPU时间。启用“Record with method traces”并重现引起ANR的场景。在时间线上将看到冻结时刻主线程中执行了哪些方法。

Firebase Crashlytics集成以收集Android上ANR的示例：

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

修复ANR的方法

修复ANR主要是将所有长时间操作从主线程转移到后台线程。让我们看看每种组件类型的具体技术。

使用WorkManager处理后台任务

WorkManager — Google推荐的后台工作解决方案。它保证在后台线程中执行任务，同时考虑设备状态。与Service不同，WorkManager不会阻塞主线程，并且能够容忍应用重启。对于BroadcastReceiver，使用goAsync()并将结果PendingResult传递给WorkManager。

Kotlin Coroutines与正确的调度器

所有网络请求、数据库工作和文件操作使用Dispatchers.IO启动。主线程只能更新UI。使用viewModelScope在Activity销毁时自动取消协程。避免在任何上下文中使用runBlocking()——这是对当前线程的同步阻塞。

ContentProvider的延迟初始化

如果ContentProvider执行长时间初始化，请使用延迟加载机制：创建一个立即返回数据的提供程序，并通过WorkManager延迟启动重型初始化。这可以防止在应用启动时发生ANR，此时系统对延迟最敏感。

在Android中正确使用BroadcastReceiver与goAsync的示例：

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

开发中的ANR预防

对抗ANR的最佳方法是通过工具和架构解决方案在开发阶段防止它们的出现。

使用StrictMode检测主线程阻塞

启用detectNetwork()和detectDiskReads()/detectDiskWrites()策略的StrictMode在开发阶段检测潜在ANR。在Debug构建中设置penaltyDeath——任何违规都将导致立即崩溃，开发者在提交之前就会看到问题。

Firebase Performance Monitoring用于生产指标

Firebase Performance跟踪关键操作的执行时间，并显示哪些场景超过ANR阈值。为每个屏幕和网络请求配置自定义跟踪。如果执行时间超过3秒——这是需要优化的潜在ANR。

网络和磁盘延迟测试

模拟慢速条件：通过iOS或Android Emulator上的Network Link Conditioner限制网络速度。通过慢速内存模拟减慢磁盘读取。ANR经常在这样的条件下出现，在开发者的快速设备上不可见。

• BroadcastReceiver — 处理超过1秒时始终使用goAsync()
• Service — 使用WorkManager或带后台调度器的CoroutineWorker替代
• ContentProvider — 避免在onCreate中使用网络和数据库，使用带WorkManager的延迟初始化
• UI线程 — Debug中使用penaltyDeath的StrictMode，生产监控使用Firebase Performance