android anr原因,android系统事件的响应 _为什么手机软件经常无响应

稳定性问题简述Android 的稳定性是 Android 性能的一个重要指标，它也是 App 质量构建体系中最基本和最关键的一环；如果应用经常崩溃，或者关键功能不可用，那显然会对我们的留存产生重大影响
【android anr原因,android系统事件的响应】所以为了保障应用的稳定性，我们首先应该树立对稳定性的正确认识
从表现来看有:死机重启自动关机无法开机冻屏黑屏闪退无响应等等情况

文章插图
这也就说明了稳定性问题比较杂，且很多是概率性问题，没有统一处理方式，需要针对具体的问题，具体分析
一般来说：必现的问题较易解决，针对当前代码添加各种调试 log ，一步步 debug 去定位，过程虽然可能慢点，但一般都会解决
针对偶发性的概率问题，则较为麻烦，依赖于大量的测试复现，然后统计分析当前抓取到的 events 、system 等 log 中，找到复现的步骤，然后去定位；且针对与这种概率问题，最好能够拿到当时的现场，所以有时候需要将 tombstone 或者 ANR 、crash 转为 ANR 去处理
从技术层面来划分：无外乎两大类：长时间无法执行完成(Timeout) 以及异常崩溃(crash). 主要分类如下所示:
ANRWatchdogCrash、界面、流程异常TombstonePanic接下来我们细说一下 ANR应用程序无响应即 Application not Responding，简称“无响应”或 “ANR”
为什么会有 ANR?如上所述，ANR 的产生需要同时满足三个条件：
主线程：只有应用程序进程的主线程响应超时才会产生 ANR超时时间：产生 ANR 的上下文不同，超时时间也会不同，但只要在这个时间上限内没有响应就会 ANR输入事件/特定操作：输入事件是指按键、触屏等设备输入事件，特定操作是指 BroadcastReceiver 和 Service 的生命周期中的各个函数，产生 ANR 的上下文不同，导致 ANR 的原因也会不同ANR 机制本身就是为了防止差的用户体检，是完全 Android 系统工程师为大家埋下的雷；这个雷既然是工程师设计的，那就可以被工程师控制
比如像我们通常说按键 5s 内时间处理不完的 ANR ，这个 5s 在一些低端手机上被修改为 8s 甚至 10s ,还有就是 ANR 产生后，相关的“现场”是会被保留下来比如在 events log、main log、system log 上有相关的 ANR 信息；再比如出现 ANR 的时候生成的 trace 文件，bugreport 中也有一些有用的信息，帮我们分析 ANR 产生的原因现在好多平台 cpu 都是多核，cpu 达到 100% 都不能说明就是系统卡顿导致的 ANR
还要说明，系统 ANR in 往往比 event log 中的 am_anr 会慢很多；具体慢多少需要根据场景而定，所以建议以 event log 中的 am_anr 作为时间窗口起点比较好

文章插图
那ANR in 能看到哪些信息呢?Reason: ANR 原因，这个在 evnent log 中也可以看到作用不大；原因可以定位 ANR 的时间窗口，比如按键类型的 ANR 那分析的时候只需要在 event log 的am_anr 之前 5s 的时间窗口中分析就行Load: 0.06 / 0.05 / 0.05 cpu 负载，这个可以看到是否是系统性能整体慢的参考指标。但是各个平台这个参数又不统一。所以参考价值不大TOTAL: 这个是整体 cpu 占用情况如果能够看到 kernel 占用比较多，可以考虑是否是系统问题那如何证明系统卡顿导致的 ANR 呢？如果是由系统引起的卡顿在 event log 中搜索dvm_lock_sample，因为往往在系统卡顿的时候 dvm_lock_sample 会打印出系统主线程的一些主要方法耗费了多少时间
dvm_lock_sample: [system_server,1,Binder:1614_A,22,AlarmManagerService.java,1072,-,2496,4] （进程名,是否主线程1是0否,线程号,花费时间,文件名,申请锁行数，持锁文件名，持锁行数,采样频率）今天关于 ANR 的相关技术知识点就分享到这里了；关于 ANR 的技术问题，我们还要去好好的学习剖析；因此我把工作中遇到的性能卡顿问题，以及对网上大部分的资料的收集和整理，最终整合出了一份《Android 高工必备性能优化》学习文档，有需要这份文档的朋友，可以私信发送 “进阶” 即可免费获取