Android ANR（应用无响应）

最新推荐文章于 2024-05-14 09:11:12 发布

mysimplelove

最新推荐文章于 2024-05-14 09:11:12 发布

阅读量1.7w

点赞数 9

分类专栏：学无止境文章标签： android安卓 anr 进程无响应主线程卡顿卡死

本文链接：https://blog.csdn.net/mysimplelove/article/details/93191748

版权

学无止境专栏收录该内容

50 篇文章 2 订阅

订阅专栏

前言：在Android上，如果你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框，这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。用户可以选择“等待”而让程序继续运行，也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr，而让用户每次都要处理这个对话框。因此，在程序里对响应性能的设计很重要，这样系统不会显示ANR给用户。

ANR简介

ANR全称：Application Not Responding，也就是应用程序无响应。

ANR原因

Android系统中，ActivityManagerService(简称AMS)和WindowManagerService(简称WMS)会检测App的响应时间，如果App在特定时间无法相应屏幕触摸或键盘输入时间，或者特定事件没有处理完毕，就会出现ANR。

首先，Android系统对于一些事件需要在一定的时间范围内完成，如果超过预定时间能未能得到有效响应或者响应时间过长，都会造成ANR。ANR由消息处理机制保证，Android在系统层实现了一套精密的机制来发现ANR，核心原理是消息调度和超时处理。

其次，ANR机制主体实现在系统层。所有与ANR相关的消息，都会经过系统进程(system_server)调度，然后派发到应用进程完成对消息的实际处理，同时，系统进程设计了不同的超时限制来跟踪消息的处理。一旦应用程序处理消息不当，超时限制就起作用了，它收集一些系统状态，譬如CPU/IO使用情况、进程函数调用栈，并且报告用户有进程无响应了(ANR对话框)。

然后，ANR问题本质是一个性能问题。ANR机制实际上对应用程序主线程的限制，要求主线程在限定的时间内处理完一些最常见的操作(启动服务、处理广播、处理输入)，如果处理超时，则认为主线程已经失去了响应其他操作的能力。主线程中的耗时操作，譬如密集CPU运算、大量IO、复杂界面布局等，都会降低应用程序的响应能力。

ANR出现场景

发生ANR时会调用AppNotRespondingDialog.show()方法弹出对话框提示用户，该对话框的依次调用关系如下图所示：

AppErrors.appNotResponding()，该方法是最终弹出ANR对话框的唯一入口，调用该方法的场景才会有ANR提示，也可以认为在主线程中执行无论再耗时的任务，只要最终不调用该方法，都不会有ANR提示，也不会有ANR相关日志及报告；通过调用关系可以看出哪些场景会导致ANR，有以下四种场景：

InputDispatching Timeout：5秒内无法响应屏幕触摸事件或键盘输入事件。
BroadcastQueue Timeout ：在执行前台广播（BroadcastReceiver）的onReceive()函数时10秒没有处理完成，后台为60秒。
Service Timeout ：前台服务20秒内，后台服务在200秒内没有执行完毕。
ContentProvider Timeout ：ContentProvider的publish在10s内没进行完。

ANR原因

主线程慢代码
主线程IO
锁竞争
死锁

如何避免ANR

1.UI线程尽量只做跟UI相关的工作;
2.耗时的工作（比如数据库操作，I/O，连接网络或者别的有可能阻碍UI线程的操作）把它放入单独的线程处理;
3.尽量用Handler来处理UI thread和别的thread之间的交互;
4.实在绕不开主线程，可以尝试通过Handler延迟加载;
5.广播中如果有耗时操作，建议放在IntentService中去执行，或者通过goAsync() + HandlerThread分发执行。

分析ANR的重点

1.cpu占用率方面：
可以通过分析各进程的CPU时间占用率，来判断是否为某些进程长期占用CPU导致该进程无法获取到足够的CPU处理时间，而导致ANR重点关注下CPU的负载，各个进程总的CPU时间占用率，用户CPU时间占用率，核心态CPU时间占用率，以及iowait CPU时间占用率。
2.内存方面
主要看当前应用native和dalvik层内存使用情况，结合系统给每个应用分配的最大内存来分析。

ANR日志分析

当app出现ANR时会在data/anr/目录下生成traces.txt日志文件。每次发生ANR时都会删除旧的traces文件，重新创建新文件。也就是说Android只保留最后一次发生ANR时的信息。

首先，我们可以使用adb命令导出traces文件：

adb pull /data/anr/traces.txt d:\

友情提示：traces.txt默认会被导出到Android SDK的\platform-tools目录。

开发中最方便的是在log里面就可以看到ANR的相关信息，以下面的日志为例，我们可以从Android studio logcat很明显的看出ANR发生的原因，用户的输入超时了，问题线程的PID:879。

同时我们还可以通俗易懂的看出来 CPU平均负载，CPU的使用情况：

4.67 ,3.32 ,1.49 分别表示发生`ANR` 前一分钟，五分钟，十五分钟 `CPU`的平均负载 Load: 4.67 / 3.32 / 1.49 CPU usage from 6021ms to 79ms ago。

anr

接下来还是回到进一步分析traces.txt文件上来，看文件里面的内容：


----- pid 879 at 2019-01-02 08:05:04 -----
Cmd line: com.sandiyu.lcd

JNI: CheckJNI is off; workarounds are off; pins=2; globals=273

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)

"main" prio=5 tid=1 WAIT
  | group="main" sCount=1 dsCount=0 obj=0x4159cd68 self=0x414d6510
  | sysTid=879 nice=0 sched=0/0 cgrp=apps handle=1074020692
  | state=S schedstat=( 0 0 0 ) utm=602 stm=168 core=1
  at java.lang.Object.wait(Native Method)
  - waiting on <0x4159ce38> (a java.lang.VMThread) held by tid=1 (main)
  at java.lang.Thread.parkFor(Thread.java:1205)
  at sun.misc.Unsafe.park(Unsafe.java:325)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2017)
  at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:318)
  at com.sandiyu.lcd.utils.DeviceCommandSender$CommandSendThread.send(DeviceCommandSender.java:156)
  at com.sandiyu.lcd.utils.DeviceCommandSender.displayNull(DeviceCommandSender.java:81)
  at com.sandiyu.lcd.DlpPrintActivity$PrintRunnable.clearImage(DlpPrintActivity.java:884)
  at com.sandiyu.lcd.DlpPrintActivity$PrintRunnable.access$1900(DlpPrintActivity.java:253)
  at com.sandiyu.lcd.DlpPrintActivity.onBackPressed(DlpPrintActivity.java:954)
  at android.app.Activity.onKeyUp(Activity.java:2193)
  
  ...

一般trace文件顶部的线程即为ANR的元凶，找到了犯罪线程我们就可以查看、分析一下犯罪现场。

line 1,2

----- pid 879 at 2019-01-02 08:05:04 -----
Cmd line: com.sandiyu.lcd

可以看到ANR 发生的进程id，时间，名称。

line 3,4,5

JNI: CheckJNI is off; workarounds are off; pins=2; globals=273

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)

可以看到线程的基本信息（tll：thread list lock，tsl：thread suspend lock，tscl：thread suspend count lock，ghl：gc heap lock）。

line "main"

"main" prio=5 tid=1 WAIT

这一行说明了线程名称，优先级，线程锁id和线程状态。可以看到本次ANR 线程为WAIT状态。

额外补充一下线程状态有如下几种：

java thread 状态	cpp thread状态	说明
TERMINATED	ZOMBIE	线程死亡，终止运行
RUNNABLE	RUNNING/RUNNABLE	线程可运行或正在运行
TIMED_WAITING	TIMED_WAIT	执行了带有超时参数的wait、sleep或join函数
BLOCKED	MONITOR	线程阻塞，等待获取对象锁
WAITING	WAIT	执行了无超时参数的wait函数
NEW	INITIALIZING	新建，正在初始化，为其分配资源
NEW	STARTING	新建，正在启动
RUNNABLE	NATIVE	正在执行JNI本地函数
WAITING	VMWAIT	正在等待VM资源
RUNNABLE	SUSPENDED	线程暂停，通常是由于GC或debug被暂停
	UNKNOWN	未知状态

接着往下面的信息看

at com.sandiyu.lcd.utils.DeviceCommandSender$CommandSendThread.send(DeviceCommandSender.java:156)
  at com.sandiyu.lcd.utils.DeviceCommandSender.displayNull(DeviceCommandSender.java:81)
  at com.sandiyu.lcd.DlpPrintActivity$PrintRunnable.clearImage(DlpPrintActivity.java:884)
  at com.sandiyu.lcd.DlpPrintActivity$PrintRunnable.access$1900(DlpPrintActivity.java:253)
  at com.sandiyu.lcd.DlpPrintActivity.onBackPressed(DlpPrintActivity.java:954)

在这里我们就找到了原因，CommandSendThread.send需要等待网络资源来更新UI，连接中断了，这时候点击onBackPressed长时间得不到相应，它就报了ANR了。

该篇文章只是介绍了通过traces来分析ANR的方式，也有其他方式就不一一介绍了。

see you

mysimplelove

关注

9
点赞
踩
45

收藏

觉得还不错? 一键收藏
0
评论
Android ANR（应用无响应）

前言：在Android上，如果你的应用程序有一段时间响应不够灵敏，系统会向用户显示一个对话框，这个对话框称作应用程序无响应（ANR：Application Not Responding）对话框。用户可以选择“等待”而让程序继续运行，也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr，而让用户每次都要处理这个对话框。因此，在程序里对响应性能的设计很重要，这样系统不会显示ANR给用户...
复制链接

扫一扫