#性能优化-白屏度量 阿里是怎么监控前端白屏的？

这两者方向不同，资源错误影响面较多，且视情况而定，故不在下面方案考虑范围内。为此，参考了网上的一些实践加上自己的一些调研，大概总结出了一些方案：

一、onerror + DOM 检测

原理很简单，在当前主流的 SPA 框架下，DOM 一般挂载在一个根节点之下（比如 <div id="root"></div> ）发生白屏后通常现象是根节点下所有 DOM 被卸载，该方案就是通过监听全局的 onerror 事件，在异常发生时去检测根节点下是否挂载 DOM，若无则证明白屏。我认为是非常简单暴力且有效的方案。但是也有缺点：其一切建立在 白屏 === 根节点下 DOM 被卸载 成立的前提下，实际并非如此比如一些微前端的框架，当然也有我后面要提到的方案，这个方案和我最终方案天然冲突。

二、Mutation Observer Api

不了解的可以看下文档[1]。其本质是监听 DOM 变化，并告诉你每次变化的 DOM 是被增加还是删除。为其考虑了多种方案：

1. 搭配 onerror 使用，类似第一个方案，但很快被我否决了，虽然其可以很好的知道 DOM 改变的动向，但无法和具体某个报错联系起来，两个都是事件监听，两者是没有必然联系的。

2. 单独使用判断是否有大量 DOM 被卸载，缺点：白屏不一定是 DOM 被卸载，也有可能是压根没渲染，且正常情况也有可能大量 DOM 被卸载。完全走不通。

3. 单独使用其监听时机配合 DOM 检测，其缺点和方案一一样，而且我觉得不如方案一。因为它没法和具体错误联系起来，也就是没法定位。当然我和其他团队同学交流的时候他们给出了其他方向：通过追踪用户行为数据来定位问题，我觉得也是一种方法。

一开始我认为这就是最终答案，经过了漫长的心里斗争，最终还是否定掉了。不过它给了一个比较好的监听时机的选择。

三、饿了么-Emonitor 白屏监控方案

饿了么的白屏监控方案，其原理是记录页面打开 4s 前后 html 长度变化，并将数据上传到饿了么自研的时序数据库。如果一个页面是稳定的，那么页面长度变化的分布应该呈现「幂次分布」曲线的形态，p10、p20 （排在文档前 10%、20%）等数据线应该是平稳的，在一定的区间内波动，如果页面出现异常，那么曲线一定会出现掉底的情况。

其他

其他都大同小样，其实调研了一圈下来发现无非就是两点

1. 监控时机：调研下来常见的就三种：

2. onerror

3. mutation observer api

4. 轮训

5. DOM 检测：这个方案就很多了，除了上述的还可以：

6. elementsFromPoint api 采样

7. 图像识别

8. 基于 DOM 的各种数据的各种算法识别

9. …

改变方向

---

几番尝试下来几乎没有我想要的，其主要原因是准确率 – 这些方案都不能保证我监听到的是白屏，单从理论的推导就说不通。他们都有一个共同点：监听的是’白屏’这个现象，从现象去推导本质虽然能成功，但是不够准确。所以我真正想要监听的是造成白屏的本质。

那么回到最开始，什么是白屏？他是如何造成的？是因为错误导致的浏览器无法渲染？不，在这个 spa 框架盛行的现在实际上的白屏是框架造成的，本质是由于错误导致框架不知道怎么渲染所以干脆就不渲染。由于我们团队 React 技术栈居多，我们来看看 React 官网的一段话[2]：

React 认为把一个错误的 UI 保留比完全移除它更糟糕。我们不讨论这个看法的正确与否，至少我们知道了白屏的原因：渲染过程的异常且我们没有捕获异常并处理。

反观目前的主流框架：我们把 DOM 的操作托管给了框架&