关于闲鱼的 ANR 治理，我有几条心得

背景

闲鱼在业务的快速迭代过程中，面临着稳定性的考验，尤其是ANR（应用程序无响应）问题尤为突出，在舆情平台偶尔可以看到有用户反馈闲鱼App卡顿、卡死的的情况。发生ANR时系统会弹框引导用户关闭应用，或者直接杀死应用进程，非常影响使用体验，甚至造成用户流失。

ANR问题的难点在于线下极难复现，平时测试过程中几乎没有ANR问题的反馈，但是到了线上，面对Android碎片化机型、系统运行状态、用户操作习惯，导致出现ANR问题。所以必须依靠监控排查针对性地解决问题。本文主要从ANR监控、排查体系、优化案例几个方面阐述闲鱼对ANR问题治理的思路。

ANR引入的原因

要解决ANR问题首先需要了解ANR引入的原因。Android系统通过对应用进程的组件（Activity，Service，Receiver，Provider、input）的响应能力进行超时监控，如果超过预定时间应用进程还未完成任务，则会触发系统的ANR警告。所以ANR引入的原因可以分为两大类

1. 主线程繁忙，来不及处理关键消息：存在耗时消息、或者消息队列拥塞，关键消息得不到调度、或者发生死锁

2. 系统繁忙，主线程得不到调度：系统或应用内部其它线程或资源负载过高（高IO、内存频繁抖动），主线程调度被严重抢占

监控方案

监听anr目录的变化

使用FileProvider监听 /data/anr/traces.txt 文件的变化，并捕获现场进行上报。不过Android 6.0以上版本系统文件权限收紧后，没有读取这个文件的权限。之前我们采用这个监控方案导致大量高版本设备ANR问题漏报。

主线程超时监测

开启一个子线程定期post一个message到主线程，每隔一段时间（比如5秒）监测该message是否被消费掉，如果没有被处理，则说明主线程被卡住，可能发生了ANR，再通过系统服务获取当前进程的错误信息，判断是否有ANR发生。但这个会存在大量漏报的情况，并且轮询的方案性能不佳。

监听 SIGQUIT 信号

系统服务在触发ANR后，会发送一个SIGQUIT信号到应用进程来触发dump traces，在应用侧我们可以监听SIGQUIT信号来判断是否发生了ANR。为了排除其他进程的ANR导致的误报，需要再通过系统服务获取当前进程的错误信息，进一步过滤。第3种方案准确率高，性能损耗小，也是业界目前主流APP采用监控方案。

排查体系

选择了合适的监控方案之后，还需要完善的排查体系以便对ANR问题归因分析。

ANR traces信息

Crash sdk在监听SIGQUIT信号后，会调用art虚拟机内部dump堆栈的接口，获取ANR traces信息，包含ANR进程中所有线程的堆栈，据此可以分析出是否有主线程耗时、死锁、主线程等待锁、主线程sleep等问题。

下图为相册场景下卡死ANR，通过trace文件可以定位到原因为主线程在等待子线程。

下图为webview场景下ANR，通过trace文件可以定位到原因为主线程主动循环sleep，等待资源初始化完成。

主线程消息队列监控

在依靠ANR traces信息修复有明确堆栈的问题之后，剩下比较多的是nativePollOnce的问题，如下图堆栈

堆栈上都是系统消息队列的源码，没有业务代码，似乎不好定位分析。进入nativePollOnce场景可能的几种情况：

1.当前没有待处理的消息，线程进入睡眠状态，等待管道另一端有入队消息唤醒；

2.消息队列其实有消息待处理，但是被设置了同步屏障，遍历队列消息列表如果没有找到异步消息，则会进入nativePollOnce等待唤醒；

3.dump traces 过于耗时导致偏移，耗时消息在dump之前发生。

对于第2点情况，可以通过hook消息队列，检测是否有同步屏障泄露的情况，我们在线上小范围采样埋点并没有发现此类问题。对于第3点情况，可以对ANR发生前主线程消息队列历史消息做监控，在发生耗时消息时主动上报，在发生ANR时把历史消息、当前消息、等待队列的消息通过crash sdk上报云端。

实现方案

通过设置主线程Looper的Printer，监控每一个消息的调度，记录消息的target、callback、what，以及当前时间戳。同时开启一个子线程，如果有消息处理发生则会定时采集主线程的堆栈，并通过时间戳将堆栈与消息关联起来，从而可以了解每个消息在执行时主线程的堆栈。

   publicfinalclass Looper{    
public static void loop(){    
......    
    
for(;;) {    
......    
finalPrinter 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("<<<<<Finishedto" +msg.target+ " " +msg.callback);    
}    
}    
......    
}    
}    

由于存在频繁的字符串拼接，对性能有一定损耗，只会对线上小范围采样开启。

方案效果

通过对消息队列的监控，可以看到有一个消息执行耗时155ms，挂钟耗时411ms，观察堆栈可知原因是在主线程调用较重的初始化操作，并且存在跨进程调用，一但阻塞了后面Receiver、Service等消息执行，则会触发系统服务ANR警告。

优化案例

在具备完善准确的监控排查能力之后，下面分享一些优化案例。

SharedPreference优化

从线上ANR的traces数据来看，关于sp导致的anr问题主要集中在3类：1.在特定消息处，主线程等待sp apply队列持久化完成2.主线程对sp commit3.主线程阻塞等待sp加载数据完成在线下测试mmkv与sp对比性能数据，发现mmkv可以比较完美的解决这三个问题。首次安装分别测试mmkv和sp的读写性能（循环1000次取总和，每个key、value均不相同）：

第2次启动，只读取kv组件的一个值 我们在编译器通过切面的方式接管所有getSharedPreferences的接口调用，根据白名单配置返回mmkv实现或者原始系统的SharedPreferencesImpl实现，对业务层使用无感知。

网络广播监听耗时优化

从线上ANR的traces数据来看，关于getActiveNetworkInfo的ipc调用不少，通过埋点发现一方面是由于ipc跨进程通信本身耗时，另一方面监听网络状态的广播监听者实例过多，每一个都会重复调用一次查询网络状态，每个累加造成了耗时加剧，一旦阻塞了关键消息的调度执行，则会引发ANR优化方案为通过动态代理IConnectivityManager接口，拦截代理getActiveNetworkInfo方法，优先使用缓存， 由统一全局的网络广播监听器在异步线程IPC获取网络信息，更新缓存，后面可以直接使用缓存，避免多次IPC调用。

启动组件延迟注册

启动Application#onCreate阶段有串行任务会阻塞主线程执行，此时系统发送的关键消息得不到主线程调度就会发生ANR。修复的核心思想是尽量不要在启动阶段注册receiver、service等组件，或者延迟到onCreate全部执行完毕再注册。

   publicclass MyApplication extends Application{    
    
@Override    
public void onCreate(){    
//耗时串行任务...    
isInitDone=true;    
}    
    
@Override    
public Intent registerReceiver(final BroadcastReceiver receiver, final IntentFilter filter){    
if(isInitDone) {    
returnsuper.registerReceiver(receiver, filter);    
}    
    
mainHandler.post(newRunnable() {    
@Override    
public void run(){    
MyApplication.super.registerReceiver(receiver,filter);    
}    
});    
    
returnnull;    
}    
}    

总结和展望

在对ANR问题的监控升级和排查能力的完善之后，通过解决一系列优化方案，ANR率下降一半以上，给用户带来更好的使用体验。希望本文的内容可以开发者治理ANR带来启发，把我们应用代码的性能做到极致。后续我们会思考以下两方面的内容：•继续加强对ANR问题优化治理，比如将关键消息切到异步线程执行，避免主线程队列拥塞得不到调度的情况；•加强防御机制防止数据劣化，比如线下自动化稳定性测试提前发现新增问题。