在线“杀死” App 的卡顿难题！

ANR（Application Not Response）是安卓开发团队经常遇到的无响应问题，但却很难定位和根除。尤其是线上问题，由于难以复现，导致开发者难以有效地快速解决。为此，本⽂将为大家分享作者是如何在⼀个⽉内降低 50% 的 ANR 线上问题发⽣率的探索与实践，希望能对开发者有所帮助或启发。

Google 的一项内部研究表明，过高的崩溃与 ANR 发生率会直接影响应用的评分情况，并且很难在商店中累积起用户量，严重影响应用在商店的排名情况。这一系列的连锁反应将会给应用带来很大的损失，且有可能失去在应用商店获得谷歌推荐的资格。因此，ANR 问题对于⼤多数安卓团队来说十分棘手，尤其是线上问题令人头疼。因为本地问题可以复现，线上 ANR 却很难。因而探究线上 ANR 问题的治理⽅案更具意义。

触因与流程分析

1. 关于 ANR

从用户侧看， ANR 问题是指⽤户在使⽤应⽤过程中出现了严重卡顿或卡死时，系统给出的⽆响应提示弹窗。而从系统侧看，ANR 问题就是 AMS 在执⾏特定⽅法时出现的超时错误，触发点有四个：

InputDispatching Timeout
BroadcastQueue Timeout
Service Timeout
ContentProvider Timeout

系统的 ANR 触发流程⼤致可分为两个部分：

⽤户可以直观感受到的 ANR 弹窗，这部分由 AMS 处理。

同时 AMS 还会发出⼀个 SIGQUIT 信号：