都知道避免ANR,但该如何分析,定位,解决?

2020-12-16 15:53:37 浏览数 (1)

作者:石器时代小古董

链接:https://www.jianshu.com/p/cfa9ed42e379

一、什么是Anr:

application not responding 程序无响应。程序在规定的时间内没有响应。

超时时间的计数一般是从按键分发给app开始。超时的原因一般有两种:

1.当前的事件没有机会得到处理(即UI线程正在处理前一个事件,没有及时的完成或者looper被某种原因阻塞住了);

2.当前的事件正在处理,但没有及时完成。

二、Anr的主要原因

ANR一般有三种类型:

1:KeyDispatchTimeout(5 seconds) --主要类型

按键或触摸事件在特定时间内无法得到响应

2:BroadcastTimeout(10 seconds)

BroadcastReceiver在的onRecieve运行在主线程中,短时间内无法处理完成导致

3:ServiceTimeout(20 seconds) --小概率类型

Service的各个声明周期在特定时间内无法处理完成

Anr场景分析

1.使用命令导出anr日志

代码语言:javascript复制
adb pull /data/anr/traces.txt  ~/Desktop/

2.分析关键信息

以每行的重点内容没准,每行自带时间戳

代码语言:javascript复制
Process:anr发生的时间和进程,和生成traces文件的时间
CPUusage ... ago :cpu在anr发生前的使用情况
CPUusage ...later: cpu在anr后的使用情况
ABI:         手机的cpu架构
HEAP:     堆的内存信息
ANR in:包名,和类名
Reason:原因
TOTAL:总的CPU使用率
prio:线程的优先级
tid:线程锁id  主线程的id为1  主要看这个线程的
Sleeping:线程的状态
sCount:线程被挂起的次数
dsCount:线程是否被调试
代码语言:javascript复制
04-01 13:12:11.572** I/InputDispatcher( 220): Application is not responding**:Window{2b263310com.[Android](http://lib.csdn.net/base/android).email/com.android.email.activity.SplitScreenActivitypaused=false}.  5009.8ms since event, 5009.5ms since waitstarted
04-0113:12:11.572 I/WindowManager( 220): Input event dispatching timedout sending tocom.android.email/com.android.email.activity.SplitScreenActivity
04-01 **13:12:14.123 I/Process(  220): Sending signal. PID: 21404 SIG: 3---****发生**ANR**的时间和生成**trace.txt**的时间**
04-01 13:12:14.123 I/dalvikvm(21404):threadid=4: reacting to signal 3 
……

04-0113:12:15.872 E/ActivityManager(  220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
04-0113:12:15.872 E/ActivityManager(  220): Reason:keyDispatchingTimedOut
04-0113:12:15.872 E/ActivityManager(  220): Load: 8.68 / 8.37 / 8.53
04-0113:12:15.872 E/ActivityManager(  220): **CPUusage from 4361ms to 699ms ago** ----CPU在ANR发生前的使用情况

04-0113:12:15.872 E/ActivityManager(  220):   5.5!404/com.android.email: 1.3% user   4.1% kernel / faults: 10 minor
04-0113:12:15.872 E/ActivityManager(  220):   4.3"0/system_server: 2.7% user   1.5% kernel / faults: 11 minor 2 major
04-0113:12:15.872 E/ActivityManager(  220):   0.9R/spi_qsd.0: 0% user   0.9% kernel
04-0113:12:15.872 E/ActivityManager(  220):   0.5e/irq/170-cyttsp-: 0% user   0.5% kernel
04-0113:12:15.872 E/ActivityManager(  220):   0.5)6/com.android.systemui: 0.5% user   0% kernel
04-0113:12:15.872 E/ActivityManager(  220): **100%TOTAL: 4.8% user   7.6% kernel   87% iowait**
04-0113:12:15.872 E/ActivityManager(  220): **CPUusage from 3697ms to 4223ms later**:-- ANR后CPU的使用量
04-0113:12:15.872 E/ActivityManager(  220):   25!404/com.android.email: 25% user   0% kernel / faults: 191 minor
04-0113:12:15.872 E/ActivityManager(  220):    16% 21603/__eas(par.hakan: 16% user   0% kernel
04-0113:12:15.872 E/ActivityManager(  220):    7.2% 21406/GC: 7.2% user   0% kernel
04-0113:12:15.872 E/ActivityManager(  220):    1.8% 21409/Compiler: 1.8% user   0% kernel
04-0113:12:15.872 E/ActivityManager(  220):   5.5"0/system_server: 0% user   5.5% kernel / faults: 1 minor
04-0113:12:15.872 E/ActivityManager(  220):    5.5% 263/InputDispatcher: 0% user   5.5% kernel
04-0113:12:15.872 E/ActivityManager(  220): **32%TOTAL: 28% user   3.7% kernel**

典型的分析情况

1.如果TOTAL的和接近100,有可能是因为当前使用的app占用的cpu太高,导致系统将你的杀死。

2.如果TOTAL很小,则说明线程被阻塞了,主线程在等待下条消息的进入,任务在等待时anr。

3.如果ioWait很高,则说明是io操作导致的

分析

因为主线程被阻塞导致的关键信息。

at android.os.MessageQueue.nativePollOnce(Native Method) at android.os.MessageQueue.next(MessageQueue.java:119) at android.os.Looper.loop(Looper.java:110)

代码语言:javascript复制
DALVIK THREADS:(mutexes: tll=0tsl=0 tscl=0 ghl=0 hwl=0 
hwll=0)"main" prio=5 tid=1NATIVE  | group="main" sCount=1 
dsCount=0obj=0x2aad2248 self=0xcf70  | sysTid=21404 nice=0 
sched=0/0cgrp=[fopen-error:2] 
handle=1876218976  

at android.os.MessageQueue.nativePollOnce(Native Method)  
at android.os.MessageQueue.next(MessageQueue.java:119)  
at android.os.Looper.loop(Looper.java:110**) 
at android.app.ActivityThread.main(ActivityThread.java:3688)
 at java.lang.reflect.Method.invokeNative(Native Method)  
at java.lang.reflect.Method.invoke(Method.java:507)  
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:866) 
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:624) 
at dalvik.system.NativeStart.main(Native Method)

io读写导致的anr

关键点:ioWait很高,ContentResolver in AsyncTask onPostExecute

1.首先看到total中ioWait很高,说明是io操作导致的。

2.具体原因

可以看到关键词sqlite,ContentResolver

在主线程进行了网络访问

关键词OSNetworkSystem.receiveStream,net

内存不足导致

可以看到TOTAL的使用率有98,所以内存不足。

关键词:VMWAITVMRuntime.trackExternalAllocation

广播阻塞导致anr

android.intent.action.SCREEN_OFF广播为order,即如果其中注册了此广播的任何应用在处理此广播时未返回,则会导致后续broadcast的失败,出现ANR,导致系统无法唤醒。而导致广播未被及时处理的原因,除了可能是由于对应的Receiver处理函数中一些操作长时间未完成外,也可能是由于整个应用进程被block了,从而没有机会去调用Receiver函数。

1.针对onRecieve中的耗时操作,可以将业务单独加入到一个线程中执行:

快速定位anr

1.如果是ANR问题 , 则搜索“ANR”关键词 。快速定位到关键事件信息 。

2.如果是ForceClosed(程序强制关闭) 和其它异常退出信息,则搜索"Fatal" 关键词, 快速定位到关键事件信息 。

ANR的避免和检测

使用StrictModel

它是android sdk提供的一个用来检测代码中是否存在违规操作的工具类

1.线程检测策略

ThreadPolicy

1.detectCustomSlowCalls:检测耗时操作

2.detectDiskWrites:检测磁盘写入

3.detectDiskRead:检测磁盘读取

4.detectNetWork:检测网络

5.detectAll:启用所有策略

VmPolicy

虚拟机检测策略

1.detectActivityLeaks:是否存在activity泄露

2.detectLeakedClosableObjects:是否存在没有关闭的closable对象

3.detectLeakedSqlLiteObjects:是否存在sqlite对象泄露

4.detectClassInstanceLimit:是否存在实力个数超限制

5.detectALL:启用所有策略

使用方式

代码语言:javascript复制
在application的oncreate方法前
StrictMode.setThreadPolicy(new StrictModel.ThreadPolicy.Builder().detectAll().penaltyLog().build());
//penlatyLog表示是否打印日志。

0 人点赞