流畅性三板斧番外之：各大厂与卡顿和ANR的战役记载

前言

前段时刻写了流畅性三板斧的系列文章，比较系统性但不是很精细的梳理了下在Android端怎么做帧率监控、主线程耗时监控、以及ANR 的监控。在写作进程中也参阅了大厂在这方面对外共享的技能文章，本文就此梳理下这些文章，一是为了更好的吸收消化这些计划从中罗致营养，另一方面也算是问候这些协助咱们成长的忘我共享。

1 今天头条团队对ANR问题对外共享

首先是，2021年3月份，今天头条团队共享的ANR 优化实践系列文章：

  • 《今天头条 ANR 优化实践系列 – 规划原理及影响要素》：/post/694006…

  • 《今天头条 ANR 优化实践系列 – 监控东西与剖析思路》：/post/694266…

  • 《今天头条 ANR 优化实践系列共享 – 实例剖析集锦》：/post/694526…

  • 《今天头条 ANR 优化实践系列 – Barrier导致主线程假死》：/post/694798…

  • 《今天头条 ANR 优化实践系列 – 离别 SharedPreference 等候》：/post/696196…

1.1 认识ANR

1.1.1 系统怎么处理ANR

规划原理和影响要素篇，首要对以下要害问题展开

  • ANR触发的条件以及根本原因

  • 产生ANR之后，系统处理ANR的流程。

  • 运用层怎么断定ANR：对ANR的感知，经过监听SIGQUIT信号。

  • 运用层面怎么获取有用的信息协助处理ANR问题。

1.1.2 ANR问题分类

把ANR 产生的影响要素清晰的分为了四个大的类别，基本覆盖了ANR问题产生的原因。

  • 运用内主线程存在耗时使命；

  • 运用主线程处理许多使命；

  • 系统内部其他进程或许资源负载过高；

  • 运用自身其他线程或许负载过高。

系列文章其实便是环绕着这些问题的监控、剖析、处理展开的。

2 东西建造-音讯调度监控

经过博文得知，今天头条团队，ANR 监控的东西叫 Raster，其最首要的功能便是搜集主线程调度。

ANR 产生的原因许多状况下或许是历史耗时问题的累计。因此单纯搜集产生ANR 时那一刻的仓库就会有【仓库漂移的问题】，也便是搜集到的仓库不是诱发ANR 产生的真实原因。现在ANR 监控的许多结构也是环绕这一问题展开的。

应对方法 对主线程音讯调度进行监控记载，包含历史音讯，正在履行的音讯和即将履行的音讯。一起对四大组件履行的音讯进行独自的监控，这对咱们剖析哪个组件产生的ANR 是很重要的参阅根据。

这一计划是在网上揭露的我能接触到的最早提出的，后面咱们会看到许多团队对ANR 问题的监控都是这一计划的变种，或许迥然不同。

这一计划的细化，首要包含以下几个方面

2.1 音讯聚合

音讯计算聚合战略：主线程音讯会许多，记载曩昔5-10秒的音讯自身是一个比较重的动作，选用必定的聚合战略是很有必要的。

  • 合并耗时段的多个音讯：耗时较小的音讯，对ANR 问题的产生影响不大，只记载总耗时和和音讯的个数。

  • 独立组件音讯：ActivtyThread 组件调度经过Handler咱们可以搜集到这些调度，独自记载。

  • 独立耗时音讯：对超过阈值（比如300ms）的音讯独自记载，耗时音讯是咱们要点重视的对象。

  • 记载IDEL 状况，主线程无音讯的时候，会进入IDEL 状况，阻塞在nativePoll 处。这一状况独自计算。

  • 产生ANR 时，搜集当前正在进行的使命。

  • ANR 产生时，搜集pending音讯，根据pending音讯中的组件调度音讯能让们知道哪个组件触发 ANR，一起根据等候的经常侧面反映系统负载的能力。

2.2 每条音讯记载的要害信息

  • 音讯调度的时长：cputime 和 walltime，记载两个时刻能更好的判别一次音讯耗时是履行耗时仍是等候或许抢占较多。

  • 音讯调度的类型：组件调度，耗时调度，多音讯聚合调度

  • 音讯仓库：对音讯内详细履行信息，搜集其仓库。

    流畅性三板斧番外之：各大厂与卡顿和ANR的战斗记录

2.3 主线程线程仓库的采样

对耗时的音讯，进行采样，采取的战略是超时采样。详细来说，介于大部分的耗时小音讯不需求进行仓库采样，为了避免频频设置和撤销超时使命（也便是采样使命），头条在此处做了一个优化，每次音讯开端是并不是从头设置搜集超时使命，而是修改方针时刻。

流畅性三板斧番外之：各大厂与卡顿和ANR的战斗记录

3 问题剖析&处理

  • 结合结合搜集的物料，这些物料包含ANR Info信息，搜集的主线程调度信息等给出了剖析ANR问题的一般思路。经过trace信息读取是否有显着的耗时调用，经过ANR Info剖析系统负载，运用内负载，再结合Raster搜集的线程调用，把ANR问题终究归因上上述四大要素上。然后详细剖析处理。这里不做展开了，今天头条团队案例剖析仍是相当精彩的不容错失。

  • 对Barrier走漏的监控和由SP引发的案例进行详细的剖析。

2 微信团队

2021年7月份，微信团队发布在公众号上的两篇文章关于卡顿监控和ANR监控的文章

  • 《微信Android客户端的卡顿监控计划》：mp.weixin.qq.com/s/3dubi2GVW…

  • 《微信Android客户端的ANR监控计划》：mp.weixin.qq.com/s/fWoXprt2T…

2.1 首先第一篇《微信Android客户端的卡顿监控计划》

  • 该篇是我接触到的最早也或许是仅有一篇指出运用WatchDog计划漏报卡顿和ANR的问题的文章。文章里乃至还指出了漏报概率公式，以及怎么不漏报的计划，如下图

流畅性三板斧番外之：各大厂与卡顿和ANR的战斗记录

思考这样一个问题，假如咱们挑选间隔4.5秒去check发送到主线程Looper到Message是否被消费。现在有一个5秒到卡顿，从2秒开端，完毕在第7秒耗时5秒，咱们间隔5秒能监控到的概率是多少？

答案是只有11%，惊讶不。原因便是在在0-4.5和4.5到9这两个周期内那些空闲的时刻，音讯都有或许被消费掉！这种状况咱们就监控不到了。想想，你再想想，真的是佩服腾讯工程师严谨的工程风格。

  • 另外，该篇全面的的供给了监控主线程卡顿的计划，包含

  • 主线程Message处理的耗时，运用的是设置Looper Printer的计划，Android10以后咱们可以经过设置Observer监控，有爱好的可以找相关资料。

  • IdleHandler耗时的监控，经过hook MessageQueue mIdleHandlers实现。

  • TouchEvent的耗时监控，经过PLT Hook。这一块要留意，TouchEvent的事情分发是不经过Handler机制，而是直接native层调到java层分发给View的，假如这个知识点不清楚的小伙伴留意了，又有新知识学习了。

2.2 第二篇文章

很是精彩，ANR怎么产生，系统源码实现，找监控计划直接一套组合拳，可见功底深厚大佬便是大佬。

其中，经过监听SIGQUIT信号并过滤误报终究监控ANR的计划，也是当前主流的正规计划，为什么是加一个正规的修饰词呢，想想ANRWatchDog那种多不正经就知道这个有多正规。

这里面，几个重要的点我列下

  • 监听SIGQUIT信号，需求留意从头发送出去

  • 梳理系统ANR的进程中，发现的ANR Trace 经过hook手法可以拿到

这便是微信团队出的关于Android卡顿和ANR的两篇经典文章，建议我们自傲研读，卷起来！

3 钉钉技能团队

2022年12月份，钉钉团队宣布的ANR 问题的处理计划系列文章。

  • 《钉钉 ANR 治理最佳实践 | 定位 ANR 不再水中望月》：mp.weixin.qq.com/s/Cc02krw5L…

  • 《让 nativePollOnce 不再排名第一 | 钉钉 ANR 治理最佳实践：mp.weixin.qq.com/s/8hN9A5Epe…

  • 《钉钉 ANR 实战踩坑与经验总结 | 钉钉 ANR 治理最佳实践》：mp.weixin.qq.com/s/4IY3FC27P…

3.1 ANR 断定

作为ANR问题不可避免的两个问题

  • 文章也是剖析了系统ANR 的流程

  • 断定ANR的计划也是经过监听SIGQUIT 并过滤误报的方法。

3.2 东西建造

监控ANR 的计划思路与今天头条基本一起，搜集主线程的调度信息做记载。其中也有一些不同，把主线程调度的分类，以下五类

流畅性三板斧番外之：各大厂与卡顿和ANR的战斗记录

  • 主线程的音讯调度

  • IdelHandler 调度

  • IDLE 状况

  • 接触事情

  • 传感器事情

可见，其在主线程使命调度的方面监控的愈加详细，今天头条的Raster东西从博文看只是对主线程的音讯调度进行了监控，咱们在结合微信团队的卡顿监控计划，其实可以更全面的对主线程使命进行调度，这一点很知道借鉴学习。

此外，博文里还提出有些手机厂商在运用进程会进入冻住状况，APP 回到前台后才持续履行，冻住的进程里会导致使命耗时过长，需求独自记载，不过这一点今天头条的计划，里可以经过CPUTime 和WallTime 识别出来。

其他方面，ANRCanery 搜集也会搜集曩昔当下和等候的使命调度，也对会搜集的音讯进行聚合处理。仓库搜集上，也是选用了时刻对齐计划对仓库进行采样。

3.3 实践共享

  • 结合详细场景共享了一些死锁场景，Barrier音讯泄露场景等。

  • 还共享了东西建造的心得，很有启发性。

4 其他团队

4.1 阿里其他技能团队

4.1.2 闲鱼团队

2021年6月份， 《关于闲鱼的ANR治理，我有几条心得》developer.aliyun.com/article/786…

文章短小精悍

  • 【监控】监听SIGQUIT信号

  • 【排查】搭建了ANR Info搜集和主线程Message监控。

  • 【优化】给出了三个在借助排查东西的优化案例。

3.3 手淘技能团队

《手淘 Android 帧率搜集与监控详解》：/post/705151…

手淘团队2022年1月份，提出了Android [滑动帧率]思路并给出了比较详细的监控计划。

4.2 shopee 团队

2022年8月份 LooperMonitor

《Android 卡顿与 ANR 的剖析实践》：/post/713600…

  • ANR的断定: 也是经过SIGQUIT +过滤的方法。

  • ANR的监控 ：主线程的监控思路与今天头条和字节跳动一起，记载主线程的调度信息，也是有聚合的战略。

值得留意的点：

  • 文章里要点提出了对音讯的记载运用了池化技能，削减内存重复分配问题。

  • 搜集仓库的计划上，这里说到了利用Kotlin协程非阻塞式挂起特性实现了高效的搜集。该计划并没有详细展开怎么实现的。一起搜集阈值线性添加。

  • 对Looper Message的监控，在 Android api ≥ 28 时，Looper 中新增了一个 Observer 的接口，选用元反射的方法，削减了经过Looper Printer 拼接Message带来的功能损耗。

4.3 毒物团队

2021年9月份得物团队宣布了ANR监控文章

《得物技能 | 得物App ANR监控渠道规划》/post/700929…

  • ANR断定运用了爱奇艺的XCarash因此能搜集到tomsbtone信息

  • 主线程音讯回溯搜集思路与其他家类似。

  • 毒物搭建了ANR剖析渠道，数据可视化，有必定的参阅意义。

5 多说一些抓栈问题。

java层面直接经过thread.getStackTrace()获取仓库信息，是有必定损耗的，对此咱们看到我们惯例的做法是控制搜集的频率，shoppe团队说到的由协程的非阻塞式挂起实现高效的线程仓库搜集，对此我是持怀疑态度

业界确实对高效搜集仓库方向有探究，给出了高效的抓栈计划，妥妥的黑科技看到了比较优秀的两篇供我们参阅。

  • 《西瓜视频稳定性治理系统建造三：Sliver 原理及实践》：mp.weixin.qq.com/s/LW3eMK9O2…

  • 网易云音乐《不一样的Android仓库抓取计划》:/post/721280…

总结

纵观各厂在卡顿和ANR 方面做的探究和计划，咱们可以看出，思路上都有重合，在细节方面做了许多针对自身业务和实际状况做的针对性的优化和个性化的开发。总的来说逃不出以下几个过程

流畅性三板斧番外之：各大厂与卡顿和ANR的战斗记录

  • ANR的感知上：业界主流的计划便是监听SIGQUIT 信号+误报过滤。腾讯技能团队，说到的OV 厂商对ANR的处理并不是惯例的处理，而是做闪退处理，所以要以check主线程正在处理的 Message，延误时刻作为辅助避免漏报。

  • 信息搜集上：由于产生ANR 时，主线程正在处理的使命或许并不是产生ANR的真实原因，因此需求对主线程使命过往调度进行计算记载，一起对音讯进行监控，监控的类型，其实微信团队卡顿计划监控给出了全面的计划。需求对音讯进行聚合处理。使命的履行栈抓取，控制频次，也有团队给出了高效抓栈计划。另外，出了主线程调度音讯外，系统负载状况信息对咱们剖析ANR 很重要，因为ANR 产生的原因可不仅仅是主线程履行了耗时使命。

  • 问题处理：全面准确的信息搜集的基础上，会让找出问题处理问题工作变得更简略，各团队也给出了思路和案例，参阅性很高。

上述ANR 的监控计划，截止到现在都没有开源，卡顿监控在Matrix上开源了。talk is cheap ，因此我在正在测验取各家之所长，编写开源一个ANR监控东西。现在正在草稿阶段，把基本结构做完之后会尽快开源出来，期望我们参与进来一起建造。重视作者 别错失更新进展。

ANR问题从监控到搜集都运用了各种hook手法黑科技，ANR作为Android一种维护机制， 只提出问题，不处理问题的行为都是xxx，现在还未看到官方对此有何动作。

好了，写文不易，不足之处批评指正，期望各位点赞 评论 鼓舞 感谢！！！

另附系列文章：

Android 流畅性三板斧之帧率监控（/post/721780…）

Android 流畅性三板斧之卡顿监控（/post/721877…）

Android 流畅性三板斧之ANR监控 (/post/722004…)

本文正在参加「金石计划」