日志关键字：InputDispatching Timeout
日志关键字：Timeout of broadcast BroadcastRecord
日志关键字：Timeout executing service
日志关键字：Timeout publishing content providers
经过大量ANR案例的分析，总结出以下三个ANR问题产生的典型场景：
主线程被其他线程锁(占比57%)：调用了thread的sleep()、wait()等方法，导致的主线程等待超时。
系统资源被占用(占比14%)：其他进程系统资源(CPU/RAM/IO)占用率高，导致该进程无法抢占到足够的系统资源。
[]( )2、解决ANR问题方法论
导出ANR日志信息，根据日志信息，判断确认发生ANR的包名类名，进程号，发生时间，导致ANR原因类型等。
关注系统资源信息，包括ANR发生前后的CPU，内存，IO等系统资源的使用情况。
查看主线程状态，关注主线程是否存在耗时、死锁、等锁等问题，判断该ANR是App导致还是系统导致的。
ANR问题发生时，系统会收集ANR相关的日志信息，CPU使用情况，trace日志也就是各线程执行情况等信息，生成一个traces.txt的文件并且放在/data/anr/路径下。
注意：每一次新的ANR问题的发生，会把之前的ANR信息覆盖掉。
我们可以通过adb命令将traces文件导出到本地。
adb root
adb shell ls /data/anr
adb pull /data/anr/<filename>
复制代码
1）在log中找到ANR发生信息： Traces文件中的关键字，例如：
09-24 15:20:20.211 1001 1543 1570 XXXXXXX： ANR in xxxxxx
09-24 15:20:20.211 1001 1543 1570 XXXXXXX： PID: xxxxx
09-24 15:20:20.211 1001 1543 1570 XXXXXXX： Reason: xxxxxx
复制代码
其中：
ANR in中，包括导致ANR的包名，类名
PID 中，为发生ANR的进程PID
2）找到CPU Usage信息
09-24 15:20:20.211 1001 1543 1570 XXXXXX： CPUusage from xxx to xxx ago xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
09-24 15:20:20.211 1001 1543 1570 XXXXXX： CPUusage from xxx to xxx later xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
复制代码
其中
ago 表示ANR发生前的CPU的使用情况
later表示ANR发生后的CPU的使用情况
分析CPU usage以后，如若还是无法找出问题原因，则需要进一步分析trace文件。traces文件中详细记录了发生ANR前后该进程的各个线程的Stack，一般从主线程的stack入手分析，查看分析ANR问题发生前，应用是否有异常。
其中不同场景下的ANR问题情况不大相同，需要具体情况具体分析，此处就不展开详细描述。
[]( )3、ANR问题难点及破题思路
用户在应用内的绝大部分操作，比如按钮点击，加载资源，页面跳转等操作，都需要有App的主动反馈，但ANR发生时，在用户等待数秒后，仅会弹出一个“应用无响应”的弹窗给用户，这会给用户带来“应用难用”的感觉，极其影响用户体验。
但是，现网中的ANR问题又很难处理，问题包括但不限于：
平时的测试难以覆盖，毕竟ANR经常出现在老设备、弱网络环境的场景下，测试难以做到全场景覆盖。
对于现网应用的ANR问题，如果问题非必现，则定位难度较高，需要有可以复现问题的实际设备在身边，才能获取到具体日志trace等信息。
[]( )3.2 ANR处理新方案
除了依赖现有传统的ANR问题定位经验，配合第三方应用监控平台、进行ANR问题的处理，也是方便快捷的ANR处理手段。
提升用户体验迫在眉睫，但ANR问题对用户体验影响大， 定位解决ANR问题老大难，针对这个需求痛点，越来愈多的第三方开始研究并对外提供应用性能监控工具。
**性能管理（App Performance Management，简称APM）**是华为AppGallery Connect质量系列服务中的其中一项，提供分钟级应用性能监控能力，其ANR分析功能，更是解决ANR问题定位与处理的最佳搭档。使用AGC性能管理服务监控应用ANR，能够为您带来以下好处：
1.实时监控现网应用ANR，现网应用ANR趋势全掌握。
2.ANR现场信息自动采集和展示，大部分情况无需复现，在线定位问题。
3.通过APM页面，定位思路系统化，快速上手ANR问题定位，及时解决问题。
[]( )4、ANR问题解决案例整理
接下来以华为AGC性能管理服务为例，介绍配合AGC性能管理服务，如何快速定位典型的ANR问题。
4.1.1 发现问题 在华为AGC控制台的我的项目-质量-性能管理页面，在“ANR分析”页签下，发现排在第一位的“用户ANR率”高达16.67%，决定优先解决该类ANR问题。
4.1.2 定位问题 点开TOP排行榜中该类问题卡片，进入了该类“ANR问题详情”页面，进一步查看分析该ANR 问题的数据报告。
在这个“ANR问题详情”页面中，分析用户数分布饼图，发现该类ANR问题在“应用版本2.0”、“手机型号HUAWEI VOG-AL10”、“系统版本10”这三个条件下，ANR影响的用户数最多。
在报告下方的“发生记录”中，找到满足这三个条件的发生记录，点击“查看详情”准备针对具体的问题进行分析。
(1) 分析系统资源状态 首先，通过报告，发现该问题发生时，CPU占用是20%、IO占用是0%、未发生过低内存、应用被分配堆是26.50MB、应用已用堆是8.69MB，线程数是61，从系统资源来看，未出现明显的异常，如下图所示：
因为ANR问题原因可以分为两大类，一是系统资源不足导致，二是自身代码逻辑导致，综合以上系统资源信息，该ANR问题不是由于系统资源不足导致，那么分析该ANR问题思路转变为：该ANR问题由自身代码逻辑导致，接下来，我们顺着该思路分析这次的ANR问题。 (2) 查看主线程状态：发现ANR代码片段 自身代码逻辑导致ANR问题，其主要分析思路是查看主线程堆栈及线程状态，我们在性能管理页面上“主线程堆栈”页签中能够找到问题堆栈，发现该问题发生时，主线程处于获取锁状态，到此我们能够得出结论：该ANR问题是因为主线程一直在等待锁资源，而被阻塞，导致了后续输入事件未被响应，从而触发了应用的“Input dispatching timed out”类型的ANR。
查看具体的堆栈信息，我们找到了ANR问题代码片段，发现死锁是发生在“com.aiops.hiperformance.MainActivity.dispatchActivityDestroyed”调用中。查看代码发现，死锁发生在“mLock.readLock().lock()”函数中。
希望本文对你有所启发，有任何面试上的建议也欢迎留言分享给大家。
好了，今天的分享就到这里，如果你对在面试中遇到的问题，或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己，对于自己的未来还不够了解不知道给如何规划，可以加一下下面的技术群。来看看同行们都是如何突破现状，怎么学习的，来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。
这里放一下资料获取方式：GitHub
好了~如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。
为什么某些人会一直比你优秀，是因为他本身就很优秀还一直在持续努力变得更优秀，而你是不是还在满足于现状内心在窃喜！希望读到这的您能点个小赞和关注下我，以后还会更新技术干货，谢谢您的支持！
标签：
（0）