“我在秒杀 iPhone XS 的支付页面卡了 3 秒,最后没抢到”,用户嘶声力竭地反馈了一个卡顿问题。
“莫慌莫慌”,等我打开 Android Studio, 用上一讲学到的几个工具分析一下就知道原因了。
“咦,在我这里整个支付过程丝滑般流畅”。这个经历让我明白,卡顿跟崩溃一样需要“现场信息”。因为卡顿的产生也是依赖很多因素,比如用户的系统版本、CPU 负载、网络环境、应用数据等。
脱离这个现场,我们本地难以复现,也就很难去解决问题。但是卡顿又非常影响用户体验的,特别是发生在启动、聊天、支付这些关键场景,那我们应该如何去监控线上的卡顿问题,并且保留足够多的现场信息协助我们排查解决问题呢?
卡顿监控
前面我讲过监控 ANR 的方法,不过也提到两个问题:一个是高版本的系统没有权限读取系统的 ANR 日志;另一个是 ANR 太依赖系统实现,我们无法灵活控制参数,例如我觉得主线程卡顿 3 秒用户已经不太能忍受,而默认参数只能监控至少 5 秒以上的卡顿。
所以现实情况就要求我们需要采用其他的方式来监控是否出现卡顿问题,并且针对特定场景还要监控其他特定的指标。
1. 消息队列
我设计的第一套监控卡顿的方案是基于消息队列实现,通过替换 Looper 的 Printer 实现。在 2013 年的时候,我写过一个名为 WxPerformanceTool 的性能监控工具,其中耗时监控就使用了这个方法。后面这个工具在腾讯公共组件做了内部开源,还获得了 2013 年的年度十佳组件。