亲宝软件园·资讯

展开

Android ANR

Ghelper 人气:0

前言

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。

加载全部内容

相关教程
猜你喜欢
用户评论