Android性能优化之ANR问题定位分析

前言

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目录文件的变化

@IntDef(flag = true, value = {
        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。

到此这篇关于Android性能优化之ANR问题定位分析的文章就介绍到这了,更多相关Android ANR 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论