闪退、崩溃、无响应、重启等是应用稳定性常见的问题现象，稳定性故障大体可归类为ANR/冻屏、Crash/Tombstone、资源泄露三大类。本文通过对三类故障的产生原因、故障现象、触发机制及如何定位等，展开深度解读。

本文将详解ANR类故障，并通过一个Binder阻塞问题案例，演示如何有效定位ANR类故障。

1、ANR问题原因分析

2、ANR问题定位方法

1）打开system_app_anr@XXXX文件，查看ANR发生进程、进程号、主线程状态，是不是有明显的死锁或者明显binder调用阻塞；
2）如果是死锁，看业务代码即可；
3）如果是binder阻塞，查看binder调用链信息，查找对端进程及其对端进程调用stack，找到阻塞函数，如果system_app_anr@XXXX被截断，可以查看traces.txt文件；
4）如果是nativepollonce，可以查看BlockMonitor日志，是否主线程有比较耗时的操作；CPU占用率情况，iowait情况；最有效的是分析systrace日志；
5）如果system_app_anr@XXXX中没有发生anr的调用stack，一般是三种情况：

ANR进程处于D state，导致无法响应SIG 3信号，从而导致无法打印stack，可以通过sysrq信息确认；
ART处于死锁状态，由于ART本身bug导致无法处理SIG 3操作；
ANR进程获取不了足够的时间无法打印调用stack。

3、Binder阻塞ANR案例分析

3.1 ANR主栈分析

可以明确，这个ANR发生的原因，是Binder阻塞：

此时主线程，阻塞在isCoverOpen函数。

3.2 Binder阻塞分析

查找对应的binder transaction信息，分析binder被阻塞的原因。

（1）确认ANR发生的binder

阻塞的binder是aod发生给systemserver的，但看不到systemserver的Binder线程，故需要看看systemserver的Binder情况。

（2）确认对端binder

分析2618的主栈。

在binder transcation表中可以看到，systemserver进程的16个Binder线程，全部被阻塞在给hwfacerecognize发送消息。

在Android中一个进程最多会使用16个binder线程，systemserver的全部Binder线程都被阻塞，故不能再分配Binder线程处理其他的Binder消息，导致其他进程给systemserver发送Binder消息时是会被阻塞，且没有对端binder线程的。

故问题的焦点，转移到了hwfacerecognize（PID 727）的进程上。

（3）业务代码分析

hwfacerecognize（PID 727）是人脸识别的进程，联合人脸识别模块的分析，发现是727进程出现crash。

稳定性优化需要开发者持续运营和维护，并对稳定性涉及的多项知识领域进行了解，才能更好的设计出稳定性优化方案，进而提升用户使用体验。

转载学习：https://mp.weixin.qq.com/s?__biz=MzIzODM4NTkxNA==&mid=2247493852&idx=1&sn=3e4d0dd17601fd84550073cb00e600e2&chksm=e9388749de4f0e5f5a5c91b0bf05dffa809409b25762a7743c6e34d6498750a4e3be2bbc55c7&scene=21#wechat_redirect