稳定性Log——ANR

ANR Broadcast TimeOut 超时判断

ANR service TimeOut 超时判断

ANR InputDispatching TimeOut超时判断

稳定性Log——ANR

在这里插入图片描述

ANR简介

  1. service TimeOut(20s)

前台进程中 service 生命周期不能超过20秒,后台进程中service生命周期不能超过200秒。
在启动service时,抛出定时消息SERVICE_TIMEOUT_MSG或SERVICE_BACKGOURND_TIMEOUT_MSG,如果定时消息响应了,则说明发生了ANR。

  1. Broadcast TimeOut(前台10s后台60s)

前台的“串行广播消息”必须在10秒内处理完毕,后台的“串行广播消息”必须在60秒内处理完毕,每派发串行广播消息到一个接收器,都抛出定时消息BROADCAST_TIMEOUT_MSG,如果定时消息响应了,则说明发生了ANR。

  1. InputDispatching TimeOut(5s)

输入事件如触摸、点击事件,必须在5秒内处理完毕。超时就会发生ANR。

appNotResponding

发生ANR最终调用 appNotResponding ,记录anr信息到event、system、trace,并发送未响应Dialog给系统显示
xref: /frameworks/base/services/core/java/com/android/server/am/AppErrors.java

885    final void appNotResponding(ProcessRecord app, ActivityRecord activity,
886            ActivityRecord parent, boolean aboveSystem, final String annotation) {
887        ArrayList<Integer> firstPids = new ArrayList<Integer>(5);
888        SparseArray<Boolean> lastPids = new SparseArray<Boolean>(20);
889
890        if (mService.mController != null) {
891            try {
892                // 0 == continue, -1 = kill process immediately
893                int res = mService.mController.appEarlyNotResponding(
894                        app.processName, app.pid, annotation);
895                if (res < 0 && app.pid != MY_PID) {
896                    app.kill("anr", true);
897                }
898            } catch (RemoteException e) {
899                mService.mController = null;
900                Watchdog.getInstance().setActivityController(null);
901            }
902        }
	      // ... ... ... ...
1099    }

ANR问题与解决方法

  1. 在event log中查找关键字am_anr,查询ANR相关信息
  2. 在android日志中查找关键字ANR in ,查看ANR发生时的CPU信息,以及ANR发生原因
  3. 在trace日志中,通过Cmd line关键字,查看对应进程的方法调用堆栈,分析ANR发生时的方法调用信息
  4. 整机卡顿导致系统响应缓慢:CPU使用率、IOwait、内存等,就是ANR in关键字信息
  5. 主线程block查看堆栈,需要结合发生anr前log和blockmonitor分析??

更多查看其它博客

简书:Android ANR:原理分析及解决办法
cnblogs博客园:Android ANR 详解


潜在的耗时操作

例如网络或数据库操作,或者高耗时的计算如改变位图尺寸,应该在子线程里 (或者以数据库操作为例,通过异步请求的方式)来完成。然而,不是说你的主线程阻塞在那里等待子线程的完成——也不是调用 Thread.wait()或是Thread.sleep()。替代的方法是,主线程应该为子线程提供一个Handler,以便完成时能够提交给主线程。 以这种方式设计你的应用程序,将能保证你的主线程保持对输入的响应性并能避免由于5秒输入事件的超时引发的ANR对话框。

如何避免ANR?

1、运行在主线程里的任何方法都尽可能少做事情。特别是,Activity应该在它的关键生命周期方 法(如onCreate()和onResume())里尽可能少的去做创建操作。(可以采用重新开启子线程的方式,然后使用 Handler+Message的方式做一些操作,比如更新主线程中的ui等)

2、应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务(因为 BroadcastReceiver的生命周期短),替代的是,如果响应Intent广播需要执行一个耗时的动作的话,应用程序应该启动一个 Service。(此处需要注意的是可以在广播接受者中启动Service,但是却不可以在Service中启动broadcasereciver,关于原因后续会有介绍,此处不是本文重点)

3、避免在Intent Receiver里启动一个Activity,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广 播时需要向用户展示什么,你应该使用Notification Manager来实现。

总结:ANR异常也是在程序中自己经常遇到的问题,主要的解决办法自己最常用的就是不要在主线程中做 耗时的操作,而应放在子线程中来实现,比如采用Handler+mesage的方式,或者是有时候需要做一些和网络相互交互的耗时操作就采用 asyntask异步任务的方式(它的底层其实Handler+mesage有所区别的是它是线程池)等,在主线程中更新UI。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

xhBruce

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值