让 Chrome 崩溃的一行 CSS 代码
一般的 CSS 代碼只會(huì)出現(xiàn) UI 版式或者兼容性方面的小問題。但這里我們要分享一行有趣的 CSS，它可以直接讓你的 Chrome 頁面掛掉 :)
復(fù)現(xiàn)
其實(shí)這臺(tái)機(jī)器只有 8GB 內(nèi)存，不過這不重要了。和讓 JS 崩潰的紅線容量 4GB 比起來，果然還是 CSS 更強(qiáng)大呢 :)
故事
這行代碼的發(fā)現(xiàn)，源自于我們的編輯器項(xiàng)目在實(shí)現(xiàn)畫布尺寸調(diào)節(jié)時(shí)的一個(gè)詭異現(xiàn)象：用戶調(diào)節(jié)畫布尺寸時(shí)，只要新舊尺寸之比超過一定幅度，Chrome 就會(huì)卡死。
雖然這個(gè)問題很難由普通用戶的操作路徑觸發(fā)，不過它所導(dǎo)致的后果確實(shí)比較嚴(yán)重。排查時(shí)我們首先考慮了 JS 阻塞和 DOM 重繪過頻等方面的可能性，但它們都不是問題所在。一個(gè)突破點(diǎn)在于調(diào)試器 Rendering 工具中 FPS Meter 的輸出：
這里 GPU Memory 被占滿了。雖然這個(gè)提示信息現(xiàn)在看來很明顯是與硬件加速有關(guān)的，但在沒有相關(guān)經(jīng)歷的情況下我們還是沒有確定它與具體代碼之間的關(guān)聯(lián)。直到我們偶然查看 Chrome 設(shè)計(jì)文檔中關(guān)于 Compositing 的介紹時(shí)，發(fā)現(xiàn)了一個(gè)行為：Blink 會(huì)將 DOM 節(jié)點(diǎn)映射到 LayoutObject 的渲染樹，這棵樹中的節(jié)點(diǎn)理論上每個(gè)都能具備到渲染后端的上下文，但為了節(jié)約資源 Chrome 會(huì)將它們做一些合并后再渲染。而這時(shí)存在 CSS 定位（如絕對(duì)定位與 transform）的元素是不能合并的，這會(huì)造成對(duì)顯存的額外開銷。
基于這個(gè)信息的提示，我們使用 Layout 工具來調(diào)試當(dāng)時(shí)的頁面，果然找到了一個(gè)特殊的地方：
圖中最大的矩形 Layer 通過一般的 DOM 調(diào)試是無法看見的，因此我們推測(cè)它的過大尺寸所導(dǎo)致的 RAM 開銷是罪魁禍?zhǔn)住；谶@個(gè)信息，我們最后找到了一個(gè)寬高都很合理但 transform 的 scale 值可能在邏輯中被修改得很大的 DOM 節(jié)點(diǎn)，限制它的 scale 上限即可解決問題：我們不難發(fā)現(xiàn) scale 的值和最終對(duì)應(yīng)像素?cái)?shù)量之間有著 O(N^2) 的關(guān)系，1 個(gè)像素只放大 100 倍也有 10000 個(gè)像素了。因此 scale 很大時(shí)對(duì)內(nèi)存 / 顯存的過度使用也就是有可能的了（當(dāng)然瀏覽器會(huì)做 Tiling 等工作，因此這不符合一般情況下的實(shí)際情形，Safari / Firefox 這時(shí)候也沒有出現(xiàn)問題）。最后給 Chrome 提了個(gè) bug 見 #894115
總結(jié)
需要注意的是，因?yàn)槿狈?duì)瀏覽器內(nèi)核的深度了解，上面的調(diào)試思路很可能是不準(zhǔn)確的。簡(jiǎn)單的總結(jié)：
- 硬件加速是有代價(jià)的，最好能知道代價(jià)在哪
- 瀏覽器的文檔里藏著很多有意思的東西
- 調(diào)試工具的一些冷門功能其實(shí)很強(qiáng)大，平時(shí)可以多試試
希望大佬指正，謝謝 XD
edit: 似乎不是所有設(shè)備必現(xiàn)的，讓配置太好掛不掉的吃瓜同學(xué)們失望了。想更確定地復(fù)現(xiàn)的同學(xué)，在 bug 鏈接中有更容易復(fù)現(xiàn)問題的用例哈
edit-2: Chrome 團(tuán)隊(duì)可以復(fù)現(xiàn)并 assign 了這個(gè)問題，見 #894115
總結(jié)
以上是生活随笔為你收集整理的让 Chrome 崩溃的一行 CSS 代码的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 浏览器拦截打开新窗口情况总结
- 下一篇： CSS原理解析之模型篇