閃退、崩潰、無響應、重啟等是應用穩定性常見的問題現象，穩定性故障大體可歸類為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