Android ANR的产生与分析

ANR即Application Not Responding应用无响应,一般在ANR的时候会弹出一个应用无响应对话框。也许有些开发者在使用某些手机开发中不在弹出应用无响应弹出框,特别是国产手机Android4.0以上的系统中,即使在开发者选项中设置了“显示所有应用无响应-为后台应用显示无响应ANR对话框”,主要是因为在某些国产手机系统中就将该选项屏蔽了,应用超过了一定时间无响应也不会弹出ANR对话框了。

Android ANR的产生与分析_第1张图片

一般情况下应用无响应的时候回产生一个日志文件,位于/data/anr/文件夹下面,trace文件是Android Davik虚拟机在收到异常终止信号时产生的,最常见的一个触发条件就是Android应用中产生了FC(force close)。由于该文件的产生是在DVM中的,所以只有运行DVM实例的进程才能产生该文件,也就是说只有Java代码才能产生该文件,App应用的Native层(如Android Library、用c/c++编译的库)即使异常也不会产生ANR日志文件。我们可以通过ANR产生的traces日志文件分析应用在哪里产生了ANR,以此来有效解决应用中的ANR。

Android ANR的产生与分析_第2张图片

为什么会产生ANR

在Android里,应用程序的响应是由ActivityManager和WindowManager服务系统服务监视的,当检测到下面三种情况的任何一种时,Android就会针对特定的应用程序显示ANR对话框。

  • Activity的UI在5秒内没有响应输入事件(例如,按键按下,屏幕触摸)–主要类型
  • BroadcastReceiver在10秒内没有执行完毕
  • Service在特定时间内(20秒内)无法处理完成–小概率类型

造成ANR的原因有很多,无论是在Activity或者BroadcastReceiver还是在Service,我们看到都是在主线程中操作引起的ANR,因此我们应该避免在主线程做太多耗时的操作,网络请求不用说了,Android4.0以后就禁止在主线程成执行请求了,除此之外就是要注意如下几个方面:

  • 主线程频繁进行IO操作,比如读写文件或者数据库;
  • 硬件操作如进行调用照相机或者录音等操作;
  • 多线程操作的死锁,导致主线程等待超时;
  • 主线程操作调用join()方法、sleep()方法或者wait()方法;
  • system server中发生WatchDog ANR;
  • service binder的数量达到上限。

traces.txt文件分析

如果拉取traces.txt日志文件

当产生ANR的时候系统会生成一个日志文件,日志存放在/data/anr/文件夹下面,一般名称为traces.txt,但是也有例外的,如下:

Android ANR的产生与分析_第3张图片

如果手机已经是完全root的了,可以直接通过DDMS的File Explorer直接导出来,如果不是root的手机,可以通过如下adb命令查看ANR日志文件位于哪里。

adb shell ls /data/anr/

然后通过adb的pull将日志文件拉取到指定的路径。

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

但是如果手机没有进行root,执行adb pull命令就会出现如下提示:

remote object ‘/data/anr/traces.txt’ does not exist

这时候我们可以使用adb将文件copy一份到sdcard,然后再拉取出来。

adbshell
cat  /data/anr/traces.txt  >/mnt/sdcard/traces.txt  
exit

traces.txt日志文件分析

一般traces.txt日志输出格式如下,本实例是在主线程中强行Sleep导致的ANR日志:

DALVIKTHREADS :
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)  
"main" prio=5 tid=1 Sleeping
  | group="main" sCount=1 dsCount=0 obj=0x73f11000 self=0xf3c25800
  | sysTid=2957 nice=0 cgrp=default sched=0/0 handle=0xf7770ea0
  | state=S schedstat=( 107710942 40533261 131 ) utm=4 stm=6 core=2 HZ=100
  | stack=0xff49d000-0xff49f000 stackSize=8MB
  | heldmutexes=
  atjava.lang.Thread.sleep!(Native method)
  - sleepingon <0x31fd6f5d> (a java.lang.Object)
  atjava.lang.Thread.sleep(Thread.java:1031)
  - locked <0x31fd6f5d> (a java.lang.Object)
  atjava.lang.Thread.sleep(Thread.java:985)
  atcom.sunny.demo.MainActivity.startMethod(MainActivity.java:21)
  atjava.lang.reflect.Method.invoke!(Native method)
  atjava.lang.reflect.Method.invoke(Method.java:372)
  atandroid.view.View$1.onClick(View.java:4015)
  atandroid.view.View.performClick(View.java:4780)
  atandroid.view.View$PerformClick.run(View.java:19866)
  atandroid.os.Handler.handleCallback(Handler.java:739)
  atandroid.os.Handler.dispatchMessage(Handler.java:95)
  atandroid.os.Looper.loop(Looper.java:135)
  atandroid.app.ActivityThread.main(ActivityThread.java:5254)
  atjava.lang.reflect.Method.invoke!(Native method)
  atjava.lang.reflect.Method.invoke(Method.java:372)
  atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
  atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
  1. 第1行是固定头,指明下面都是当前运行的dvm thread:“DALVIK THREADS”;
  2. 第2行输出的是改进程中各线程互斥量的值,有些手机上面可能没有这一行日志信息;
  3. 第3行输出的是线程名字(“main”),线程优先级(“prio=5”),线程id(“tid=1”),线程状态(Sleeping),比较常见的状态还有Native、Waiting;
  4. 第4行分别是线程所处的线程组 (“main”),线程被正常挂起的次处(“sCount=1”),线程因调试而挂起次数(”dsCount=0“),当前线程所关联的java线程对象(”obj=0x73f11000“)以及该线程本身的地址(“0xf3c25800”);
  5. 第5行 显示线程调度信息,分别是该线程在linux系统下得本地线程id (“ sysTid=2957”),线程的调度有优先级(“nice=0”),调度策略(sched=0/0),优先组属(“cgrp=default”)以及 处理函数地址(“handle=0xf7770ea0”);
  6. 第6行 显示更多该线程当前上下文,分别是调度状态(从 /proc/[pid]/task/[tid]/schedstat读出)(“schedstat=( 107710942 40533261 131 )”),以及该线程运行信息 ,它们是线程用户态下使用的时间值(单位是jiffies)(“utm=4”), 内核态下得调度时间值(“stm=6”),以及最后运行改线程的cup标识(“core=2”);
  7. 第7行表示线程栈的地址(“stack=0xff49d000-0xff49f000”)以及栈大小(“stackSize=8MB”);
  8. 后面是线程的调用栈信息,也是分析ANR的核心所在。

通过traces.txt中 at com.sunny.demo.MainActivity.startMethod(MainActivity.java:21) 很容易就可以定位到我们的问题所在,MainActivity的第21行,然后我们可以看到代码:

try {
 Thread.sleep(10000);
} catch (InterruptedException e) {
 e.printStackTrace();
}

这就是由于主线程睡眠10s导致的无法响应。开发中定位ANR问题日志有个很简单的规律,就是 直接找到我们自己开发App所使用的包名(包括第三方Library库)信息开始定位找就可以了 。

再看另外一个实例,这是在开发中实际遇到的一个问题。

DALVIKTHREADS (23):
"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x73f11000 self=0xf3c25800
  | sysTid=2929 nice=0 cgrp=default sched=0/0 handle=0xf77bbea0
  | state=R schedstat=( 42455718229 4950682716 114556 ) utm=208 stm=4036 core=1 HZ=100
  | stack=0xff38d000-0xff38f000 stackSize=8MB
  | heldmutexes=
  atandroid.database.sqlite.SQLiteConnection.nativeExecute(Native method)
  atandroid.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:555)
  atandroid.database.sqlite.SQLiteSession.endTransactionUnchecked(SQLiteSession.java:437)
  atandroid.database.sqlite.SQLiteSession.endTransaction(SQLiteSession.java:401)
  atandroid.database.sqlite.SQLiteDatabase.endTransaction(SQLiteDatabase.java:522)
  atcom.xxx.xxxx.db.dao.DownloadItemDao$2.execute(DownloadItemDao.java:171)
  atcom.xxx.xxxx.db.DBManager.executeTask(DBManager.java:44)
  atcom.xxx.xxxx.db.dao.DownloadItemDao.updateDownload(DownloadItemDao.java:154)
  atcom.xxx.xxxx.download.DownloadManager$ManagerListener.onUIProgress(DownloadManager.java:222)
  atcom.sunny.net.listener.impl.UIProgressListener$UIHandler.progress(UIProgressListener.java:30)
  atcom.sunny.net.listener.handler.ProgressHandler.handleMessage(ProgressHandler.java:47)
  atandroid.os.Handler.dispatchMessage(Handler.java:102)
  atandroid.os.Looper.loop(Looper.java:135)
  atandroid.app.ActivityThread.main(ActivityThread.java:5254)
  atjava.lang.reflect.Method.invoke!(Native method)
  atjava.lang.reflect.Method.invoke(Method.java:372)
  atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
  atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)

先定位数据库操作处的问题,在DownloadItemDao的updateDownload()方法的154行,代码如下:

DBManager.getInstance().executeTask(new QueryExecutor() {
 @Override
 public void execute(SQLiteDatabasedatabase) {
 //...
 }
 });
}

然后接着定位executeTask方法,方法定义如下:

public void executeTask(QueryExecutorexecutor) {
 SQLiteDatabasedatabase = openDB();
 executor.execute(database);
 closeDB();
}

从这里可以看出来在下载过程中我们对数据库的操作都是在Main线程中进行的,所以我们可以再定义一个异步的方法,将DownloadItemDao的updateDownload()方法中调用改为DBManager.getInstance().executeAsyncTask()的方式,这样我们将对数据库这种比较耗时的操作子线程执行异步操作。

public void executeAsyncTask(final QueryExecutorexecutor) {
 new Thread(new Runnable() {
 public void run() {
 SQLiteDatabasedatabase = openDB();
 executor.execute(database);
 closeDB();
 }
 }).start();
}

接着看一下下载中的回调方式at com.sunny.net.listener.handler.ProgressHandler.handleMessage(ProgressHandler.java:47),在ProgressHandler类的47行,我们看到这里是将子线程异步下载的信息实时回调到主线程的地方:

if (!progressModel.isDone()) {
 progress(uiProgessListener, progressModel.getCurrentBytes(), progressModel.getContentLength(), progressModel.isDone());
}

这里的实现方式毫无疑问是实时回调进度,在UI展现层进度可以不必实时回调,可以减少对频繁UI更新操作,从分析可以知道频繁更新UI也是导致ANR的一个很重要的原因,因此可以适当的采用一定的延时再执行UI回调,更改后代码如下:

public static final int MIN_RATE=1000;
long currTime = SystemClock.uptimeMillis();
if (currTime - lastUpdateTime >= MIN_RATE&&!progressModel.isDone()) {
 lastUpdateTime = currTime;
 progress(uiProgessListener, progressModel.getCurrentBytes(), progressModel.getContentLength(), progressModel.isDone());
}

这样通过ANR日志文件可以非常方面快捷的定位到问题所在,并及时的给出解决方式提高日常开发中对问题的处理效率。

如何避免ANR

  • 避免在主线程进行复杂耗时的操作,特别是文件读取或者数据库操作;
  • 避免频繁实时更新UI;
  • BroadCastReceiver 要进行复杂操作的的时候,可以在onReceive()方法中启动一个Service来处理;
  • 避免在IntentReceiver里启动一个Activity,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广 播时需要向用户展示什么,你应该使用Notification Manager来实现。
  • 在设计及代码编写阶段避免出现出现同步/死锁或者错误处理不恰当等情况。

参考资料

android ANR发生的原因总结和解决办法

如何分析解决Android ANR

Android 信号处理面面观 之 trace 文件含义

Android ANR分析

android anr trace.txt文件 抓取

你可能感兴趣的:(Android)