文章目录
- 一、ANR概述
- 二、触发ANR的主要场景
- 三、Android四大组件中的潜在的ANR风险
- 五、避免ANR的实践建议
- 六、ANR的产生原因与出现的场景
- 6.1 原因：
- 6.2 出现场景：
- 七、ANR的定位与分析
- 7.1. ANR分析思路——traces
- 7.2 ANR其他分析思路与相关日志
- 7.2.1 分析logcat思路
- 7.2.2 分析kernel思路
- 7.2.3 分析cpuinfo思路
- 7.2.4 分析meminfo思路
- 7.3. traces.txt重要字段
- 八、ANR分析案例
- 8.1 分析案例一：Input ANR
- 8.2 分析案例二：在系统的方法上的锁没释放
- 8.3 主线程被其他线程lock，导致死锁
- 8.4 分析案例三 内存问题
- 8.4 分析案例四 GC问题
- 参考
在Android开发中，应用程序无响应（ANR）是一个常见的问题，特别是当应用程序的主线程被长时间阻塞时。本文将深入探讨ANR的定义、常见触发场景以及如何避免这些问题。
一、ANR概述
ANR（Application Not Responding）是指Android系统在检测到应用程序主线程长时间阻塞而无法响应用户输入时触发的错误。
当用户界面线程（UI线程）被阻塞超过一定时间限制时，系统会认为应用程序已经崩溃或停止响应，并显示一个强制关闭应用的对话框，以确保用户体验。
二、触发ANR的主要场景
在Android开发中，ANR（Application Not Responding）主要可以分为以下几种类型，这些类型涵盖了不同情况下可能触发ANR的场景：
-
Input Dispatching Timeout：
当一个输入事件（如触摸屏事件或按键事件）在特定时间内无法及时处理时，系统会认为应用程序无响应。通常情况下，该超时限制为5秒。 -
BroadcastQueue Timeout：
前台广播接收器（Foreground Broadcast Receivers）在特定时间内无法处理完所有广播消
