ANR

ANR（Application Not Responding，应用无响应），这是 Android 开发中最常见的稳定性问题之一，根据深入分析，ANR主要由四种类型触发：输入事件分发超时、BroadcastReceiver处理超时、Service启动超时和ContentProvider发布超时。ANR发生的核心原因是主线程被阻塞，无法及时处理用户输入事件或系统服务请求。应用的主线程（UI 线程）被阻塞超过系统阈值，导致用户操作无法响应。

1. 核心本质：ANR 是主线程阻塞超过系统阈值导致，所有诱因最终都指向「主线程做了耗时操作」；
2. 定位关键：通过 traces.txt 日志找到主线程阻塞的具体代码位置，聚焦锁、IO、网络、计算四类耗时操作；
3. 解决原则：耗时操作移出主线程（线程池 / 协程 / IntentService），主线程只处理 UI 相关逻辑；
4. 预防重点：监控主线程耗时、优化资源使用、避免同步锁阻塞，严格遵循 Android 主线程规范。

简单来说，避免 ANR 的核心就是「让主线程轻装上阵」，把所有耗时工作交给子线程处理。

ANR是Android应用开发中必须面对的挑战，其根本原因是主线程被阻塞无法及时响应用户输入或系统请求。预防ANR需要开发者从代码结构、异步机制、资源管理和系统监控四个方面综合施策。随着Android系统的发展，ANR的触发机制和阈值也在不断变化，应保持对最新技术的了解。

随着Kotlin协程在Android开发中的普及，以及Jetpack组件的不断完善，ANR的预防将更加便捷。但无论技术如何演进，核心原则始终是避免主线程阻塞。通过合理使用异步机制、优化代码结构、监控系统资源，可以打造更加流畅和稳定的Android应用，提升用户体验和应用质量。

ANR 核心定义与触发条件

ANR 本质是Android 系统对应用响应能力的监控机制：系统会监控主线程的执行耗时，当超过特定阈值且无响应时，就会判定为 ANR，并弹出「应用无响应」的提示框。

不同场景的触发阈值（Android 标准规则）：

Android系统通过Watchdog机制监控主线程状态，当检测到以下任一情况时触发ANR：

输入事件分发超时：当主线程未在5秒内处理用户输入事件(如触摸、按键)，且用户再次触发输入事件时，系统将判定应用无响应。这种ANR的特点是需要用户重复操作才会触发，主要与UI线程的事件处理能力相关。

BroadcastReceiver处理超时：前台广播的onReceive()方法必须在10秒内完成，后台广播则为60秒。如果单个接收者或整个广播队列处理时间超过阈值，系统将触发ANR。值得注意的是，有序广播的总执行时间还可能达到receiver个数*timeout时长，因此复杂广播处理尤其容易引发ANR。

Service启动超时：前台服务(如通过startService()启动)的生命周期方法必须在20秒内完成返回，后台服务则为200秒。Service启动过程中的耗时操作若阻塞主线程，将导致ANR。Android系统在启动Service时会埋下定时炸弹，若未及时拆除则触发ANR。

ContentProvider发布超时：Android 12+引入的ContentProvider发布超时机制，要求应用在10秒内完成ContentProvider的注册和初始化。与其他类型不同，此超时不会弹出ANR对话框，而是直接杀掉进程。

这些超时阈值并非固定不变，不同厂商和系统版本可能存在差异。系统采用"装炸弹-拆炸弹-引爆炸弹"的机制来检测ANR，当应用组件未在规定时间内完成操作，系统会触发ANR对话框。ANR对话框包含应用包名、触发原因、进程PID等关键信息，开发者可通过日志定位问题。

注意：不同手机厂商可能微调阈值，但核心逻辑一致；ANR 触发后，系统会自动生成 ANR 日志，这是定位问题的关键。

ANR 的核心原因

所有 ANR 的本质都是主线程被阻塞，常见诱因可归纳为 4 类：

1. 主线程执行耗时操作

• 网络请求（HTTP/HTTPS、Socket）直接在主线程调用；
• 本地 IO 操作（读写大文件、数据库 CRUD）；
• 复杂计算（JSON 解析、数据排序、加密解密）；
• 同步锁阻塞（主线程等待其他线程释放锁，且等待超时）。

2. 主线程被其他线程抢占资源

• 大量子线程频繁创建 / 销毁，抢占 CPU 资源；
• 主线程 Looper 消息队列堵塞（如发送大量耗时的 Handler 消息）；
• 内存不足导致频繁 GC（垃圾回收），主线程被暂停。

3. 系统资源不足

• 应用占用内存过高，触发系统低内存查杀；
• CPU 被其他应用 / 系统进程占满，应用主线程无法调度；
• 磁盘 IO 繁忙（如手机存储满、SD 卡读写异常）。

4. 第三方库 / 系统服务阻塞

• 第三方 SDK（如广告、统计、支付）在主线程执行耗时操作；
• 调用系统服务（如 Location、Bluetooth）时，服务响应超时。

主线程阻塞情况

1. 耗时I/O操作

主线程执行同步I/O操作是最常见的ANR原因。这包括文件读写、网络请求、数据库操作等。例如在Activity的onCreate()方法中直接读取大文件，或在onReceive()中执行网络请求，都可能阻塞主线程超过阈值。Android官方推荐将I/O操作移至子线程执行，可通过以下方式实现：

• 使用Kotlin协程：通过withContext(Dispatchers.IO)执行I/O操作，完成后通过withContext(Dispatchers.Main)更新UI
• 使用AsyncTask：在doInBackground()中执行耗时操作，通过onPostExecute()更新UI
• 使用RxJava：通过Observable或Single在子线程执行操作，通过subscribeOn()和observeOn()控制线程

以文件读取为例，同步读取大文件可能导致主线程阻塞：

// 错误示例：同步读取大文件
String content = new String(Files.readAllBytes(Paths.get(filename)));

优化后应使用异步方式读取文件：

// 正确示例：协程异步读取文件
GlobalScope.launch(Dispatchers.IO) {
    val content = File(filename).readText()
    withContext(Dispatchers.Main) {
        // 更新UI
    }
}

2. 数据库读写操作

直接在主线程执行复杂的数据库查询或写入操作，也是ANR的常见原因。数据库操作可能涉及磁盘I/O，处理时间较长。解决方法是将数据库操作移至子线程执行，具体策略包括：

• 使用Room数据库：通过添加suspend关键字将查询声明为挂起函数，在子线程执行
• 使用异步任务：在AsyncTask的doInBackground()中执行数据库操作
• 批量操作优化：使用事务批量插入数据，减少数据库锁竞争

例如，在主线程中执行大量查询可能导致ANR：

// 错误示例：主线程执行复杂查询
Cursor cursor = db.rawQuery("SELECT * FROM large_table", null);

优化后应使用协程异步执行查询：

// 正确示例：协程异步查询
GlobalScope.launch(Dispatchers.IO) {
    val cursor = db.rawQuery("SELECT * FROM large_table", null)
    // 处理结果
    withContext(Dispatchers.Main) {
        // 更新UI
    }
}

3. 复杂计算任务

主线程执行耗时的计算任务(如图像处理、大数据计算、复杂的算法等)会导致UI线程无法响应。解决方案是将计算任务拆分到子线程执行，具体方法包括：

• 使用HandlerThread：创建带Looper的线程，处理计算任务后通过Handler更新UI
• 使用线程池：通过ThreadPoolExecutor管理计算任务
• 使用Kotlin协程：通过launch或async执行计算任务

复杂计算任务的典型表现是单帧渲染时间超过16ms，可通过Systrace工具检测：

# 使用Systrace检测UI渲染时间
python systrace.py -o trace.html -t 10 sched view wm gfx

在Systrace报告中，关注"Choreographer#doFrame"事件的持续时间，若超过16ms则可能引起ANR。

4. 锁争用与死锁

主线程与其他线程因锁争用或死锁被阻塞，也是ANR的重要原因。锁争用会导致主线程长时间等待锁资源，而死锁则会使主线程永久阻塞。解决方案是优化锁策略，减少锁竞争，具体包括：

• 减少锁粒度：避免使用大范围的锁，尽量缩小同步代码块
• 设置锁超时：为锁操作设置合理的超时时间
• 使用无锁数据结构：如ConcurrentHashMap替代HashMap

通过TSan工具可检测线程错误，包括死锁和锁争用：

# 使用TSan检测死锁
adb shell setprop debug.tsan true
adb shell am start -n com.example.app/.MainActivity

检测到的死锁问题会通过日志输出，帮助开发者定位阻塞点。

系统资源使用异常导致ANR

1. CPU资源占用过高

当主线程CPU占用率过高，系统无法及时调度处理输入事件或其他请求，也会触发ANR。CPU占用率过高通常表现为单帧渲染时间超过16ms，可通过以下工具检测：

• adb shell top：查看各进程的CPU使用率
• dumpsys cpuinfo：获取应用的CPU使用详情
• Android Profiler：分析应用的CPU使用情况

优化CPU使用率的策略包括：

• 使用Systrace分析CPU调度
• 优化算法和计算逻辑
• 减少不必要的UI渲染

2. 内存泄漏

内存泄漏导致应用可用内存不足，可能引发OOM(Out Of Memory)崩溃，也可能导致GC(垃圾回收)频繁，影响主线程响应。内存泄漏的主要表现是内存使用量持续增长，可通过以下工具检测：

• LeakCanary：自动检测内存泄漏并生成报告
• Android Profiler：实时监控内存分配和泄漏对象
• MAT(Memory Analyzer Tool)：分析堆转储文件，定位泄漏对象

内存泄漏的常见场景包括：

• 静态变量持有Activity或Context引用
• 匿名内部类隐式持有外部类实例
• 未释放的数据库连接或网络连接

通过弱引用(WeakReference)可有效预防内存泄漏：

// 使用弱引用防止内存泄漏
public class ImageLoaderTask extends AsyncTask<String, Void, Bitmap> {
    private WeakReference<ImageView> imageViewWeakReference;
    
    public ImageLoaderTask(ImageView imageView) {
        imageViewWeakReference = new WeakReference<>(imageView);
    }
    
    @Override
    protected void onPostExecute(Bitmap bitmap) {
        ImageView imageView = imageViewWeakReference.get();
        if (imageView != null && bitmap != null) {
            imageView.setImageBitmap(bitmap);
        }
    }
}

3. Binder通信性能问题

Binder是Android跨进程通信的核心机制，若Binder调用阻塞时间过长，可能导致主线程无法及时响应。Binder通信超时通常与系统服务响应时间或Binder线程池资源不足相关，可通过以下方式优化：

• 减少Binder调用次数：合并多个请求，避免频繁通信
• 使用oneway关键字：对于不需要返回结果的调用，使用AIDL的oneway关键字实现异步调用
• 优化Binder线程池：合理设置线程池大小，避免资源耗尽

AIDL中oneway关键字的使用示例：

// IMyService.aidl
package com.example.myapp;

interface IMyService {
    // 普通同步方法
    void normalMethod();
    
    // oneway异步方法
    oneway void onewayMethod();
}

ANR 定位与解决（实战步骤）

1. 第一步：获取 ANR 日志

ANR 发生后，Android 系统会在 /data/anr/ 目录生成 traces.txt 文件（需 root 权限，或通过 adb 导出），这是定位的核心依据：

# 导出 ANR 日志到本地
adb pull /data/anr/traces.txt ~/Desktop/anr_log.txt

日志中会明确标注：

• 发生 ANR 的应用包名、进程 ID；
• 主线程的调用栈（阻塞的具体代码位置）；
• 其他线程的状态（是否持有锁、是否占用 CPU）。

2. 第二步：常见 ANR 解决示例

以下是典型场景的修复代码，核心原则是「耗时操作移出主线程」：

场景 1：主线程执行网络请求（触发 ANR）

❌ 错误代码（主线程请求网络）：

// MainActivity.java（主线程）
public void onClick(View v) {
    // 直接在主线程请求网络 → 阻塞5秒以上触发 ANR
    String result = HttpUtil.get("https://example.com/api/data");
    tvResult.setText(result);
}

✅ 修复代码（使用线程池 + Handler / 协程）：

// 方案1：线程池 + Handler（Java）
private ExecutorService executor = Executors.newSingleThreadExecutor();
private Handler mainHandler = new Handler(Looper.getMainLooper());

public void onClick(View v) {
    executor.execute(() -> {
        // 子线程执行耗时网络请求
        String result = HttpUtil.get("https://example.com/api/data");
        // 切回主线程更新 UI
        mainHandler.post(() -> tvResult.setText(result));
    });
}

// 方案2：Kotlin 协程（更简洁）
fun onClick(v: View) {
    lifecycleScope.launch(Dispatchers.IO) {
        // IO 线程执行网络请求
        val result = HttpUtil.get("https://example.com/api/data")
        // 切回主线程更新 UI
        withContext(Dispatchers.Main) {
            tvResult.text = result
        }
    }
}

场景 2：主线程读写大文件

❌ 错误代码：

// 主线程读取大文件 → 阻塞主线程
public String readBigFile() {
    File file = new File(getFilesDir(), "big_data.txt");
    BufferedReader br = new BufferedReader(new FileReader(file));
    StringBuilder sb = new StringBuilder();
    String line;
    while ((line = br.readLine()) != null) { // 耗时操作
        sb.append(line);
    }
    br.close();
    return sb.toString();
}

✅ 修复代码（使用 AsyncTask / 协程）：

// Kotlin 协程 + withContext
suspend fun readBigFile(): String = withContext(Dispatchers.IO) {
    val file = File(context.filesDir, "big_data.txt")
    return@withContext file.readText() // IO 线程执行
}

// 调用处
lifecycleScope.launch {
    val content = readBigFile()
    tvContent.text = content // 主线程更新 UI
}

场景 3：避免主线程 Looper 堵塞

主线程的 Handler 消息队列如果被大量耗时消息占满，会导致输入事件无法处理，触发 ANR。解决方案：

• 减少主线程 Handler 发送耗时消息；
• 对高频消息做防抖 / 节流（如搜索框输入）；
• 使用 HandlerThread 处理非 UI 相关的消息。

3. 第三步：ANR 预防措施

除了修复已知问题，还需做好日常预防：

1. 严格遵循主线程规范：
   • 主线程只做 UI 渲染、事件分发，不做任何耗时操作；
   • 所有网络、IO、计算操作都放在子线程（线程池 / 协程 / IntentService）。
2. 监控主线程耗时：
   • 使用 Android Studio Profiler 监控主线程耗时（CPU 面板）；
   • 接入第三方监控工具（如 Firebase Performance、Bugly、Matrix），实时监控主线程卡顿。
3. 优化资源使用：
   • 减少内存泄漏（避免静态持有 Activity 引用），降低 GC 频率；
   • 优化数据库操作（索引、批量操作），减少 IO 耗时；
   • 避免同步锁嵌套，减少死锁 / 阻塞风险。
4. 兜底处理：
   • 对广播接收器，若逻辑复杂则使用 goAsync() 异步处理；
   • Service 耗时操作改用 IntentService 或 WorkManager。

ANR 日志关键信息解读（示例）

以下是 traces.txt 中典型的 ANR 日志片段：

----- pid 12345 at 2026-01-06 10:00:00 -----
Cmd line: com.example.myapp

"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x73a0b0a0 self=0x7f8a12345678
  | sysTid=12345 nice=0 cgrp=default sched=0/0 handle=0x7f8a98765432
  | state=S schedstat=( 123456789 987654321 123 ) utm=10 stm=2 core=0 HZ=100
  | stack=0x7ffee000-0x7ffee800 stackSize=8MB
  | held mutexes=
  at com.example.myapp.MainActivity.onClick(MainActivity.java:50)
  - waiting to lock <0x0a1b2c3d> (a java.lang.Object) held by thread 2
  at android.view.View.performClick(View.java:7448)
  at android.view.View.performClickInternal(View.java:7425)
  ...

关键信息解读：

• tid=1：主线程（main）；
• Blocked：线程状态为阻塞；
• waiting to lock <0x0a1b2c3d>：主线程等待线程 2 释放锁；
• MainActivity.java:50：阻塞的具体代码行（第 50 行）。

ANR的预防与解决策略

1. 异步任务框架选择与使用

Android提供了多种异步任务处理框架，开发者应根据场景选择合适的方案：

• Kotlin协程：适用于短时、轻量级任务，如网络请求、UI更新。通过Dispatchers.IO或Default调度，需注意避免在主线程执行耗时操作
• WorkManager：适用于后台、持久化任务，如数据同步、日志上传。支持协程集成，通过CoroutineWorker实现异步工作
• RxJava：适用于需要复杂异步处理和响应式编程的场景

不同框架的优缺点对比：

2. 线程池配置优化

合理配置线程池是预防ANR的关键。线程池的核心参数包括：

• corePoolSize：核心线程数，维护线程的最少数量
• maximumPoolSize：最大线程数，允许的最大线程数
• workQueue：阻塞队列，存放待执行任务
• threadFactory：线程工厂，创建新线程
• rejectedExecutionHandler：任务溢出处理策略

根据任务性质，线程池参数应合理设置：

// 线程池配置示例
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    Runtime.getRuntime().availableProcessors() + 1, // CPU密集型任务
    Runtime.getRuntime().availableProcessors() * 2, // I/O密集型任务
    60, 
    TimeUnit.SECONDS,
    new LinkedBlockingDeque<>(100),
    new ThreadFactory() {
        @Override
        public Thread newThread(Runnable r) {
            return new Thread(r);
        }
    },
    new ThreadPoolExecutor.CallerRunsPolicy()
);

3. 系统资源监控与优化

建立ANR监控体系是预防ANR的重要手段：

• CPU监控：通过top命令或Android Profiler实时监测主线程CPU使用率
• 内存监控：使用LeakCanary或Android Profiler检测内存泄漏和GC情况
• Binder监控：通过binder或binder_driver类别日志分析Binder通信性能

具体监控命令示例：

# 查看CPU使用情况
adb shell top -n 1 | grep com.example.app

# 查看内存信息
adb shell dumpsys meminfo com.example.app

# 查看Binder驱动信息
adb shell dumpsys binder

4. 代码结构优化

良好的代码结构是预防ANR的基础：

• MVVM架构：在ViewModel中处理异步操作，通过LiveData或StateFlow安全更新UI
• 模块化设计：将耗时操作与UI分离，通过接口定义清晰的职责边界
• 避免主线程阻塞：使用StrictMode工具检测主线程中的不当操作

MVVM架构下的异步操作示例：

// ViewModel中的异步操作
class MyViewModel : ViewModel() {
    private val _data = MutableLiveData<String>()
    val data: LiveData<String> = _data
    
    fun loadAsyncData() {
        viewModelScope.launch {
            val result = withContext(Dispatchers.IO) {
                // 执行耗时操作
            }
            _data.value = result
        }
    }
}

5. 及时处理输入事件 ?

在Android应用中，及时处理输入事件是避免ANR问题的重要一环。Activity和Service等组件作为应用的核心组成部分，它们承担着响应用户输入和系统事件的关键任务。因此，这些组件必须能够在接收到输入事件后迅速做出反应，以确保应用的流畅运行和用户满意度的提升。

为了实现这一目标，开发者需要关注以下几个方面：

• 事件分发机制的理解：深入了解Android的事件分发机制是优化输入事件处理的前提。开发者应熟悉触摸事件、按键事件等不同类型的输入事件在Android系统中的传递和处理流程，以便更好地掌握如何优化这些事件的处理。

• 减少处理时间：对于需要响应的输入事件，应尽量减少处理时间。这可以通过优化代码逻辑、减少不必要的计算和资源消耗来实现。例如，避免在事件处理函数中进行复杂的数据处理或网络请求等操作，以确保事件能够得到快速响应。

• 异步处理耗时操作：如果某个操作需要较长时间才能完成，如网络请求或数据库查询等，应将其放到子线程中进行异步处理。这样可以避免主线程被阻塞，确保其他输入事件能够得到及时处理。同时，在异步操作进行期间，可以在界面上显示进度条或加载动画等提示信息，以告知用户当前应用的状态，提升用户的等待体验。

• 合理设置超时时间：对于某些需要等待的操作，如文件读写或网络连接等，应合理设置超时时间。一旦操作超过设定的超时时间仍未完成，应用应能够主动中断该操作并给出相应的提示信息，以避免长时间的无响应状态引发用户的不满和焦虑。

• 监控与调试：在实际开发过程中，开发者应密切关注应用的响应性能，并定期进行调试和优化。通过监控工具可以实时监测应用的CPU占用率、内存消耗等指标，帮助开发者及时发现并解决潜在的性能问题。同时，利用调试工具可以模拟各种输入事件和异常情况，验证应用在各种场景下的响应性和稳定性。

及时处理输入事件是避免Android应用出现ANR问题的关键所在。通过深入理解事件分发机制、减少处理时间、异步处理耗时操作、合理设置超时时间以及加强监控与调试等措施的实施，开发者可以显著提升应用的响应性能和用户体验，从而打造出更加优质、稳定的Android应用。

6. 避免死锁和阻塞 ?

在Android多线程编程环境中，有效地避免死锁和阻塞是确保应用流畅运行、减少ANR发生的关键。为了实现这一目标，开发者需要深入理解死锁和阻塞的产生原因，并采取相应的预防措施。

• 死锁的预防策略

死锁通常是由于多个线程在等待彼此释放资源而形成的。为了预防死锁，可以采取以下策略：

​ a. 避免嵌套锁：尽量避免在一个线程中同时持有多个锁，尤其是当这些锁涉及到不同的资源时。这样可以减少线程之间因资源依赖而产生的死锁风险。

​ b. 顺序获取锁：当多个线程需要同时访问多个共享资源时，应确保它们以相同的顺序请求这些资源。通过这种方法，可以避免因请求资源的顺序不同而导致的死锁。

​ c. 超时和重试机制：为线程获取锁的操作设置超时时间。如果线程在超时时间内未能成功获取锁，则应放弃尝试，并可能在稍后重试。这种策略有助于打破潜在的死锁状态。

​ d. 检测死锁：利用工具或编写代码来定期检测应用中是否存在死锁情况。一旦发现死锁，应立即采取措施进行解决，如终止相关线程或释放资源。

• 阻塞的缓解措施

阻塞通常发生在线程等待某个条件成立或某个资源可用时。为了缓解阻塞带来的问题，可以考虑以下措施：

​ a. 合理使用同步机制：通过synchronized关键字、Lock接口等同步机制来控制对共享资源的访问。确保在访问共享资源时使用合适的同步块或同步方法，以减少不必要的阻塞。

​ b. 优化资源分配：合理设计和分配应用中的资源，如内存、CPU时间等，以确保各个线程能够公平地获取所需资源，并降低因资源不足而导致的阻塞风险。

​ c. 异步编程模型：采用异步编程模型来处理耗时操作，如网络请求或数据库查询。通过使用回调函数、Future模式或响应式编程等技术，可以将耗时操作移至后台线程执行，从而避免主线程被阻塞。

​ d. 线程优先级调度：根据任务的紧急程度和重要性，为线程设置合理的优先级。这有助于确保关键任务能够优先执行，减少因低优先级线程长时间占用资源而导致的阻塞情况。

ANR的调试与分析工具

1. ANR日志分析

当ANR发生时，系统会在/data/anr/traces.txt文件中记录详细信息。分析traces.txt文件是定位ANR原因的关键步骤，主要关注以下内容：

• ANR类型：输入事件、BroadcastReceiver、Service或ContentProvider
• 进程信息：发生ANR的进程名、PID、CPU使用率、内存占用
• 线程堆栈：主线程和其他活跃线程的调用堆栈，识别阻塞点

获取ANR日志的命令：

# 拉取ANR日志
adb pull /data/anr/traces.txt .

# 查看ANR日志
less traces.txt

2. Systrace工具

Systrace是Android官方提供的性能分析工具，可捕获系统关键组件(如CPU、Binder、App主线程)的实时行为。Systrace特别适合分析UI线程阻塞问题，通过可视化时间轴展示各线程的执行情况。

Systrace的基本使用方法：

# 捕获Systrace数据
python systrace.py -o trace.html -t 10 -a com.example.app \
    sched view wm am app binder Driver

# 分析Systrace报告
chromium trace.html

在Systrace报告中，重点关注"Choreographer#doFrame"事件的持续时间，以及主线程的调度情况。

3. Android Profiler

Android Profiler是Android Studio内置的性能分析工具，提供CPU、内存、网络和电池的实时监控。Android Profiler的CPU分析功能可精确到方法级别，帮助开发者定位耗时操作。

Android Profiler的主要功能：

• CPU Profiler：分析方法调用和线程状态
• Memory Profiler：检测内存泄漏和对象引用
• Network Profiler：监控网络请求和响应
• Battery Profiler：分析电池消耗情况

通过Android Profiler的CPU采样功能，可识别主线程中耗时过长的方法。

4. 在使用性能分析工具时，需要注意以下几点：

• 定期使用：性能分析工具应该成为我们开发过程中的常规武器。定期使用这些工具对应用进行性能评估，可以及时发现并解决潜在的性能问题，从而避免ANR的发生。

• 关注关键指标：在使用Profiler等工具时，我们应该重点关注那些与ANR密切相关的指标，如CPU占用率、内存使用情况等。这些指标能够直接反映出应用的响应性和稳定性。

• 结合代码分析：性能分析工具虽然功能强大，但并不能完全替代代码分析。在发现性能问题时，我们需要结合具体的代码逻辑进行深入分析，找出问题的根源并进行优化。

• 持续优化：性能优化是一个持续的过程。随着应用的不断迭代和更新，我们需要不断地使用性能分析工具进行检测和优化，确保应用在各种场景下都能保持良好的稳定性和响应性。

使用性能分析工具是预防和解决Android应用中ANR问题的有效途径。通过充分利用这些工具的功能和特点，我们可以更加高效地定位和解决性能瓶颈，从而提升用户体验和应用的市场竞争力。

实际案例分析与解决方案

1. 广播接收器ANR案例

问题描述：某应用在接收前台广播时经常出现ANR，日志显示"Broadcast of Intent { act=android.intent.action.BOOT_COMPLETED }"

原因分析：BroadcastReceiver的onReceive()方法中执行了耗时的网络请求和数据处理操作。

解决方案：将耗时操作移至子线程，并使用WorkManager处理复杂任务：

// 使用WorkManager处理耗时广播操作
class MyBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // 立即返回，避免ANR
        WorkManager.getInstance(context).enqueue(
            OneTimeWorkRequestBuilder<HandleBootWorkRequest>()
                .setInputData(Data.Builder().build())
                .build()
        )
    }
}

// 自定义Worker处理耗时操作
class HandleBootWorkRequest : Worker() {
    override fun doWork(): Result {
        // 执行网络请求和数据处理
        return Result.success()
    }
}

2. Service启动ANR案例

问题描述：应用启动时Service启动过程经常超过20秒，触发ANR。

原因分析：Service的onCreate()方法中执行了复杂的数据库初始化和网络同步操作。

解决方案：优化Service启动流程，减少耗时操作：

// 优化Service启动流程
class MyService : Service() {
    override fun onCreate() {
        // 执行必要的初始化
        super.onCreate()
        
        // 将耗时操作移至子线程
        GlobalScope.launch {
            // 执行数据库初始化和网络同步
        }
    }
    
    override fun onStartCommand(intent: Intent, flags: Int, startId: Int): Int {
        // 返回立即，避免ANR
        return START_STICKY
    }
}

3. 内存泄漏导致ANR案例

问题描述：应用长时间运行后出现ANR，内存使用量持续增长，频繁触发GC。

原因分析：ViewModel中持有Activity的强引用，导致Activity无法被回收，内存泄漏累积。

解决方案：使用弱引用和生命周期感知组件：

// 使用弱引用和生命周期感知
class MyViewModel : ViewModel() {
    private val _context = WeakReference<Context>(applicationContext)
    
    fun someFunction() {
        GlobalScope.launch {
            // 执行耗时操作
            withContext(Dispatchers.Main) {
                val context = _context.get()
                if (context != null) {
                    // 更新UI
                }
            }
        }
    }
}

ANR的预防最佳实践

1. 遵循Android线程规范

• 避免在主线程执行耗时操作(超过100-200ms)
• Activity的所有生命周期回调(如onCreate(), onResume())应尽可能轻量
• 在BroadcastReceiver中快速完成工作或将任务移至Service
• 避免在IntentReceiver中启动Activity，改用Notification Manager通知用户

2. 使用合适的异步机制

• 网络请求：使用Retrofit或Volley等异步网络库
• 数据库操作：使用Room或ContentProvider的异步API
• 文件I/O：使用AsyncTask或协程执行读写操作
• 复杂计算：使用HandlerThread或线程池处理计算任务

3. 优化代码与架构设计

• 减少UI线程负担：避免在主线程执行耗时的布局测量、布局和绘制操作
• 避免锁争用：减少synchronized块的范围，使用ReentrantLock替代
• 优化数据库性能：在高频查询字段添加索引，使用批量操作和事务管理
• 内存泄漏预防：使用弱引用、避免静态持有Activity/Context、及时释放资源

4. 建立ANR监控体系

• 集成Firebase Crashlytics实时监控ANR率
• 部署自动化Monkey测试脚本
• 使用StrictMode检测主线程网络请求
• 定期分析ANR日志和系统性能指标

通过上述策略的综合应用，可显著降低ANR发生率。例如，某电商App通过将耗时操作移至子线程、优化数据库索引和使用线程池管理，ANR率从0.47%降至0.12%。

如何避免 ANR 问题？

核心思路是从根源上杜绝主线程阻塞，同时通过规范、监控、优化三层策略，全方位保障主线程的响应能力。

1. 核心策略：耗时操作全部异步化（协程 / 线程池），主线程只做 UI 相关操作；
2. 关键优化：避免锁阻塞、减少 GC 压力、优化网络 / 数据库 / 广播等高频场景；
3. 兜底保障：通过 Profiler / 第三方工具监控主线程状态，提前发现并修复卡顿问题。

简单来说，避免 ANR 的核心就是「让主线程始终保持空闲」—— 把所有可能耗时的工作交给子线程，主线程只专注于响应用户操作和渲染 UI。

核心原则：主线程只做「UI 相关」的轻量操作

ANR 的本质是主线程（UI 线程）被耗时操作阻塞，因此第一步就是严格划分主线程和子线程的职责：

具体避坑方案（按优先级排序）

1. 耗时操作异步化（最核心）

将所有耗时操作移出主线程，推荐使用成熟的异步方案（避免手动创建线程导致的管理混乱）：

方案 1：Kotlin 协程（推荐，简洁且安全）

协程是 Android 官方推荐的异步方案，自带线程切换和生命周期管理，避免内存泄漏：

// Activity/Fragment 中使用（绑定生命周期，自动取消）
lifecycleScope.launch {
    // 1. 切到 IO 线程执行耗时操作
    val data = withContext(Dispatchers.IO) {
        // 网络请求/文件读写/数据库操作
        ApiClient.fetchUserData() // 耗时操作
    }
    // 2. 自动切回主线程，更新 UI
    tvUserInfo.text = data.toString()
}

// 全局耗时任务（如应用初始化）
val scope = CoroutineScope(Dispatchers.Default + SupervisorJob())
scope.launch {
    val config = withContext(Dispatchers.IO) {
        ConfigManager.loadConfig() // 耗时 IO 操作
    }
    // 主线程更新配置
    withContext(Dispatchers.Main) {
        AppConfig.init(config)
    }
}

// 页面销毁时取消协程（避免泄漏）
override fun onDestroy() {
    super.onDestroy()
    scope.cancel()
}

方案 2：线程池（Java/Kotlin 通用）

适合批量处理耗时任务，避免频繁创建 / 销毁线程：

// 全局线程池（推荐复用，避免重复创建）
private static final ExecutorService IO_THREAD_POOL = new ThreadPoolExecutor(
    2, // 核心线程数
    4, // 最大线程数
    60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(),
    new ThreadFactory() {
        private int count = 0;
        @Override
        public Thread newThread(Runnable r) {
            Thread thread = new Thread(r);
            thread.setName("IO-Thread-" + count++); // 命名线程，方便调试
            return thread;
        }
    }
);

// 主线程调用
public void loadData() {
    IO_THREAD_POOL.execute(() -> {
        // 子线程执行耗时操作
        String data = DbHelper.queryBigData();
        // 切回主线程更新 UI
        runOnUiThread(() -> tvData.setText(data));
    });
}

// 应用退出时关闭线程池（避免内存泄漏）
public void onAppQuit() {
    IO_THREAD_POOL.shutdown();
}

方案 3：WorkManager（后台任务）

适合需要持久化的后台任务（如同步数据、上传日志），自动适配 Android 后台限制：

// 定义后台任务
class SyncDataWorker(context: Context, params: WorkerParameters) : CoroutineWorker(context, params) {
    override suspend fun doWork(): Result {
        // 后台执行耗时同步操作
        val result = withContext(Dispatchers.IO) {
            SyncManager.syncAllData()
        }
        return if (result) Result.success() else Result.retry()
    }
}

// 触发任务
val syncRequest = OneTimeWorkRequestBuilder<SyncDataWorker>()
    .setConstraints(Constraints.Builder()
        .setRequiredNetworkType(NetworkType.CONNECTED) // 仅在有网络时执行
        .build())
    .build()

WorkManager.getInstance(context).enqueue(syncRequest)

2. 优化高频 / 耗时场景

针对容易触发 ANR 的高频场景，做专项优化：

• 网络请求：

  • 增加超时限制（避免无限等待）：OkHttpClient.Builder().connectTimeout(10, TimeUnit.SECONDS)；
  • 取消无用请求（如页面销毁时取消未完成的请求）；
  • 使用缓存（避免重复请求）。

• 数据库操作：

  • 给常用字段加索引，减少查询耗时；
  • 批量操作使用事务（避免多次 IO）；
  • 分页加载大数据（避免一次性查询全量数据）。

• 广播接收器：

  • 静态广播尽量改为动态广播，且缩短执行时间；

  • 复杂广播逻辑使用goAsync()异步处理：

    @Override
    public void onReceive(Context context, Intent intent) {
        // 异步处理广播，避免 10 秒超时
        BroadcastReceiver.PendingResult result = goAsync();
        IO_THREAD_POOL.execute(() -> {
            // 耗时处理逻辑
            handleBroadcastData(intent);
            result.finish(); // 处理完成后标记结束
        });
    }
    

• Service 操作：

  • 前台 Service 耗时操作改用 IntentService 或 JobIntentService；
  • 避免在 onCreate()/onStartCommand() 中执行耗时逻辑。

3. 避免主线程锁阻塞

同步锁是 ANR 的高频诱因（主线程等待子线程释放锁），需重点规避：

• 避免在主线程中等待子线程的锁（如 synchronized、CountDownLatch）；

• 锁的粒度要小（只锁关键代码块，不锁整个方法）；

• 避免嵌套锁（降低死锁 / 阻塞风险）；

• 给锁操作加超时限制（避免无限等待）：

  // 使用 tryLock 加超时，避免主线程无限阻塞
  Lock lock = new ReentrantLock();
  if (lock.tryLock(3, TimeUnit.SECONDS)) {
      try {
          // 临界区代码
      } finally {
          lock.unlock();
      }
  } else {
      // 超时处理，避免 ANR
      Log.e("ANR", "获取锁超时，放弃执行");
  }
  

4. 减少主线程 GC 压力

频繁 GC 会暂停主线程，导致响应延迟，甚至触发 ANR：

• 避免内存泄漏（如静态持有 Activity/Fragment 引用、未取消的监听器）；
• 减少临时对象创建（如循环中避免频繁创建 String、List）；
• 使用对象池复用频繁创建的对象（如 Bitmap、网络请求对象）；
• 及时释放无用资源（如 Bitmap.recycle ()、关闭流）。

监控与兜底（提前发现问题）

即使做好了预防，也需要监控主线程状态，提前发现潜在 ANR：

1. 使用 Android Studio Profiler：

   • CPU 面板：监控主线程的耗时函数（红色块表示耗时操作）；
   • 内存面板：监控 GC 频率和内存使用；
   • 卡顿检测：开启「Advanced Profiling」，实时检测主线程卡顿。

2. 接入第三方监控工具：

   • 字节跳动 Matrix、腾讯 Bugly、阿里百川：实时监控 ANR、卡顿，并输出调用栈；
   • Firebase Performance：监控网络请求、函数执行耗时。

3. 自定义主线程监控：

   监控 Looper 消息处理耗时，超过阈值时记录日志：

   // 监控主线程消息队列
   Looper.getMainLooper().setMessageLogging { msg ->
       if (msg.contains(">>>>> Dispatching")) {
           // 记录消息开始时间
           mainThreadStartTime = System.currentTimeMillis()
       } else if (msg.contains("<<<<< Finished")) {
           // 计算消息处理耗时
           val cost = System.currentTimeMillis() - mainThreadStartTime
           if (cost > 1000) { // 超过1秒，记录耗时日志
               Log.w("ANR_WARN", "主线程消息处理耗时：$cost ms，消息：$msg")
           }
       }
   }
   

开发规范（团队层面规避）

1. 代码评审：重点检查主线程是否有耗时操作；
2. 单元测试：对耗时函数做耗时测试，超过阈值告警；
3. 灰度发布：新功能先灰度，监控 ANR 率是否上升；
4. 避免滥用第三方库：优先选择轻量、口碑好的 SDK，避免引入暗地在主线程执行耗时操作的库。

如何监控 ANR？

ANR 监控分为「系统原生日志监控」「应用层主动监控」「第三方工具监控」三类，覆盖从开发调试到线上发布的全场景：

1. 开发 / 测试阶段：系统原生监控（最基础）

Android 系统在 ANR 发生时会自动生成日志文件，这是最核心的监控依据，适合本地调试：

（1）实时监控 ANR 触发

通过 adb 命令实时查看系统日志，使用 adb logcat 过滤 ANR 相关日志ANR 发生时会有明确的 ANR in 关键字：

# 实时过滤 ANR 日志（Windows/Linux/macOS 通用）
adb logcat | findstr "ANR"  # Windows
adb logcat | grep -i "ANR"  # Linux/macOS

输出示例：

01-06 10:00:00.123  1234  5678 E ActivityManager: ANR in com.example.myapp (com.example.myapp/.MainActivity)
01-06 10:00:00.124  1234  5678 E ActivityManager: Reason: Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.)
01-06 10:00:00.125  1234  5678 E ActivityManager: Load: 2.5 / 1.8 / 1.2
01-06 10:00:00.126  1234  5678 E ActivityManager: CPU usage from 0ms to 5000ms ago:

日志关键信息：

• 发生 ANR 的应用包名（如 com.example.myapp）；
• ANR 原因（如 Input dispatching timed out 输入超时）；
• CPU / 内存使用率（判断是否资源不足）。

（2）导出 ANR 核心日志文件 traces.txt

ANR 发生后，系统会在 /data/anr/ 目录生成 traces.txt（核心）和 anr_*.log 文件，导出后可离线分析：

# 导出 traces.txt（需 root 或调试权限）
adb pull /data/anr/traces.txt ~/Desktop/anr_traces.txt

# 若权限不足，可先复制到 sdcard 再导出
adb shell "cp /data/anr/traces.txt /sdcard/"
adb pull /sdcard/traces.txt ~/Desktop/anr_traces.txt

2. 线上生产阶段：应用层主动监控（自定义埋点）

适合线上环境，在 ANR 发生时主动捕获并上报，核心原理是「监控主线程 Looper 消息处理耗时」：

核心实现（Looper 监控）

Android 主线程的消息处理依赖 Looper，通过 Hook Looper.loop() 可监控每个消息的处理耗时，超过阈值则判定为「潜在 ANR」并记录堆栈：

class ANRMonitor private constructor() {
    // ANR 阈值（参考系统 5 秒，这里设 4 秒提前预警）
    private val ANR_THRESHOLD = 4000L
    private val mainHandler = Handler(Looper.getMainLooper())
    private val mainLooper = Looper.getMainLooper()
    private var isMonitoring = false

    // 检测主线程是否阻塞的 Runnable
    private val anrDetector = object : Runnable {
        override fun run() {
            // 若主线程阻塞，这个 Runnable 无法按时执行
            val startTime = System.currentTimeMillis()
            mainHandler.post {
                val delay = System.currentTimeMillis() - startTime
                // 延迟超过阈值，判定为 ANR 风险
                if (delay > ANR_THRESHOLD) {
                    // 捕获主线程堆栈
                    val stackTrace = getMainThreadStackTrace()
                    // 上报 ANR 信息（日志/服务器），上报到服务器（对接你的埋点平台）
                    reportANR("主线程阻塞超时：$delay ms", stackTrace)
                }
            }
        }
    }

    // 启动监控
    fun startMonitor() {
        if (isMonitoring) return
        isMonitoring = true
        // 每隔 1 秒检测一次主线程是否阻塞
        val executor = ScheduledThreadPoolExecutor(1)
        executor.scheduleAtFixedRate(anrDetector, 0, 1, TimeUnit.SECONDS)
    }

    // 获取主线程堆栈
    private fun getMainThreadStackTrace(): String {
        val mainThread = mainLooper.thread
        val stackTraceElements = mainThread.stackTrace
        return stackTraceElements.joinToString("\n") {
            "\tat ${it.className}.${it.methodName}(${it.fileName}:${it.lineNumber})"
        }
    }

    // 上报 ANR 信息（可对接埋点平台）
    private fun reportANR(reason: String, stackTrace: String) {
        val anrInfo = """
            ANR 预警：$reason
            设备信息：${Build.MODEL} / ${Build.VERSION.RELEASE}
            堆栈信息：$stackTrace
        """.trimIndent()
        // 1. 本地日志记录
        Log.e("ANR_MONITOR", anrInfo)
        // 2. 上报到服务器（示例）
        // ApiClient.uploadANR(anrInfo)
    }

    companion object {
        val INSTANCE by lazy { ANRMonitor() }
    }
}

// 在 Application 中启动监控
class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        ANRMonitor.INSTANCE.startMonitor()
    }
}

核心逻辑：

• 每隔 1 秒往主线程消息队列发一个「检测 Runnable/任务」；
• 若主线程正常，该 Runnable/任务 会立即执行，计算延迟≈0；
• 若主线程阻塞，Runnable/任务 执行延迟超过阈值（如4秒），判定为ANR并触发 ANR 预警并捕获堆栈。

3. 线上生产环境：第三方监控工具（推荐）

无需自己造轮子，成熟的第三方工具能自动监控、上报、分析 ANR，还能统计 ANR 率：

接入示例（Bugly）：

// 1. 集成依赖（build.gradle）
implementation 'com.tencent.bugly:crashreport:latest.release'

// 2. 初始化（Application）
Bugly.init(getApplicationContext(), "你的AppID", false);

Bugly 会自动捕获 ANR 并生成「ANR 分析报告」，包含：

• ANR 发生时间、设备信息、系统版本；
• 主线程完整堆栈（阻塞的具体代码行）；
• CPU / 内存使用情况、用户操作路径。

如何分析 ANR？

分析 ANR 的核心是「找到主线程阻塞的根因」，步骤可总结为：获取日志 → 定位阻塞点 → 分析诱因 → 验证修复。

1. 第一步：提取 ANR 日志核心信息

以系统生成的 traces.txt 为例，重点关注以下内容：

----- pid 12345 at 2026-01-06 10:00:00 -----
Cmd line: com.example.myapp
Build fingerprint: 'google/pixel6/pixel6:14/UP1A.231005.007/1234567:user/release-keys'

"main" prio=5 tid=1 Blocked  // 主线程状态：Blocked（阻塞）
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x73a0b0a0 self=0x7f8a12345678
  | sysTid=12345 nice=0 cgrp=default sched=0/0 handle=0x7f8a98765432
  | state=S schedstat=( 123456789 987654321 123 ) utm=10 stm=2 core=0 HZ=100
  | stack=0x7ffee000-0x7ffee800 stackSize=8MB
  | held mutexes=
  at com.example.myapp.MainActivity.loadData(MainActivity.java:80)  // 阻塞的代码行
  - waiting to lock <0x0a1b2c3d> (a java.lang.Object) held by thread 2  // 等待锁，被线程2持有
  at com.example.myapp.MainActivity.onClick(MainActivity.java:50)  // 触发点（点击事件）
  at android.view.View.performClick(View.java:7448)
  ...

"Thread-2" prio=5 tid=2 RUNNABLE  // 持有锁的线程2状态：RUNNABLE（一直在运行）
  | group="main" sCount=0 dsCount=0 flags=0 obj=0x12c000a0 self=0x7f8a12347890
  | sysTid=12346 nice=0 cgrp=default sched=0/0 handle=0x7f8a98767890
  | state=R schedstat=( 987654321 123456789 456 ) utm=50 stm=10 core=1 HZ=100
  | stack=0x7f89f000-0x7f89f800 stackSize=1036KB
  | held mutexes=0x0a1b2c3d  // 持有主线程等待的锁
  at com.example.myapp.DataManager.queryData(DataManager.java:120)  // 线程2的耗时操作
  at com.example.myapp.DataManager.access$000(DataManager.java:10)
  at com.example.myapp.DataManager$1.run(DataManager.java:80)
  ...

关键信息解读：

2. 第二步：分类分析 ANR 根因

根据日志信息，ANR 根因可分为 4 类，对应不同分析思路：

（1）主线程直接执行耗时操作

• 特征：日志中主线程状态为 Runnable，堆栈显示在执行网络 / IO / 计算代码；
• 示例：at com.example.myapp.MainActivity.httpRequest(MainActivity.java:60)；
• 分析：找到该行代码，确认是耗时操作（如无异步的网络请求）；
• 修复：移到子线程（协程 / 线程池）。

（2）主线程等待锁阻塞

• 特征：日志中有 waiting to lock，且有线程持有该锁；
• 示例：主线程等 Thread-2 的锁，Thread-2 一直在执行耗时操作；
• 分析：
  1. 找到持有锁的线程（如上例 Thread-2）；
  2. 查看该线程的堆栈，确认是否在执行无限循环 / 极耗时操作；
• 修复：
  • 缩小锁粒度（只锁关键代码，不锁整个方法）；
  • 给锁加超时（tryLock）；
  • 避免主线程等待子线程的锁。

（3）主线程 Looper 消息队列堵塞

• 特征：日志中主线程在处理 Handler 消息，且消息处理耗时；
• 示例：at android.os.Handler.dispatchMessage(Handler.java:106)；
• 分析：
  1. 查看消息来源（如频繁发送的耗时消息）；
  2. 检查是否有大量消息堆积；
• 修复：
  • 减少主线程 Handler 发送耗时消息；
  • 对高频消息做防抖 / 节流（如搜索框输入）。

（4）系统资源不足导致 ANR

• 特征：日志中 CPU / 内存使用率极高，或有 GC_FOR_ALLOC 频繁出现；
• 示例：CPU usage from 0ms to 5000ms ago: 90%；
• 分析：
  1. 查看系统日志中的内存 / CPU 使用情况；
  2. 检查是否有内存泄漏 / 内存溢出；
• 修复：
  • 优化内存使用（释放无用资源、避免泄漏）；
  • 减少 CPU 占用（优化算法、避免无限循环）。

3. 第三步：验证修复效果

修复后，需通过以下方式验证：

• 本地测试：模拟触发场景（如点击按钮、批量操作），用 Profiler 监控主线程耗时；
• 压测：高频触发相关操作，观察是否再出现 ANR；
• 线上监控：发布灰度版本，查看第三方工具的 ANR 率是否下降；
• 日志复查：若仍有 ANR，重新导出 traces.txt，确认根因是否已解决。

监控分析总结

简单来说，监控 ANR 是「及时发现问题」，分析 ANR 是「精准定位根因」，两者结合才能高效解决 ANR 问题。

1. 监控 ANR：开发阶段用 adb logcat + traces.txt，线上阶段用自定义 Looper 监控 + 第三方 SDK；
2. 分析 ANR：核心是从 traces.txt 定位主线程阻塞点，按「耗时操作 / 锁阻塞 / 消息堵塞 / 资源不足」分类修复；
3. 核心原则：ANR 的本质是主线程阻塞，避免 ANR 的关键是耗时操作异步化，主线程只做 UI 相关工作。

监控 ANR 关键点

1. 开发阶段用 adb logcat 和 traces.txt 实时监控，快速定位本地 ANR；
2. 应用层通过 Hook Looper 实现自定义 ANR 预警，提前捕获潜在问题；
3. 线上环境优先使用第三方工具（Bugly/Matrix），自动上报 ANR 并生成分析报告。

分析 ANR 关键点

1. 核心是从 traces.txt 中找到主线程的状态和阻塞代码行；
2. 按「耗时操作」「锁阻塞」「消息队列堵塞」「资源不足」分类分析根因；
3. 修复后通过本地测试 + 线上监控验证效果，确保 ANR 问题彻底解决。

Android ANR 分析排查清单

本清单覆盖 日志获取→根因定位→修复验证 全流程，可直接用于开发调试和线上问题排查。

额外备注

1. 若 traces.txt 权限不足，可在测试机上开启 root 权限，或使用 debug 包调试。
2. 线上 ANR 问题，优先查看第三方工具的 ANR 聚合报告，可快速定位高频发生的 ANR 点。