什么是ANR？怎么样分析ANR？常见ANR场景及解决方案？

ANR，即"应用程序无响应"，是Android开发中最常见的性能问题之一。要解决ANR，关键是理解其成因，掌握分析方法，并针对不同场景进行优化。

📋 什么是ANR？

ANR (Application Not Responding) 是Android系统的一种保护机制：当App的界面线程（又称主线程，负责处理用户交互和界面更新）被阻塞太久，系统就会弹出一个对话框，提示用户"等待"或"强制关闭"。

ANR 类型	超时场景	常见超时阈值
Input ANR	5秒内未响应屏幕点击、按键等输入事件。这是最常见的类型。	5秒
BroadcastReceiver ANR	前台广播的 `onReceive()` 方法耗时过长。前台广播和后台广播的超时阈值不同。	前台10秒 / 后台60秒
Service ANR	服务启动或执行关键操作耗时过长。	前台20秒 / 后台200秒
ContentProvider ANR	`ContentProvider` 的 `publish()` 操作超时。	10秒

请注意，超时阈值在不同厂商、不同版本的设备上可能存在细微差别。

🕵️‍♂️ 如何分析ANR？

分析ANR的核心是查看系统生成的trace文件，它记录了ANR发生瞬间所有线程的调用堆栈、CPU和内存状态等信息，是定位问题的"黑匣子"。

第一步：获取原始日志 通过adb命令导出/data/anr/目录下的Trace文件。

bash 复制代码

# 方法1: 直接获取文件内容（部分设备权限不足时会失败）
adb shell cat /data/anr/traces.txt > anr_trace.txt

# 方法2: 先将文件复制到可访问目录再pull（成功率更高）
adb shell cp /data/anr/traces.txt /sdcard/
adb pull /sdcard/traces.txt

也可以使用 Logcat 定位ANR发生的具体时间、涉及的进程PID以及主要触发原因（Reason），这些信息能帮助缩小分析范围。

第二步：分析核心文件 traces.txt 拿到文件后，重点关注以下几个部分：
- CPU使用情况 ：在文件中搜索 CPU usage from。如果某个应用或系统服务CPU占用率过高，可能是系统资源紧张导致ANR。如果CPU总占用率很低，则很可能应用自身主线程被阻塞。
- 主线程堆栈 ：这是分析的重中之重。traces.txt 会记录各线程的调用栈，你需要：
  - 找到主线程 ：搜索 "main" prio=，其后的堆栈信息就是ANR发生时主线程正在执行的代码。
  - 定位问题 ：仔细查看堆栈中的类名、方法名和行号。例如，at android.database.sqlite.SQLiteDatabase.rawQuery 说明主线程在执行数据库查询。
- 其他阻塞原因 ：
  - 锁等待 ：在主线程堆栈中搜索 BLOCKED 或 WAITING 状态，查看 - waiting to lock <...> 这样的信息，就能知道是哪个锁导致了阻塞。
  - Binder调用 ：如果主线程卡在 binder.transact() 等Binder调用上，说明主线程在等待其他进程（如系统服务）返回结果，需要分析调用是否合理。
第三步：使用辅助工具深度分析 除了手动分析Trace文件，还可以借助工具提升效率：
- Android Studio Profiler：在开发阶段，实时监控CPU、内存的使用情况，直观地发现主线程的耗时操作。
- Perfetto：Google官方的系统级性能分析工具，能提供非常详细的图形化分析，可以完美补充静态Trace文件的不足。
- Systrace：一个老牌但依然有效的性能分析工具，适合分析UI渲染导致的掉帧和ANR问题。
- StrictMode：开发工具，能在代码中检测主线程上的磁盘I/O和网络访问等潜在问题，帮助预防ANR。
- BlockCanary：一个轻量级的开源库，可以监控应用卡顿，并在发生卡顿时通知开发者，非常实用。

🔍 常见ANR场景及解决方案

下表按问题场景 和具体原因分类，列出了常见ANR问题及解决方案。

问题场景	具体原因	代码迹象（在堆栈中可看到）	解决方案
I/O 与网络操作	在主线程中进行网络请求、文件读写、数据库查询等阻塞操作。	`HttpURLConnection.connect()` `SQLiteDatabase.query()` `FileInputStream.read()`	将耗时操作移至后台线程。可用方案：协程(Kotlin)、`Thread`、`ExecutorService`、`WorkManager`（后台任务）。
界面渲染	布局层级过深、一次性加载大量图片或执行复杂UI绘制。	`View.onDraw()` `ImageView.setImageBitmap()`	优化布局、降低UI绘制复杂度。使用`ViewStub`延迟加载、复用布局、压缩图片或使用`WebP`格式、将图片加载库置于后台线程。
锁与同步问题	主线程在等待某个被其他线程占用的锁，或出现线程死锁。	堆栈中显示 `BLOCKED` 状态，并指向 `waiting to lock <...>`。	仔细审查多线程代码。缩小锁作用范围、避免主线程与其他线程共享锁、使用并发工具 (`ReentrantLock`) 和线程池时需特别谨慎。
组件与系统交互	在主线程同步等待一个Binder调用（如系统服务）返回，而系统服务响应慢或发生死锁。	`binder.transact()` `ActivityManagerNative.getDefault()`	将耗时、阻塞的Binder调用移出主线程。例如，包管理服务(PackageManager)的查询操作应在后台线程完成。
资源紧张	设备CPU负载过高、内存严重不足，导致主线程迟迟得不到调度机会。	堆栈显示主线程处于 `RUNNABLE` 状态但长时间未执行，或内存（JVM内存或Native内存）接近耗尽。	优化自身App的资源占用，如减少内存泄漏、优化CPU使用。在Trace中检查CPU使用率，特别是 `iowait`（I/O等待）指标。
ContentProvider 访问	在主线程中通过ContentProvider访问大量数据或执行复杂查询。	`ContentResolver.query()`	将ContentProvider的访问移到后台线程。使用`Loader`或协程等异步方式加载数据。
BroadcastReceiver	在 `onReceive()` 方法中执行了耗时操作。	堆栈指向 `BroadcastReceiver.onReceive()` 方法。	使用 `goAsync()` 方法让Receiver在后台异步处理（注意限制执行时间），或启动一个`Service` 来处理复杂任务。
应用启动	在 `Application.onCreate()` 或 `Activity.onCreate()` 中执行了过多初始化操作。	堆栈指向 `Application.onCreate()` 或 `Activity.onCreate()`。	延迟或异步初始化。将非必需的初始化放在首次使用时进行，或移到后台线程。
进程间死锁	应用主线程与其他进程（如系统服务）持有锁资源，形成循环等待。	堆栈中主线程 `BLOCKED` 于 `binder.transact()`，而系统服务线程可能也处于等待状态。	分析Binder通信双方的锁依赖关系，优化锁的设计。通常需要结合系统级日志（如`logcat`）一起分析。
第三方库 / SDK	在SDK的回调方法中执行了耗时操作。	堆栈指向 `SomeLibrary.onSomeCallback()` 方法。	检查SDK的官方文档，确认是否允许在回调中执行耗时任务；如果不允许，应将耗时任务放到后台线程执行。
Service 启动	在 `Service` 的生命周期方法（如 `onStartCommand`）中执行了耗时操作。	堆栈指向 `Service.onStartCommand()`	在 `Service` 内部启动工作线程，或使用 `IntentService`（已废弃，建议使用 `JobIntentService` 或 `WorkManager`）来处理任务。

💎 总结

避免ANR的核心原则只有一条：保持主线程轻量、高效、不阻塞。所有可能耗时的操作------网络、数据库、文件、解码图片、复杂计算等------都必须放到后台线程中执行。

请记住，ANR的调试就像侦探破案，需要综合traces.txt中的堆栈信息、CPU状态和业务逻辑进行推理。工具是辅助，对项目代码逻辑的深入理解才是解决问题的关键。