作者：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: 31848
Reason: 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。
