中标建设集团有限公司 网站,wordpress+修改邮箱设置,建立网站需要备案吗,wordpress聚合平台模板一般的 CSS 代码只会出现 UI 版式或者兼容性方面的小问题。但这里我们要分享一行有趣的 CSS#xff0c;它可以直接让你的 Chrome 页面挂掉 :)
复现
在 Chrome 里打开一个稍复杂的页面#xff0c;比如知乎或者掘金打开开发者工具#xff0c;为页面 body 增加样式 s…一般的 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 见 #894115
总结
需要注意的是因为缺乏对浏览器内核的深度了解上面的调试思路很可能是不准确的。简单的总结
硬件加速是有代价的最好能知道代价在哪浏览器的文档里藏着很多有意思的东西调试工具的一些冷门功能其实很强大平时可以多试试
希望大佬指正谢谢 XD edit: 似乎不是所有设备必现的让配置太好挂不掉的吃瓜同学们失望了。想更确定地复现的同学在 bug 链接中有更容易复现问题的用例哈 edit-2: Chrome 团队可以复现并 assign 了这个问题见 #894115
