admin管理员组文章数量:1534214
Android ANR日志分析指南_connectivitythread" in group "main",是否意味着在主线程-CSDN博客
Android ANR日志分析总结_timeout of broadcast broadcastrecord-CSDN博客
https://blog.csdn/weixin_34274029/article/details/91362537?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EsearchFromBaidu%7Edefault-1.pc_relevant_baidujshouduan&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EsearchFromBaidu%7Edefault-1.pc_relevant_baidujshouduan
关键字:am_anr|anr in| oom| crash| fatal| low_memory|slow operation|BlockMonitor:| Zygote |
am_crash|broadcast |Choreographer:|commands.monkey:commands.monkey|crash:|dvm_lock_sample|System.err:|
LowMem |onTrimMemory|onAttach|onTrimMemory|onAttach|onDetach|start u0|E Hievent :|
Changing focus from Window
应用启动查杀 关键字“trigger app emergency” 内存关键字awareMem
例1:Reason: Input dispatching timed out does not have a focused windows
inputdispatcher: still no focused windows.will drop the event
这种问题主要是发生在两个应用页面之间切换的时候,这个临界点的时候,一个页面正在起来,另外一个页面已经"压栈",即失去焦点,并且在这个页面切换的时候快速点击返回back键,按照目前android系统的约定是先判断是否有window获得focus,发送按键message必须要有有效的focus窗口来接收,否则input event消息将会在系统里面Block,一当Block,系统就开始计时(即timeout),时间一到即调用notifyANR开始处理timeout事件,表面现象APP无响应,然后崩溃掉.
谷歌develop官网上对ANR触发机制是这样描述的:
此处从源码角度分析下AMS和WMS是如何monitor ANR的。
Android版本:Android 5.0
分析对象:keyDispatchingTimedOut的monitor机制
1. keyDispatchingTimedOut(此处‘key‘不准确,其实是InputEvent(包含KeyEvent和TouchEvent)派发超时,当前触屏手机上,以TouchEvent/MotionEvent为主),先看下这块的类图:
可以看到真正干活的是在Native侧,由native侧monitor事件是否超时,并触发调用Java侧notifyANR逻辑。
anr monitor的大概时序如下:
ANR monitor核心工作由InputDispatcher.cpp完成,在每次派发事件时,需要进行如下判断:
1. 判断是否有focused组件及focusedApplication
2. 判断前面的事件是否及时完成
对于1,一般是在启动时可能触发,比如启动时间过长,在这过程中触发keyevent或trackball motionevent, 则进行如下逻辑判断:
这种情况下,对应的ANR log如下:
Reason: Input dispatching timed out (Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.)
对于2,KeyEvent和MotionEvent对“及时性”的策略不同,KeyEvent需要判断上一个事件是否做完(由于涉及focus的问题,KeyEvent必须等wms处理前一个事件,才把新的事件派发过去):
checkWindowReadyForMoreInputLocked
而touchevent(touch screen,e.g.),则需判断事件等待队列里的head的事件时间是否已经过去0.5秒了,相对来说,touchevent的要求更
低些,允许的执行时延更大,此时,说明UI线程卡住了,一堆touch event在等待执行,需要停止event delivery,
因此无论是keyevent(实体键输入)还是touchevent(点击view)都是因为UI线程没及时处理完前面的事件导致.
设置anr的start和timeout值,在timeout时刻唤醒事件,再依据上述条件判断是否可以event delivery,
若满足事件派发条件, 则可以走正常派发流程,否则(如UI线程卡住、UI线程抢不到CPU等), 则触发onANRLocked,后续流程如时序图所示。
版权声明:本文标题:Android--ANR日志分析 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/xitong/1726874948a1088239.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论