背景
闲鱼在业务的快速迭代过程中，面临着稳定性的考验，尤其是ANR（应用程序无响应）问题尤为突出，在舆情平台偶尔可以看到有用户反馈闲鱼App卡顿、卡死的的情况。发生ANR时系统会弹框引导用户关闭应用，或者直接杀死应用进程，非常影响使用体验，甚至造成用户流失。
ANR问题的难点在于线下极难复现，平时测试过程中几乎没有ANR问题的反馈，但是到了线上，面对Android碎片化机型、系统运行状态、用户操作习惯，导致出现ANR问题。所以必须依靠监控排查针对性地解决问题。
本文主要从ANR监控、排查体系、优化案例几个方面阐述闲鱼对ANR问题治理的思路。
ANR引入的原因
要解决ANR问题首先需要了解ANR引入的原因。Android系统通过对应用进程的组件（Activity，Service，Receiver，Provider、input）的响应能力进行超时监控，如果超过预定时间应用进程还未完成任务，则会触发系统的ANR警告。
所以ANR引入的原因可以分为两大类
- 主线程繁忙，来不及处理关键消息：存在耗时消息、或者消息队列拥塞，关键消息得不到调度、或者发生死锁
- 系统繁忙，主线程得不到调度：系统或应用内部其它线程或资源负载过高（高IO、内存频繁抖动），主线程调度被严重抢占
监控方案
1. 监听anr目录的变化
使用FileProvider监听 /data/anr/traces.txt 文件的变化，并捕获现场进行上报。不过Android 6.0以上版本系统文件权限收紧后，没有读取这个文件的权限。之前我们采用这个监控方案导致大量高版本设备ANR问题漏报。
2. 主线程超时监测
开启一个子线程定期post一个message到主线程，每隔一段时间（比如5秒）监测该message是否被消费掉，如果没有被处理，则说明主线程被卡住，可能发生了ANR，再通过系统服务获取当前进程的错误信息，判断是否有ANR发生。
但这个会存在大量漏报的情况，并且轮询的方案性能不佳。
3. 监听 SIGQUIT 信号
系统服务在触发ANR后，会发送一个SIGQUIT信号到应用进程来触发dump traces，在应用侧我们可以监听SIGQUIT信号来判断是否发生了ANR。为了排除其他进程的ANR导致的误报，需要再通过系统服务获取当前进程的错误信息，进一步过滤。
第3种方案准确率高，性能损耗小，也是业界目前主流APP采用监控方案。
排查体系
选择了合适的监控方案之后，还需要完善的排查体系以便对ANR问题归因分析。
1. ANR traces信息
Crash sdk在监听SIGQUIT信号后，会调用art虚拟机内部dump堆栈的接口，获取ANR traces信息，包含ANR进程中所有线程的堆栈，据此可以分析出是否有主线程耗时、死锁、主线程等待锁、主线程sleep等问题。
下图为相册场景下卡死ANR，通过trace文件可以定位到原因为主线程在等待子线程。
下图为webview场景下ANR，通过trace文件可以定位到原因为主线程主动循环sleep，等待资源初始化完成。
2. 主线程消息队列监控
在依靠ANR traces信息修复有明确堆栈的问题之后，剩下比较多的是nativePollOnce的问题，如下图堆栈
堆栈上都是系统消息队列的源码，没有业务代码，似乎不好定位分析。
进入nativePollOnce场景可能的几种情况：
- 当前没有待处理的消息，线程进入睡眠状态，等待管道另一端有入队消息唤醒；
- 消息队列其实有消息待处理，但是被设置了同步屏障，遍历队列消息列表如果没有找到异步消息，则会进入nativePollOnce等待唤醒；
- dump traces 过于耗时导致偏移，耗时消息在dump之前发生。
对于第2点情况，可以通过hook消息队列，检测是否有同步屏障泄露的情况，我们在线上小范围采样埋点并没有发现此类问题。
对于第3点情况，可以对ANR发生前主线程消息队列历史消息做监控，在发生耗时消息时主动上报，在发生ANR时把历史消息、当前消息、等待队列的消息通过crash sdk上报云端。
实现方案
通过设置主线程Looper的Printer，监控每一个消息的调度，记录消息的target、callback、what，以及当前时间戳。
同时开启一个子线程，如果有消息处理发生则会定时采集主线程的堆栈，并通过时间戳将堆栈与消息关联起来，从而可以了解每个消息在执行时主线程的堆栈。
public final class Looper {
public static void loop() {
......
for (;;) {
......
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
......
try {
msg.target.dispatchMessage(msg);
} finally {
...
}
......
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
}
......
}
}由于存在频繁的字符串拼接，对性能有一定损耗，只会对线上小范围采样开启。
方案效果
通过对消息队列的监控，可以看到有一个消息执行耗时155ms，挂钟耗时411ms，观察堆栈可知原因是在主线程调用较重的初始化操作，并且存在跨进程调用，一但阻塞了后面Receiver、Service等消息执行，则会触发系统服务ANR警告。
优化案例
在具备完善准确的监控排查能力之后，下面分享一些优化案例。
1. SharedPreference优化
从线上ANR的traces数据来看，关于sp导致的anr问题主要集中在3类：
- 在特定消息处，主线程等待sp apply队列持久化完成
- 主线程对sp commit
- 主线程阻塞等待sp加载数据完成
在线下测试mmkv与sp对比性能数据，发现mmkv可以比较完美的解决这三个问题。
首次安装分别测试mmkv和sp的读写性能（循环1000次取总和，每个key、value均不相同）：
第2次启动，只读取kv组件的一个值
我们在编译器通过切面的方式接管所有getSharedPreferences的接口调用，根据白名单配置返回mmkv实现或者原始系统的SharedPreferencesImpl实现，对业务层使用无感知。
2. 网络广播监听耗时优化
从线上ANR的traces数据来看，关于getActiveNetworkInfo的ipc调用不少，通过埋点发现一方面是由于ipc跨进程通信本身耗时，另一方面监听网络状态的广播监听者实例过多，每一个都会重复调用一次查询网络状态，每个累加造成了耗时加剧，一旦阻塞了关键消息的调度执行，则会引发ANR
优化方案为通过动态代理IConnectivityManager接口，拦截代理getActiveNetworkInfo方法，优先使用缓存，
由统一全局的网络广播监听器在异步线程IPC获取网络信息，更新缓存，后面可以直接使用缓存，避免多次IPC调用。
3. 启动组件延迟注册
启动Application#onCreate阶段有串行任务会阻塞主线程执行，此时系统发送的关键消息得不到主线程调度就会发生ANR。
修复的核心思想是尽量不要在启动阶段注册receiver、service等组件，或者延迟到onCreate全部执行完毕再注册。
public class MyApplication extends Application {
@Override
public void onCreate() {
//耗时串行任务...
isInitDone=true;
}
@Override
public Intent registerReceiver(final BroadcastReceiver receiver, final IntentFilter filter) {
if (isInitDone) {
return super.registerReceiver(receiver, filter);
}
mainHandler.post(new Runnable() {
@Override
public void run() {
MyApplication.super.registerReceiver(receiver, filter);
}
});
return null;
}
}总结和展望
在对ANR问题的监控升级和排查能力的完善之后，通过解决一系列优化方案，ANR率下降一半以上，给用户带来更好的使用体验。希望本文的内容可以开发者治理ANR带来启发，把我们应用代码的性能做到极致。
后续我们会思考以下两方面的内容：
- 继续加强对ANR问题优化治理，比如将关键消息切到异步线程执行，避免主线程队列拥塞得不到调度的情况；
- 加强防御机制防止数据劣化，比如线下自动化稳定性测试提前发现新增问题。
