Android ANR的产生与分析

提兵百万西湖上,立马吴山第一峰!这篇文章主要讲述Android ANR的产生与分析相关的知识,希望能为你提供帮助。
    【Android ANR的产生与分析】ANR即Application Not Responding应用无响应,一般在ANR的时候会弹出一个应用无响应对话框。也许有些开发者在使用某些手机开发中不在弹出应用无响应弹出框,特别是国产手机android4.0以上的系统中,即使在开发者选项中设置了“显示所有应用无响应-为后台应用显示无响应ANR对话框”,主要是因为在某些国产手机系统中就将该选项屏蔽了,应用超过了一定时间无响应也不会弹出ANR对话框了。

Android ANR的产生与分析

文章图片

一般情况下应用无响应的时候回产生一个日志文件,位于/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的产生与分析

文章图片

为什么会产生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的产生与分析

文章图片

如果手机已经是完全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行,代码如下:
  1.   DBManager.getInstance().executeTask(new QueryExecutor() {
  2.   @Override
  3.   public void execute(SQLiteDatabasedatabase) {
  4.   //...
  5.   }
  6.   });
  7.   }
然后接着定位executeTask方法,方法定义如下:
  1.   public void executeTask(QueryExecutorexecutor) {
  2.   SQLiteDatabasedatabase = openDB();
  3.   executor.execute(database);
  4.   closeDB();
  5.   }
从这里可以看出来在下载过程中我们对数据库的操作都是在Main线程中进行的,所以我们可以再定义一个异步的方法,将DownloadItemDao的updateDownload()方法中调用改为DBManager.getInstance().executeAsyncTask()的方式,这样我们将对数据库这种比较耗时的操作子线程执行异步操作。
  1.   public void executeAsyncTask(final QueryExecutorexecutor) {
  2.   new Thread(new Runnable() {
  3.   public void run() {
  4.   SQLiteDatabasedatabase = openDB();
  5.   executor.execute(database);
  6.   closeDB();
  7.   }
  8.   }).start();
  9.   }
接着看一下下载中的回调方式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文件 抓取

    推荐阅读