我們一直以來備受DOM操作低效率的困擾，直接把所有責任都推給DOM是不對的。在DOM背后還有一個和它一樣糟糕的家伙在坑效率。這家伙有時候會帶來比DOM本身更嚴重的問題。 DOM的操作本身是同步的，代碼執(zhí)行完的同時操作也完成了，但這“完成”僅限于DOM本身。DOM操作完成只是在當前腳本運行所在的消息中，我們在這里干的壞事不會立即遭報。當這個消息結(jié)束時候，CSS重新計算我們對文檔影響的部分，如果這部分很大就需要大量的時間。我們可以做這樣的測試 運行<script> document.onclick=function(){ var i,t,div,body; t=new Date; body=document.body; for(i=0;i<1E4;i++){ div=document.createElement("div"); body.appendChild(div); }; console.log(new Date-t+" <- DOM操作耗時"); t=new Date; setTimeout(function(){ console.log(new Date-t+" <- CSS渲染耗時"); }); }; </script>

這個代碼只測試了1E4個元素，可把我們的Chrome累壞了，F(xiàn)irefox和IE躲在一旁笑嘻嘻。Chrome的問題應(yīng)該是出在它渲染引擎的某些算法上。我做了很多測試，Chrome的渲染引擎在添加元素的問題上是指數(shù)時間復雜度，而Firefox和IE則是線性時間復雜度。所以元素的數(shù)量一多Chrome就吃不消了。但這篇文章要說的關(guān)鍵不是Chrome渲染引擎的BUG，而是渲染本身帶來的性能開銷。我們看Chrome中對上面代碼工作的耗時分布

RecalculateStyle的耗時是很大的，這個測試還是在完全沒有用戶CSS的環(huán)境下測試的，如果我引入一個非常復雜的CSS，那么這個計算時間還得增加許多。當然這個圖是Chrome上的，RecalculateStyle的耗時比較夸張。但是即使在Firefox和IE上，他們至少也是線性的時間復雜度。 很多文章中說使用文檔片段(DocumentFragment)來優(yōu)化DOM操作的性能，這種說法是建立在“DOM操作實時計算CSS”的設(shè)想上的。如果DOM操作實時計算CSS，那確實可以合并這些計算起到優(yōu)化作用。但實際上計算CSS的步驟并不在操作DOM時進行，而是在單獨的消息中完成的，所以文檔片段在這方面不能帶來優(yōu)化。 操作DOM和計算CSS，這兩個步驟都是必不可少的。線性的時間復雜度已經(jīng)是最優(yōu)的了。如果說可以優(yōu)化，我們只能針對Chrome的這個BUG來優(yōu)化，解決在Chrome上的問題。如果非要對這整個問題進行優(yōu)化就得從問題的根本入手，避免大規(guī)模的文檔結(jié)構(gòu)變化。 最后我只想說，讓文檔變得如此巨大的程序本身就不是好程序！

本文標題：DOM操作的額外性能問題
URL標題：http://aaarwkj.com/news43/317393.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、網(wǎng)站營銷、品牌網(wǎng)站制作、動態(tài)網(wǎng)站、電子商務(wù)、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)