让 Chrome 崩溃的一行 CSS 代码

时间 2019-11-16

标签 chrome 崩溃一行 css 代码栏目 Chrome 繁體版

原文原文链接

通常的 CSS 代码只会出现 UI 版式或者兼容性方面的小问题。但这里咱们要分享一行有趣的 CSS，它能够直接让你的 Chrome 页面挂掉 :)后端

复现

在 Chrome 里打开一个稍复杂的页面，好比知乎或者掘金
打开开发者工具，为页面 <body> 增长样式 style: "width:1px; height:1px; transform:scale(10000)"
欣赏任务管理器里 Chrome 崩溃前的内存占用

其实这台机器只有 8GB 内存，不过这不重要了。和让 JS 崩溃的红线容量 4GB 比起来，果真仍是 CSS 更强大呢 :)浏览器

故事

这行代码的发现，源自于咱们的编辑器项目在实现画布尺寸调节时的一个诡异现象：用户调节画布尺寸时，只要新旧尺寸之比超过必定幅度，Chrome 就会卡死。编辑器

虽然这个问题很难由普通用户的操做路径触发，不过它所致使的后果确实比较严重。排查时咱们首先考虑了 JS 阻塞和 DOM 重绘过频等方面的可能性，但它们都不是问题所在。一个突破点在于调试器 Rendering 工具中 FPS Meter 的输出：工具

这里 GPU Memory 被占满了。虽然这个提示信息如今看来很明显是与硬件加速有关的，但在没有相关经历的状况下咱们仍是没有肯定它与具体代码之间的关联。直到咱们偶然查看 Chrome 设计文档中关于 Compositing 的介绍时，发现了一个行为：Blink 会将 DOM 节点映射到 LayoutObject 的渲染树，这棵树中的节点理论上每一个都能具有到渲染后端的上下文，但为了节约资源 Chrome 会将它们作一些合并后再渲染。而这时存在 CSS 定位（如绝对定位与 transform）的元素是不能合并的，这会形成对显存的额外开销。设计

基于这个信息的提示，咱们使用 Layout 工具来调试当时的页面，果真找到了一个特殊的地方：调试

图中最大的矩形 Layer 经过通常的 DOM 调试是没法看见的，所以咱们推测它的过大尺寸所致使的 RAM 开销是罪魁祸首。基于这个信息，咱们最后找到了一个宽高都很合理但 transform 的 scale 值可能在逻辑中被修改得很大的 DOM 节点，限制它的 scale 上限便可解决问题：咱们不难发现 scale 的值和最终对应像素数量之间有着 O(N^2) 的关系，1 个像素只放大 100 倍也有 10000 个像素了。所以 scale 很大时对内存 / 显存的过分使用也就是有可能的了（固然浏览器会作 Tiling 等工做，所以这不符合通常状况下的实际情形，Safari / Firefox 这时候也没有出现问题）。最后给 Chrome 提了个 bug 见 #894115code

总结

须要注意的是，由于缺少对浏览器内核的深度了解，上面的调试思路极可能是不许确的。简单的总结：orm

硬件加速是有代价的，最好能知道代价在哪
浏览器的文档里藏着不少有意思的东西
调试工具的一些冷门功能其实很强大，平时能够多试试

但愿大佬指正，谢谢 XDcdn

edit: 彷佛不是全部设备必现的，让配置太好挂不掉的吃瓜同窗们失望了。想更肯定地复现的同窗，在 bug 连接中有更容易复现问题的用例哈blog

edit-2: Chrome 团队能够复现并 assign 了这个问题，见 #894115