1. 程式人生 > >js之DOM深入學習總結

js之DOM深入學習總結

什麼是domReady?

html標籤和dom節點的區別是什麼?

html是一門標記語言,它告訴我們這個頁面有什麼內容。但行為操作是要通過Dom互動來實現的。我們不能認為只要存在html標籤,這個標籤就是一個dom了。html標籤要通過瀏覽器解析才能變成dom節點,當我在位址列中輸入一個url的時候,瀏覽器開始載入頁面,我們就能看到內容,在這個過程中,有一個dom節點構建的過程,節點是以樹的形式組織的。當頁面中的所有html標籤都轉化為dom節點之後,就叫做dom樹構建完畢,我們簡稱為domReady.其中瀏覽器是通過渲染引擎將html標籤轉化為dom節點。渲染引擎的職責是:把請求到的內容顯示到瀏覽器螢幕上。

瀏覽器渲染引擎的基本渲染流程

頁面渲染的基本流程:
解析HTML文件構建DOM樹——構建渲染樹——渲染樹佈局——繪製渲染樹
詳細過程:
第一步:瀏覽器將獲取到的HTML文件解析成DOM樹,HTML文件中的每個元素都對應DOM樹中的1個節點,根節點就是我們常用的document物件。DOM樹裡包含了所有HTML標籤,包括display:none隱藏的元素,還有用JS動態新增的元素等。
第二步: DOM樹和樣式結構體(解析樣式資訊,包括外部的css檔案、style標籤中的樣式)組合後構建render樹, 與DOM樹的不同在於:render樹能識別樣式,render 樹中每個節點都有自己的樣式,而且 render 樹不包含隱藏的節點 (比如display:none的節點,還有head節點),因為這些節點不會用於呈現,而且不會影響呈現的,所以就不會包含到 render 樹中。注意visibility:hidden隱藏的元素還是會包含到 render樹中的,因為visibility:hidden會影響佈局(layout),會佔有空間。渲染樹由一些包含有各種屬性的矩形組成,他們將會按照正確的順序顯示到螢幕上;
第三步:

佈局渲染樹(佈局DOM節點),執行佈局的過程,將確定每個節點在螢幕上的確切座標;
第四步:繪製渲染樹(繪製DOM節點,即遍歷渲染樹),使用UI後端層來繪製每個節點

window.onload事件是在頁面所有的資源都載入完畢後觸發的. 如果頁面上有大圖片等資源響應緩慢, 會導致window.onload事件遲遲無法觸發.所以出現了DOM Ready事件. 此事件在DOM文件結構準備完畢後觸發, 即在資源載入前觸發.

DOMContentLoaded 事件
這個事件在許多Webkit瀏覽器以及IE9上都可以使用, 此事件會在DOM文件準備好以後觸發, 包含在HTML5標準中. 對於支援此事件的瀏覽器, 直接使用DOMContentLoaded事件是最簡單最好的選擇.但是IE6,7,8都不支援DOMContentLoaded事件.所以目前所有的hack方法都是為了讓IE6,7,8支援DOM Ready事件.

doScroll : 微軟的文件指出doScroll必須在DOM主文件準備完畢時才可以正常觸發. 所以通過doScroll判斷DOM是否準備完畢.
注意:單純使用readyState屬性是無法判斷出Dom Ready事件的. interactive狀態過早(DOM沒有穩定), complete狀態過晚(圖片載入完畢).

高效能JavaScript之DOM程式設計

文件物件模型(DOM)是一個獨立於語言的,用於操作XML和HTML文件的應用程式介面,用指令碼進行DOM操作的代價很昂貴,它是Web應用中最常見的效能瓶頸。有個貼切的比喻,把DOM和JavaScript(這裡指ECMScript)各自想象為一個島嶼,它們之間用收費橋樑連線,ECMAScript每次訪問DOM,都要途徑這座橋,並交納”過橋費”。訪問DOM的次數越多,費用也就越高。因此,推薦的做法是儘量減少過橋的次數,努力待在ECMAScript島上。

DOM訪問與修改

訪問DOM元素是有代價的,即前面提到的”過橋費”。修改元素則更為昂貴,因為它會導致瀏覽器重新計算頁面的幾何變化(重排和重繪)。
當然,最壞的情況是在迴圈中訪問或者修改元素,尤其是對HTML元素集合迴圈操作。
Demo:

<body>
<div id="box"></div>
<script type="text/javascript">
var times = 20000;
//測試1
console.time(1);
for(var i=0;i<times;i++){
    document.getElementById("box").innerHTML+='a';
}
console.timeEnd(1);//1: 5961.652ms
//測試2
console.time(2);
var str = '';
for(var i=0;i<times;i++){
    str += 'a';//這裡用區域性變數儲存修改中的內容,然後在迴圈結束後一次性寫入
}
document.getElementById("box").innerHTML += str;
console.timeEnd(2);//2: 14.720ms
</script>
</body>

在所有瀏覽器中,修改後的版本都執行得更快。
測試程式碼1的問題在於:每次迴圈迭代,該元素都會被訪問兩次:一次讀取innerHTML的值,另一次重寫它,也就是說,每次迴圈都在”過橋”!結果顯而易見,訪問DOM的次數越多,程式碼的執行速度越慢。因此,減少訪問DOM訪問的次數,把運算儘量留在ECMAScript這端處理。

重繪和重排

瀏覽器下載完頁面中的所有元件——HTML標記、JavaScript、CSS、圖片之後會解析生成兩個內部資料結構:

  • DOM樹(表示頁面結構)
  • 渲染樹(表示DOM節點如何顯示)

DOM樹中的每一個需要顯示的節點在渲染樹中至少存在一個對應的節點(隱藏的DOM元素(disply值為none) 在渲染樹中沒有對應的節點)。渲染樹中的節點被稱為”幀”或”盒”,符合CSS模型的定義,理解頁面元素為一個具有內邊距,外邊距,邊框和位置的盒子。一旦DOM和渲染樹構建完成,瀏覽器就開始顯示(繪製”paint”)頁面元素。

當DOM的變化影響了元素的幾何屬性(寬或高)–比如改變邊框寬度或給段落增加文字,導致行數增加–瀏覽器需要重新計算元素的幾何屬性,同樣其他元素的幾何屬性和位置也會因此受到影響。瀏覽器會使渲染樹中受到影響的部分失效,並重新構造渲染樹。這個過程稱為重排(reflow)。完成重排後,瀏覽器會重新繪製受影響的部分到螢幕中,該過程稱為重繪(repaint)

並不是所有的DOM變化都會影響幾何屬性,比如改變一個元素的背景色並不會影響元素的寬和高,在這種情況下,只會發生一次重繪(不需要重排),因為元素的佈局並沒有改變。重繪和重排都是代價昂貴的操作,它們會導致Web應用程式的UI反應遲鈍,所以,應當儘可能減少這類過程的發生。
特別注意: 重排必將引起重繪,而重繪不一定會引起重排
重排和重繪的代價究竟有多大?我們再回到上面那個例子上,我們發現千倍的時間差並不是由於”過橋”一手造成的,每次”過橋”其實都伴隨著重排和重繪,而耗能的絕大部分也正是在這裡!
Demo:

<body>
<div id="box1"></div>
<div id="box2"></div>
<div id="box3"></div>
<script type="text/javascript">
var times = 20000;
// 測試1 每次過橋+重排+重繪
console.time(1);
for(var i = 0; i < times; i++) {
  document.getElementById('box1').innerHTML += 'a';
}
console.timeEnd(1);//7226.836ms
// 測試2 只過橋
console.time(2);
var str = '';
for(var i = 0; i < times; i++) {
  var tmp = document.getElementById('box2').innerHTML;//過橋
  str += 'a';
}
document.getElementById('box2').innerHTML = str;
console.timeEnd(2);//57.384ms
// 測試3
console.time(3);
var str1 = '';
for(var i = 0; i < times; i++) {
  str1 += 'a';
}
document.getElementById('box3').innerHTML = str1;
console.timeEnd(3);//3.735ms
</script>
</body>

從上面這個例子看出:多次訪問DOM對於重排和重繪來說,耗時簡直不值一提。

重排何時發生?

重排發生會導致重新構造渲染樹,以下情況會發生重排:

  • 新增或刪除可見的DOM元素
  • 元素位置改變
  • 元素尺寸改變(包括:外邊距、內邊距、邊框寬度、寬度、高度等屬性改變)
  • 內容改變(例如:文字改變或圖片被另一個不同尺寸的圖片替代)
  • 頁面渲染器初始化
  • 瀏覽器視窗尺寸改變–resize事件發生時

渲染樹變化的排隊與重新整理

由於每次重排都會產生計算消耗,大多數瀏覽器通過佇列化修改並批量執行來優化重排過程。瀏覽器把所有會引起重排、重繪的操作放入一個佇列,等佇列中的操作到了一定的數量或者到了一定的時間間隔,瀏覽器就會flush佇列,進行一個批處理。這樣就會讓多次的重排、重繪就變成一次重排重繪。
瀏覽器雖然進行一定優化處理,然而,你可能會(經常是不知不覺)強制重新整理佇列並要求計劃任務立即執行,這樣瀏覽器的優化作用就失效了。獲取佈局資訊的操作會導致佇列重新整理,比如以下方法:

  • offsetTop, offsetLeft, offsetWidth, offsetHeight
  • scrollTop, scrollLeft, scrollWidth, scrollHeight
  • clientTop, clientLeft, clientWidth, clientHeight
  • getComputedStyle() (currentStyle in IE)

以上屬性和方法需要返回最新的佈局資訊,因此瀏覽器不得不執行渲染佇列中的”待處理變化”並觸發重排以返回正確的值。我們在實際編碼中,應該儘可能避免使用上述屬性和方法,它們都會重新整理渲染佇列,即使你是在獲取最近未發生改變的或者與最新改變無關的佈局資訊。

最小化重繪和重排

看下面這個例子:

var el = document.getElementById('myDiv');
el.style.borderLeft = '1px';
el.style.borderRight = '2px';
el.style.padding = '5px';

示例中有三個樣式屬性被改變,每一個都會影響元素的幾何結構。最糟糕的情況下,會導致瀏覽器觸發三次重排。大部分現代瀏覽器都為此做了優化,只會觸發一次重排。如果在上面程式碼執行時,有其他程式碼請求佈局資訊,這會導致請求佈局資訊,這會導致觸發三次重排。而且,這段程式碼四次訪問DOM,可以被優化。一個能夠達到同樣效果且效率更高的方式是:合併所有的改變然後一次處理,這樣只會修改DOM一次

使用cssText屬性

修改程式碼如下:

var el = document.getElementById('myDiv');
el.style.cssText = 'border-left: 1px; border-right: 2px; padding: 5px;';

使用cssText屬性會覆蓋已經存在的樣式資訊,如果想保留現有樣式,可以把它附加在cssText字串後面

var el = document.getElementById('myDiv');
el.style.cssText += 'border-;eft: 1px;'

修改CSS的class名稱

另一個一次性修改樣式的方法是修改CSS的class名稱,而不是修改內聯樣式。這種方法適合於那些不依賴於執行邏輯和計算的情況。

var el = document.getElementById('myDiv');
el.className = 'active';

批量修改DOM

當需要對一個DOM元素進行一系列操作時,可以採用以下步驟:
1、使元素脫離文件流;
2、對元素應用多重改變;
3、把元素帶回文件中。
在這個過程中,會觸發兩次重排:第一步和第三步。如果忽略這兩個步驟,那麼第二步所產生的任何修改都會觸發一次重排。
三種基本方法使DOM脫離文件:
1、隱藏元素,應用修改,重新顯示;
2、使用文件片段,在當前DOM之外構建一個子樹,再把它拷貝迴文檔;
3、將原始元素拷貝到一個脫離文件的節點中,修改副本,完成後再替換原始元素。

文件片段fragment元素的應用

在文件之外建立並更新一個文件片段,然後把它附加到原始列表中。
文件片段是個輕量級的document物件,它的設計初衷就是為了完成這類任務——更新和移動節點。文件片段的一個便利的語法特性是當你附加一個片段到節點時,實際上被新增的是該片段的子節點,而不是片段本身。只觸發了一次重排,而且只訪問了一次實時的DOM。

讓元素脫離動畫流

用展開/摺疊的方式來顯示和隱藏部分頁面是一種常見的互動模式。它通常包括展開區域的幾何動畫,並將頁面其他部分推向下方。

一般來說,重排隻影響渲染樹中的一小部分,但也可能影響很大的部分,甚至整個渲染樹。瀏覽器所需要重排的次數越少,應用程式的響應速度就越快。因此當頁面頂部的一個動畫推移頁面整個餘下的部分時,會導致一次代價昂貴的大規模重排,讓使用者感到頁面一頓一頓的。渲染樹中需要重新計算的節點越多,情況就會越糟。

使用以下步驟可以避免頁面中的大部分重排:

  • 使用絕對位置定位頁面上的動畫元素,將其脫離文件流
  • 讓元素動起來。當它擴大時,會臨時覆蓋部分頁面。但這只是頁面一個小區域的重繪過程,不會產生重排並重繪頁面的大部分內容
  • 當動畫結束時恢復定位,從而只會下移一次文件的其他元素

小結

重排和重繪是DOM程式設計中耗能的主要原因之一,平時涉及DOM程式設計時可以參考以下幾點:

  • 儘量不要在佈局資訊改變時做查詢(會導致渲染佇列強制重新整理
  • 同一個DOM的多個屬性改變可以寫在一起(減少DOM訪問,同時把強制渲染佇列重新整理的風險降為0)
  • 如果要批量新增DOM(比如要給ul新增很多li),可以先讓元素脫離文件流,操作完後再帶入文件流,這樣只會觸發一次重排(文件片段(fragment)元素的應用)
  • 將需要多次重排的元素,position屬性設為absolute或fixed,這樣此元素就脫離了文件流,它的變化不會影響到其他元素。例如有動畫效果的元素就最好設定為絕對定位。

推薦一篇相關博文,總結的很好:傳送門