您好,登錄后才能下訂單哦!
這篇文章主要介紹了如何使用CSS讓Chrome崩潰,具有一定借鑒價(jià)值,感興趣的朋友可以參考下,希望大家閱讀完這篇文章之后大有收獲,下面讓小編帶著大家一起了解一下。
復(fù)現(xiàn)
在 Chrome 里打開一個(gè)稍復(fù)雜的頁面,比如知乎或者 掘金
打開開發(fā)者工具,為頁面 <body> 增加樣式 style: "width:1px; height:1px; transform:scale(10000)"
欣賞任務(wù)管理器里 Chrome 崩潰前的內(nèi)存占用
其實(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
感謝你能夠認(rèn)真閱讀完這篇文章,希望小編分享的“如何使用CSS讓Chrome崩潰”這篇文章對(duì)大家有幫助,同時(shí)也希望大家多多支持億速云,關(guān)注億速云行業(yè)資訊頻道,更多相關(guān)知識(shí)等著你來學(xué)習(xí)!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。