考虑到国内厂商对 Rom 定制化的习惯，为了确认上面监控的 Cpu 耗时是否是厂商在底层定制产生的耗时，我们在 Native 层通过 Hook 代理对 nativePollOnce 接口进行了监测。
在线上小范围验证和复现，通过观察这类 ANR 问题时的线程调度时序图，最终找到一个 NativePollOnce 停留时长高达 100S 的案例，如下图：
通过上图(TYPE=5)可以发现，ANR 发生前，主线程在消息调度结束与下次消息调度开始前，发生多次长时间停留的现象，而且期间都存在一定的 Cpu 耗时，但是远小于 Wall duration。与此同时查看本次进行 epoll_wait 期间，NativePollOnce 是否是一直没有返回，通过监控输出的日志，发现如下现象：
在对齐监控时序图与上图日志时间戳之后，看到 Java 层调用 looper.next()获取下一个消息过程中，Native 层 NativePollOnce 接口调用了多次，而且每次进入 epollwait 时传入的参数 timeout 为-1。分析到这里有些疑惑了，这并不是我们预期的一直 wait 场景啊，参数-1 代表什么意思呢？继续向下看。
MessageQueue 代码分析：
既然 ANR 这段时间，执行多次 NativePollOnce，就说明其它线程已经多次将主线程多次从 epoll wait 状态唤醒，但是消息队列已经有大量待调度的消息，为何主线程还依然停留在 looper.next()内部呢？分析到这里只好再次回到上层代码继续分析，这个参数-1 是哪里设置的。
从上图可以看到，每当消息执行结束后，获取下个消息之前会先主动调用一次 NativePollOnce，但是 nextPollTimeoutMillis 默认为 0，并不是底层接口代理时看到的-1，那么这个-1 是哪里传入的呢？继续向下看。
通过上图可以看到，只有一个地点将 nextPollTimeoutMillis 设置为-1，但是通过注释可以清晰的看到提示"msg=mMessage"，没有消息？这与现实严重不符啊，ANR 发生时，消息队列明显有很多消息待执行，这里却提示"msg=mMessage"。
通过进一步观察上述逻辑发现，该提示发生在 else 分支，如果进入到该分支，那么则说明 msg 对象获取为空，但是在上面明明看到赋值过程"msg=mMessage"，而且当前这种场景 mMessage 肯定不为 null，毕竟在 ANR 时获取的待调度消息也是通过 mMessage 遍历得到的。
既然 mMessage 不是 null，那么就说明"msg=mMessage"肯定不是 null，但是到了下面却为 null，说明在此过程肯定被某个逻辑给重新赋值了，继续分析。
通过上图可以看到只有这个场景可能将 msg 重新赋值，那么这部分逻辑是做什么的呢？
Barrier 机制介绍：
看到上面的注释瞬间明白了，原来是 Barrier 机制，是 Android 系统用来保障部分系统消息高优调度的一种机制，实现原理很简单：会在每次消息返回前，检测该消息是否是 barrier 消息，barrier 消息的典型特征就是 msg.target 对象为 null，如下图：
如果是 Barrier 消息，那么将对消息队列中的消息进行遍历，找到第一个异步消息，然后将其赋值给 msg。但是如果遍历了所有的消息都没有找到异步消息，那么最后一个消息 msg.next 肯定为 null，此时 msg 会被置为 null，并退出循环。
上图为异步消息的设置和判断是否是异步消息的接口实现，我们日常创建的 Message 是不会设置该属性的。只有系统在某些特殊场景，如 UI 刷新，为了保障交互体验，会在请求 vsync 信号前，先发送一个 barrier 消息，然后等到 barrier 消息执行时，遍历 vsync 消息并将其强制调整到头部，以保证该类消息的响应能力：barrier 消息设置和移除，实现逻辑如下：
通过上面实现可以看到，barrier 消息是不会主动移除的，需要设置 barrier 消息的业务消息得到响应后主动移除该消息，否则 barrier 消息会一直存在！
分析到这里就可以很好的解释为何在 MessageQueue.next()接口内部多次调用 NativePollOnce 了，一定是当前的 mMessage 是个 barrier 消息，但是与其关联的业务消息一直没有出现，或者执行之后没有同步移除该消息，导致该 barrier 消息一直处于消息队列头部，每次获取下一个消息时，都被 barrier 拦截和并遍历异步消息，如果有异步消息则响应，没有异步消息则通过 nativePollOnce 进行等待，从而阻塞了正常消息的调度和响应！
进一步梳理 MessageQueue.next 接口执行逻辑，通过下图就可以清晰的看到我们在 Native 层 Hook 时看到 nextPollTimeMills 传参-1 的场景是怎么设置的。
那么结合本类 ANR 问题，消息队列第一个待调度的消息是不是 barrier 消息呢？我们再次找到上面分析的案例，通过监控时序图观察第一个被 block 的消息。
通过上图可以清晰的看到，当前消息 target 对象为 null，正是 barrier 消息！破案了！
连锁反应：
按照上面的分析，如果 barrier 消息没有及时移除，那么每次通过 MessageQueue.next()查询时，只能过滤并返回带有异步属性的消息，如用户点击消息 input，vsync 消息等等。 即使用户交互和 UI 刷新消息可以正常执行，但是大量业务消息无法执行，这就导致了 UI 展示可能存在异常或功能异常，并且应用 service，receiver 等消息并没有异步属性，因此也会被 block，最终造成响应超时发生 ANR！
结合当前问题，我们发现该用户在第一次 ANR 不久之后再次发生 ANR，主线程 Trace：
第二次 ANR 时，对应的调度时序图如下：
通过当前用户连续 2 次 ANR 的消息调度监控时序图可以看到，本次 ANR 时，之前的历史消息记录没有发生任何变化，也就是说第一个 ANR 发生后确实没有再调度其他消息，但 2 次 ANR 的 WallTime 间隔超过 40S，也就是说这 40S 时间里，主线程确实一直 Block 在当前场景！
在消息调度时序图上进一步对比分析，发现两次 ANRCase，主线程当前正在执行消息的 Cpu Time 时长却发生了变化，即从 100ms 增加 450ms。那么这个数据是否置信吗？
结合这两次 ANR，分别分析一下 ANR Trace 主线程 utm+stm 的耗时(见上图 2 次 Trace 堆栈)：
发生第一次 ANR 时线程状态及 utm,stm 耗时：
state=S schedstat=( 2442286229 338070603 5221 ) utm=187 stm=57 core=5 HZ=100
发生第二次 ANR 时线程状态及 utm,stm 耗时：
| state=S schedstat=( 2796231342 442294098 6270 ) utm=202 stm=77 core=5 HZ=100
用第二次发生 ANR 时的 utm+stm 减去第一次 ANR 时的 utm+stm，即 202+77-(187+57)=35ms。这个值对应的是 cpu 时间片，utm,stm 单位换算成时间单位为 1 比 10ms，即 35*10=350ms。这个值恰好等于 Raset 监控工具统计到的两次 Cputime 差值：450ms-100ms=350ms。
说明在此期间消息队列增加了多个消息，因为每次增加一个消息，主线程都会从 epollwait 场景唤醒，然后回到 java 环境对消息队列进行遍历，判断是否有异步消息，如果没有找到，则再次进入 epollwait 状态，如此反复，从而导致了上述现象！
问题初定位：
通过上面的层层分析，我们知道了是 barrier 同步机制出现了问题，导致消息调度发生异常，即：在 barrier 消息没有被移除之前，主线程只能处理 asyncronous 属性的消息，这类消息通常是用来刷新的 vsync 消息，以及响应用户交互的 input 消息，但是正常的业务消息及其他系统消息则无法正常调度，如 Serivce，Receiver 具体超时行为的消息，因此导致了 ANR。
定位及修复：
在定位到原因之后，接下来就是找到问题并解决问题，具体什么样的改动会引起这里问题了，通过分析我们知道既然是 Barrier 消息同步的问题，那么我们可以在设置 barrier 和移除 barrier 的过程加入监控，判断哪里设置了 barrier 消息，但是没有同步移除。通过 Java hook 代理了 MessageQueue 的 postSyncBarrier 和 removeSyncBarrier 接口，进行 Barrier 消息同步监测，遗憾的是线下并没有复现。
因此只能再次回到代码层面，对相关改动进行分析，最终在一笔需求提交中发现了线索。
逻辑调整前： 先移除将要强制调度的并设置了异步属性的消息，再强制调度该消息，以保证该消息不受 barrier 消息之前的消息 block，进而提高响应能力。
if (hasMsg) {
…
handler.removeCallbacks(message.getCallback()); //先移除
handler.dispatchMessage(cloneMsg); //再强制调度该消息
…
}
逻辑调整后： 先强制调度该消息，然后再将该消息从队列中移除。
…
handler.dispatchMessage(newMessage); //先强制调度
handler.removeCallbacks(message.getCallback()); //从队列中移除消息
…
}
但是时序调整后存在一定隐患，即在强制调用 DoFrame 消息期间，业务可能会再次触发 UI 刷新逻辑，产生 barrier 消息并发出 vsync 请求，如果系统及时响应 vsync，并产生 DoFrame 消息，那么调用 removeCallbacks 接口会一次性清除消息队列中所有的 DoFrame 消息，即：移除了消息队列之前的 DoFrame 消息和下次待调度的 DoFrame 消息，但是与下次 DoFrame 消息同步的 barrier 消息并没有被移除。
那么为什么会移除多个消息呢？这就要从handler.removeCallbacks 的实现说起了。
进一步查看 messageQueue.removeMessages 接口实现，发现该接口会遍历消息队列中符合当前 runnable 以及 object 的消息，但是上面传递的 Object 对象是 null，因此就相当于移除了当前 Handler 对象下面所有相同 runnable 对象的消息！
因为强制刷新和时序调整的问题，导致了消息队列中同时存在 2 个 UI doFrame 消息，并在强制执行之后被同时移除，从而导致一个无人认领的 barrier 消息一直停留在消息队列 ！
其它场景：
此外，除了上面遇到的场景会导致这类问题之外，还有一种场景也可能会导致这类问题，即:UI 异步刷新，尽管 Android 系统禁止异步刷新，并利用 checkThread 机制对 UI 刷新进行线程检查，但是百密一疏，如果开启硬件加速，在 AndroidO 及之后的版本会间接调用 onDescendantInvalidated 触发 UI 刷新，该逻辑躲过了系统 checkThread 检查，将会造成线程并发隐患。如下图，如果并发执行则会导致前一个线程的 mTraversalBarrier 被覆盖，从而导致 vsync 消息与 barrier 出现同步问题。
查看 Android Q 源码，看到 onDescendantInvalidated 内部加上了 checkThread**，但被注释掉了！解释如下：修复摄像头后重新启用或者通过 targetSdk 检查？好吧，或许是忘记这个 TODO 了。**
总结：
至此，我们完成了该类问题的分析和最终定位，综合来看该类问题因 Trace 场景(NativePollOnce)和问题本身的高度隐蔽性，给排查和定位带来了极大挑战，如果单纯依靠系统提供的日志，是很难发现 MessageQueue.next()内部发生了异常。这里我们通过 Raster 监控工具，还原了问题现场，并提供了重要线索。现在总结来看，该类问题其实具有很明显的特征，表现在以下几个方面：
-
**问题场景 ANR Trace 集中聚合在
NativePollOnce，**此过程 Wall duration 持续很长，并且屏蔽了后续所有正常消息调度，看起来像主线被冻结一样。 -
通过 Raster 监控工具可以清晰的看到，消息队列中如果第一个待消息 target 为 null，即为 barrier 消息，可以通过后续消息 block 时长评估影响程度。
-
出现该类问题时，因为正常消息无法被调度，如 Service，Receiver 消息，将会导致应用连续发生 ANR，直到用户主动 Kill 该进程。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）
关于面试的充分准备
一些基础知识和理论肯定是要背的，要理解的背，用自己的语言总结一下背下来。
虽然 Android 没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明 Android 中级以下的岗位饱和了，现在高级工程师还是比较缺少的，我能明显感觉到国庆后多了很多高级职位，所以努力让自己成为高级工程师才是最重要的。
好了，希望对大家有所帮助。
接下来是整理的一些Android学习资料，有兴趣的朋友们可以关注下我免费领取方式。
①Android开发核心知识点笔记
②对标“阿里 P7” 40W+年薪企业资深架构师成长学习路线图
③面试精品集锦汇总
④全套体系化高级架构视频
**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水！
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
**Android精讲视频领取学习后更加是如虎添翼！**进军BATJ大厂等（备战）！现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水！
[外链图片转存中…(img-3NT4SPG8-1713504331045)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
1629
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
