Android ANR日志粗略分析

平台：Android4.4.2

 

虽然ANR的缩写是application not responding，但是并不是所有的ANR问题都是应用程序的问题。比如说CPU占用率太高、API调用卡死都有可能导致ANR，这些问题都是系统性问题。

 

1. 什么是ANR？

Android应用程序和Windows应用程序一样，采用的也是消息循环模型。就是说应用程序启动后在没有主动创建线程的情况下就只有一个主线程不断的从消息队列取出消息然后处理消息。

目前Android共定义了三种ANR，第一种比较容易理解，就是用户按键或滑动触屏后，应用程序在规定时间内不响应（当前默认值是5秒），从用户的角度看，这个问题是非常严重的，不要说5秒，只要超过1秒不响应其实都是不可接受的。识别这种ANR的原理是通过运行在system_server进程中的InputDispatcher不断检测应用程序是否处理完这个输入事件，一旦超时就打小报告，如弹出应用程序无响应的对话框，产生ANR日志。

另外两种ANR带有预防性质，因为主线程既要响应用户输入又要干其他事情，如果其他事情干的太慢那么就有可能影响对用户的响应。如果这个时候用户没有输入，那么也就算了，如果用户一旦有输入，那么必然产生前一种ANR。针对这种ANR只是产生ANR日志，但不弹框。现在说这两种ANR是什么，一种是主线程在处理通知的onReceive函数中执行超过10秒没有返回，另外一种是主线程在执行后台操作即执行Service的各个生命周期函数超过20秒。

 

如果主线程仅处理用户响应，其他的事情都通过另外一个线程处理那么是不是就没有ANR了呢？我想这样会好一些，因为有些程序员不太清楚哪些事情在主线程干的，比如我开始就不知道service的处理是在主线程中，因为这个名字起的有点坑爹，如果采用了双线程策略，就会防止这种错误。当然了解机制也是程序员的责任，即使平台默认不提供双线程，程序员也可以自己创建线程处理耗时的工作。第二个问题是后两种ANR我们要不要关注，从用户的角度看只要没产生第一种ANR，这两种ANR是没问题的，那么问题就变成这两种ANR有没有可能导致第一种ANR。因为用户随时可能输入，所以我们需要关注的是当前应用的activity组件处于活动状态时，也就是可接受用户输入的状态时，后两种ANR是否有可能发生。第三个问题，为什么后两种ANR的超时不是5秒？我推测原因同问题2，因为目前还没有机制判断后两种ANR是否会导致第一种ANR，如果有的话，那么超时完全可以设置成5秒。这个是我的臆测，如果哪位朋友更清楚这块的原因，那么非常欢迎指点一二。

 

2. ANR日志说明

ANR日志大致可以分成3个部分：基本信息，CPU占用率，线程调用栈。

2.1   基本信息

Process: system

Flags: 0xc8be09

Package: android v17 (4.2.2-eng.jslave.20131102.115504)

Package: com.android.providers.settings v17 (4.2.2-eng.jslave.20131102.115504)

Subject: keyDispatchingTimedOut

Build: xxxxx/xxxx/release-keys

 

Process就是发生ANR的进程名字，如system，android.process.media，com.android.systemui，com.tencent.mm等。

 

Flags是用来记录应用程序标志的。如：Bit0为1代表是安装在system分区的系统程序如system，bit0为0代表不是系统程序，如com.tencent.mm进程的flags为0xb0be44。Bit1为1代表该应用程序允许调试，在发货的版本中该位应该都是0。Bit2从网上资料看为1表示应用程序拥有代码？难道还有没代码的？还真有，例子中就是一个，这个没有搞清楚，欢迎高人指点。        Bit3为1表示该应用程序不能退出，一般的应用程序都设置为0，只有system server或systemUI这样的程序才会设置为1。关于其他标志位的意义可以参考frameworks/base/core/java/android/content/pm/ApplicationInfo.java中的注释也可以去开发者网站http://developer.android.com/reference/android/R.styleable.html#AndroidManifestApplication_pers