标签:mode 直接 window 广播接收者 bcf adc http 通知 ice
极力推荐文章:欢迎收藏
Android 干货分享
ANR(Application Not Responding )
应用无响应的简称,是为了在 APP
卡死时,用户 可以强制退出APP
的选择,从而避免卡机无响应问题,这是Android
系统的一种自我保护机制。
通过本篇阅读,您将学习到以下内容
- 什么是ANR
- ANR的类型
- ANR 产生的原因
- 如何分析解决 ANR问题
- ANR 问题分析解决建议
- MTK 平台 ANR问题分析
在Android
中,应用程序响应由Activity Manager
和Window Manager
系统服务进行监视。ANR(Application Not Responding )
,则是Android
的一种自我保护措施,当主线程出现卡顿时候,Android
系统会给用户一个弹出提示,让用户手动选择继续等待还是强制关闭此APP
。
当Android检测到以下情况之一时,Android
将显示特定应用程序的ANR
对话框,比如以下三种情况下ANR
将经常发生:
UI Thread
超过 5 s
没有响应Broadcast
广播超过10 s
没响应Service
服务超过 20s
没响应ANR
发生,请不要在主线程中进行耗时操作,耗时操作请尽量在子线程中运行。ANR
截图 如下:ANR
在Android
手机中很常见,按其相应类型可以分为以下 常见 三种类型。
ANR类型:
- 按键响应分发超时(Key Dispatch Timeout)
默认5 s
,超过则会出现ANR。- 广播超时(Broadcast Timeout)
默认10 s
,超过则会出现ANR。- 服务超时(Service Timeout)
默认20 s
,超过则会出现ANR。
在Android
系统中,APP
通常运行在一个UI Thread
或者叫MainThread
里。并且Android
中只有一个MainThread
和Main Message Queue
。MainThread
主要用于UI
的绘制、事件响应,监听与接收事件处理等功能。Main Message Queue
主要存放用户要处理消息的队列,主线程MainThread
从消息队列Main Message Queue
中取消息Message
后,尽快分发下去,一旦某条消息分发超时,则ANR
可能发生。
因此,当ANR
发生时,我们要分析ANR
产生的原因,也就是查找消息处理不及时的原因。例如可以从以下几个疑问点进行分析:
APP
不能获取CPU
时间片?APP
是否是等待一些没能及时处理的事件完成?在分析ANR
时有一些常见的模式可供选择:
APP
正在主线程上进行缓慢的I/O
操作。APP
正在主线程中进行很复杂的计算操作Binder
程序调用,但另一个进程需要很长时间才能返回结果。Bind
调用还是主线程调用,都不能让主线程等待很久,更不能在主线程中进行复杂的计算。知道产生ANR的原因,那么如何避免ANR 问题呢?
使用StrictMode
可以帮助您在开发应用程序时在主线程上发现意外的I / O
操作。 您可以在application
或activity
使用StrictMode
。
查看方法ANR控制的方法:
设置---- 开发者选项---显示所有ANR
注意 :
如没有开发者选项,请进入设置---关于手机--- 多次连击 版本号 即可打开隐藏的开发者选项的item
Traceview获取正在运行的应用程序的跟踪信息,分析此traces.txt
文件 可以推测出主线程在忙于某些事情。
traces
文件通常保存在/data/anr/traces.txt
下,你可以直接用adb cat
查看,或者 adb pull
出来都可以。
个人不太建议
adb root
adb shell
cat /data/anr/traces.txt
建议使用此方法
adb root
adb remount
adb pull /data/anr/traces.txt C:\Users\Administrator\Desktop\新建文件夹
分析查看ANR
原因,接着解决ANR
问题。
耗时操作
请放在工作现场中进行,可以使用Handler、AsyncTask
等。
IO 操作
(比如:网络操作、存储操作等)也是引起ANR的常见因素。强烈建议在工作线程中进行。
程序锁竞争
某些情况,ANR
产生的原因不是直接因为在主线程中产生的。 比如: 工作线程对某个资源
等上锁,恰好此时,主线程需要此资源
,如等待超时,则此时ANR可能发生。
当主线程因为请求一个其他线程正在持有的资源而进入等待状态时,ANR
可能会发生。
应用程序可以通过广播接收器响应广播消息,例如启用或禁用飞行模式或更改连接状态。 当应用程序花费太长时间来处理广播消息时,理论上超过10s 未处理完成,ANR
可能会发生。
广播 ANR发生在下列情况下:
onReceive()
方法长时间未执行完毕。尽量避免在onReceive()
中进行耗时操作。
goAsync()
方法并且未能在PendingResult
对象上调用finish()
。如要处理的广播内容较多,请使用IntentService
进行处理。
比如下面例子:
IntentService
,避免ANR发生您的广播接收机可以使用goAsync()
来通知系统需要更多的时间来处理消息。 但是,您应该在PendingResult
对象上调用finish()
。 以下示例显示如何调用finish()以让系统回收广播接收器并避免ANR:
前提,抓取一份ANR
的MTK log
。
event_log
中 搜索关键字 am_anr
或者anr
,分析并查看ANR
原因main_log
中 搜索关键字Application Not Responding
或者anr
,分析并查看ANR
原因。常见ANR 举例分析如下:
至此,本篇已结束,如有不对的地方,欢迎您的建议与指正。同时期待您的关注,感谢您的阅读,谢谢!
标签:mode 直接 window 广播接收者 bcf adc http 通知 ice
原文地址:https://www.cnblogs.com/wangjie1990/p/11327055.html