作者：layz4android

ANR（Application Not Response）应用程序未响应，当主线程被阻塞时，就会弹出如下弹窗

要么关闭当前app，要么就等待，其实这个时候没有挽救的措施，选择等待最终的结果也是ANR，最终都需要杀掉应用进程，我们看下日志，原因是Input dispatching timed out，点击事件处理超时导致ANR。

2022-08-27 16:11:53.168 2057-2080/system_process E/ActivityManager: ANR in com.lay.image_process (com.lay.image_process/.MainActivity)PID: 31848Reason: Input dispatching timed out (Waiting to send non-key event because the touched window has not finished processing certain input events that were delivered to it over 500.0ms ago.  Wait queue length: 6.  Wait queue head age: 5525.3ms.)

其实相对于其他的错误，ANR比较棘手在于，没有崩溃日志，定位问题比较困难，而且ANR是必须要解决的问题，这个用户体验极差，因此本章的核心在于攻坚ANR问题。

1 ANR原因总结

从上面的日志中，我们看到造成ANR的原因是Input dispatching timed out，那么除此之外，还有什么其他的错误。

1.1 KeyDispatchTimeout

input事件在5s之内没有处理，产生ANR；这种异常是比较常见的问题，常发生在点击事件处理中，logcat的关键字就是Input dispatching timed out

这里需要说明一点，Input事件导致ANR跟下面几种不同的是，看下面的代码，点击按钮5s后，才弹出toast，这种情况下会发生ANR吗？

btnSend.setOnClickListener {Thread.sleep(5 * 1000)ToastUtils.setText(this)
}

我们可以在私下测试一下，其实是不会的，如果用户后续没有继续输入事件，那么就不会产生ANR

1.2 BroadCastTimeout

class MyBroadCast : BroadcastReceiver(){override fun onReceive(context: Context?, intent: Intent?) {//TODO 接收广播}
}

我们在使用广播接收器接收广播时，需要重写BroadcastReceiver的onReceive方法，当前方法是在主线程中，如果在10s内没有处理弯沉，就会ANR。

因此，在onReceive方法中不能做耗时操作，如果需要则需要创建新的线程。logcat关键字是 Timeout of broadcast BroadcastRecord

1.3 ServiceTimeout


class MyService : Service(){override fun onCreate() {super.onCreate()}override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {return super.onStartCommand(intent, flags, startId)}override fun onBind(intent: Intent?): IBinder? {TODO("Not yet implemented")}}

同样，在Service中依然不能做耗时操作，如onCreate、onStartCommand、onBind方法中如果超过20s没有处理完成，就会ANR。

所以如果需要在服务中执行耗时操作，建议使用IntentService，logcat关键字是 Timeout executing service

1.4 ContentProviderTimeout

四大组件最后一个组件，如果ContentProvider在10内没有处理就会导致ANR，这个组件使用很少，暂时先不分析

综上所述，如果出现ANR，主要原因就是在主线程执行了耗时操作，导致UI线程被阻塞发生ANR；那么在我们的实际项目中，有哪些操作，可能会导致ANR呢？

1. 主线程进行频繁的IO操作

不知道我们还有多少在使用SP存储的，其实它底层就是通过IO读写操作文件，如果频繁地在主线程进行SP读写可能会造成卡顿或者ANR，之前就有过线上的ANR事故，建议大家都是用MMKV，读写速度秒杀SP；

除此之外，主线程进行网络操作也会导致ANR

2. 多线程争夺资源导致死锁
3. CPU资源耗尽

等等…

2 ANR问题解决

2.1 线下问题解决

如果在我们实际的开发过程中，如果出现ANR，那么很简单，打开logcat窗口就可以查看，还有一种方式，就是查看trace日志，路径为 /data/anr/xxx

打开trace日志，通过这一部分就能猜到具体原因了，就是因为在主线程中，响应点击事件时，线程进入休眠阻塞

线下出问题对于我们来说永远都是最简单的，难的就是在线上出了问题，用户隔你十万八千里，该如何处理？

2.2 线上问题解决

2.2.1 Bugly

可能很多小伙伴的项目中都集成了bugly，确实bugly是很不错的线上监控组件，像Crash、ANR都能够检测到，但是很多时候，日志是不全的，堆栈信息不全就没法定位问题，bugly可以作为兜底方案，具体的监控方案，我们可以自己实现。

2.2.2 FileObserver

对于线上监控，往往有两种方式，我这边先讲解第一种，通过FileObserver监听某个目录下文件是否发生变化，这里不言而喻了，就是/data/anr/xxx，如果当前文件夹中的文件发生变化，那么意味着ANR发生了，首先我们先了解一个这个类。

@Deprecated
public FileObserver(String path) {this(new File(path));
}/*** Equivalent to FileObserver(file, FileObserver.ALL_EVENTS).*/
public FileObserver(@NonNull File file) {this(Arrays.asList(file));
}/*** Equivalent to FileObserver(paths, FileObserver.ALL_EVENTS).** @param files The files or directories to monitor*/
public FileObserver(@NonNull List<File> files) {this(files, ALL_EVENTS);
}

我们先看一下其中比较核心的构造方法，FileObserver能够监听某个路径下的文件、某个文件或者文件集合的变化，FileObserver是一个抽象类，那么我们可以实现它来监听anr目录文件的变化

        ACCESS,MODIFY,ATTRIB,CLOSE_WRITE,CLOSE_NOWRITE,OPEN,MOVED_FROM,MOVED_TO,CREATE,DELETE,DELETE_SELF,MOVE_SELF
})

具体的文件状态有以上这些，包括ACCESS（当前文件被访问了）、MODIFY（当前文件被修改了）、CREATE（当前文件被创建了）、DELETE（当前文件被删除了）等等

class ANRFileObserver(val anrPath: String
) : FileObserver(anrPath) {override fun onEvent(event: Int, path: String?) {when(event){ACCESS->{}MODIFY->{}DELETE->{}CREATE->{}}}
}

这里主要是检测这4种状态，当前文件夹下内容有修改时，就将全部的trace文件上传到服务端进行日志查看。

val observer = ANRFileObserver("/data/anr/")
observer.startWatching()

但是这里需要注意的就是，很多高版本的ROM已经不支持当前文件夹的查看，甚至需要Root，因此此策略暂时不能应用，那么除此之外，还可以通过WatchDog来监控线程状态，从而判断是否发生ANR。

2.2.3 WatchDog

从字面意思上看，就是看门狗，其实这个是Android系统中的一种监控机制，当SystemServer进程启动，调用start方法之后，WatchDog也就启动了run方法

从上面这张图可以理解WatchDog的原理：首先WatchDog是一个线程，每隔5s发送一个Message消息到主线程的MessageQueue中，主线程Looper从消息队列中取出Message，如果没有阻塞，那么在5s内会执行这个Message任务，就没有ANR；如果超过5s没有执行，那么就有可能出现ANR。

为了帮助到大家更好的全面清晰的掌握好性能优化，准备了相关的核心笔记（还该底层逻辑）：https://qr18.cn/FVlo89