【Android】【稳定性】【ANR】【原理】【输入事件】

整体架构

image.png

触摸屏幕的时候,Linux内核往设备节点写数据
EventHub会监听设备节点文件
InputReader无限循环,从EventHub中读取事件,加工后把事件放入InputDispatcher队列
InputDispatcher无限循环,从InputDispatcher中取出事件,找到合适的Window,把事件写入这个Window的InputChannel
随后串口端的Looper会被唤醒

派发架构

image.png

以下是3个队列的流转流程,简单记为A、B、C队列

image.png

原理

简而言之,并不是第一次发起点击事件就会报ANR的
发起一次后就不管了
只有当后面发起了,且检测到前一次超时了,这个时候才算ANR
这个时候可以再深思一下,什么时候,会超时
先明确一个概念,输入事件的处理,作为Handler中的一个msg
然后超时其实有2个因素:
1、输入事件msg前可能还有另外的msg没有处理完
2、输入事件msg自身执行的时间
所以得出公式:ANR = preMessageTime + inputMessageTime
侧面也反映一个道理,输入事件超时,不一定因为输入事件太耗时,可能是其他msg的影响,也可能是两者的共同作用
因此有时候看到ANR堆栈并不从onClick发起也不要太过惊奇

如何定位ANR?

发生ANR时,系统会输出2个比较重要的信息

  1. longMsg
  2. 堆栈
    堆栈是最友好的信息,但是它不一定准,很多时候你会看到不相关甚至是nativePollOnce这样的正常堆栈(不准的原因是无法精确确保AMS打印堆栈时机和ANR代码处时机一致,毕竟在2个进程,而且逻辑上还是通信上都有一些时差)
    所以longMsg就显得很重要
    Service、ContentProvider、Broadcast的原理是某个生命周期执行超时,longMsg会输出具体的堆栈和生命周期方法
    我们可以找到对应的生命周期方法,给其method做trace分析,即可定位得八九不离十
    而输入事件的longMsg则要复杂得多,所以下面展开对longMsg的分析

longMsg分析

1、Waiting because no window has focus but there is a focused application that may eventually add a window when it finishes starting up.
InputChannel在onResume后创建,所以很可能onCreate、onStart、onResume执行耗时逻辑,会引起这一点
2、Waiting because the [targetType] window is paused.
窗口暂停
3、Waiting because the [targetType] window’s input channel is not registered with the input dispatcher. The window may be in the process of being removed.
窗口为连接,窗口所在的进程可能正在被移除
4、Waiting because the [targetType] window’s input connection is [Connection.Status]. The window may be in the process of being removed.
窗口连接已死亡,窗口所在的进程可能正在被移除
5、Waiting because the [targetType] window’s input channel is full. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度].
窗口连接已满
6、Waiting to send key event because the [targetType] window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: [outboundQueue长度]. Wait queue length: [waitQueue长度].
点击事件超时
7、Waiting to send non-key event because the [targetType] window has not finished processing certain input events that were delivered to it over 500ms ago. Wait queue length: [waitQueue长度]. Wait queue head age: [等待时长].
触摸事件超时
其中2,3,4,5目前没发现触发条件,可能是比较极端的情况,很少见到
1,6,7是比较清楚的,但是6,7又得不到任何有用的结论
综上只有1的情况,可以得知,很可能是Activity生命周期超时引起的

后记

学习自
http://gityuan.com/2019/04/06/android-anr/
http://gityuan.com/2017/01/01/input-anr/

有什么写得错误、让人费解或遗漏的地方,希望可以不吝赐教,我会马上更改

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 220,458评论 6 513
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,030评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 166,879评论 0 358
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,278评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,296评论 6 397
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,019评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,633评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,541评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,068评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,181评论 3 340
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,318评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,991评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,670评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,183评论 0 23
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,302评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,655评论 3 375
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,327评论 2 358

推荐阅读更多精彩内容