APM 页面加载耗时校准
作者：千诺
出品：大淘宝技术
在最新的 APM 自动化页面加载耗时计算中，剔除了对用户页面加载体验无效的元素，聚焦页面加载体验中的核心元素，既给了业务相对的自由度，又达到了一定的加载体感准确性。
背景
APM 的全称叫做 Application Performance Monitor，属于应用性能监控部分。在手淘的 APM 中有一项特殊的数据，叫做页面可视耗时，不同于业界常规的技术视角阐述数据，我们更倾向于从用户体验交互进行阐述。
以 Activity 实现的页面为例，在页面加载过程中，用户关心的是从点击开始到最后页面完全呈现，直至用户可以进行交互的一个过程，而不是单纯 Activity 的 Lifecycle 耗时，更不是技术视角的一个阶段数据。
更逼近用户体验的数据是我们在页面加载上的追求。接下来我将从淘宝 APM 如何从用户角度实现可视计算的历史进行介绍，并深入详解淘宝对页面加载耗时校准所做一些努力与改变。
从0到1：可视计算
页面可视耗时可以拆解成起点与终点，起点争议相对较少，使用的是 Activity onCreate 时间、 Fragment onFragmentPreAttached 时间以及页面跳转时间，下面主要针对可视终点进行讨论：
为什么要引入可视计算？
在 APM 中，对于页面打开耗时统计，常见有三类：Lifecycle、首帧、自定义埋点。
监控 Lifecycle 是 Android 天然的一套监控耗时的方案，奈何生命周期的耗时只是页面加载过程中的一个阶段，具有一定的技术需求观测性，但是正如文章开头所言，它其实不是我们追求的用户体验上的页面加载时长。
从 Android API 19 之后，Android 在系统 Log 中增加了 Display 的 Log 信息，它是 Activity 完成首帧的时间，可以看得出来，它也是 Google 比较重视的一个点，但它还是页面加载过程中的一个分阶段监控点，不是我们的目标结束点。
除此之外，Google 还为我们提供了 reportFullyDrawn 接口，当业务认为渲染完成时进行调用。因为业务各自不一的实现往往导致首帧距离真正的页面加载完成有相当一段距离。当然不只是 Google 意识到这一点，FaceBook 也在这方面使用上做了些有趣的尝试。
reportFullyDrawn 接口与我们常说的业务埋点其实是一回事，这样的方式统计出来的数据是相对不错与精准的，但是仍会面临几个问题：
带你读《2022技术人的百宝黑皮书》——APM 页面加载耗时校准（2）https://developer.aliyun.com/article/1340942?groupCode=taobaotech
