DocumentFragment文檔碎片

codercao 發(fā)布于2019-08-26 10:29 / 2369人閱讀

摘要：在樹中，文檔片段被其所有的孩子所代替。因?yàn)槲臋n片段存在于內(nèi)存中，并不在樹中，所以將子元素插入到文檔片段時(shí)不會(huì)引起頁(yè)面回流對(duì)元素位置和幾何上的計(jì)算。因此，使用文檔片段通常會(huì)起到優(yōu)化性能的作用。在里說(shuō)過(guò)接口表示文檔的一部分或一段。

DocumentFragments 是DOM節(jié)點(diǎn)。它們不是主DOM樹的一部分。通常的用例是創(chuàng)建文檔片段，將元素附加到文檔片段，然后將文檔片段附加到DOM樹。在DOM樹中，文檔片段被其所有的孩子所代替。因?yàn)槲臋n片段存在于內(nèi)存中，并不在DOM樹中，所以將子元素插入到文檔片段時(shí)不會(huì)引起頁(yè)面回流(reflow)(對(duì)元素位置和幾何上的計(jì)算)。因此，使用文檔片段document fragments 通常會(huì)起到優(yōu)化性能的作用(better performance)。

在W3Cschool里說(shuō)過(guò)
DocumentFragment 接口表示文檔的一部分（或一段）。更確切地說(shuō)，它表示一個(gè)或多個(gè)鄰接的 Document 節(jié)點(diǎn)和它們的所有子孫節(jié)點(diǎn)。
DocumentFragment 節(jié)點(diǎn)不屬于文檔樹，繼承的 parentNode 屬性總是 null。
不過(guò)它有一種特殊的行為，該行為使得它非常有用，即當(dāng)請(qǐng)求把一個(gè) DocumentFragment 節(jié)點(diǎn)插入文檔樹時(shí)，插入的不是 DocumentFragment 自身，而是它的所有子孫節(jié)點(diǎn)。這使得 DocumentFragment 成了有用的占位符，暫時(shí)存放那些一次插入文檔的節(jié)點(diǎn)。它還有利于實(shí)現(xiàn)文檔的剪切、復(fù)制和粘貼操作，尤其是與 Range 接口一起使用時(shí)更是如此。
可以用 Document.createDocumentFragment() 方法創(chuàng)建新的空 DocumentFragment 節(jié)點(diǎn)。
也可以用 Range.extractContents() 方法或 Range.cloneContents() 方法獲取包含現(xiàn)有文檔的片段的 DocumentFragment 節(jié)點(diǎn)。

功能強(qiáng)大,兼容良好,看看下圖

中間插播一張圖片，Document 對(duì)象的方法（來(lái)自w3cschool的手冊(cè)）

開(kāi)始之前我們先來(lái)個(gè)例子熱身，告訴大家傳統(tǒng)的插入DOM會(huì)引起什么樣的性能問(wèn)題

var elem = document.createElement("div"),
  p = document.createElement("p");

p.innerHTML = "elem ";
elem.appendChild(p);
document.body.appendChild(elem);

正如大家所知，這種代碼非常糟糕（本身沒(méi)有問(wèn)題），只是每次插入數(shù)據(jù)都會(huì)引起頁(yè)面重繪，如果是在循環(huán)之下短時(shí)間內(nèi)多次重繪頁(yè)面簡(jiǎn)直噩夢(mèng)。相關(guān)知識(shí)有個(gè)大神總結(jié)過(guò)的博非常棒頁(yè)面呈現(xiàn)、重繪、回流,不熟悉這方面的人強(qiáng)烈推薦看幾遍.
這里簡(jiǎn)單概括一下:
回流: 因?yàn)樵氐囊?guī)模尺寸，布局，隱藏等改變而需要重新構(gòu)建。
重繪: 一些元素需要更新屬性只是影響元素的外觀，風(fēng)格，而不會(huì)影響布局。
主流瀏覽器都會(huì)有些減少回流、重繪優(yōu)化方面操作.

下面換成DocumentFragments寫法看看

var oFragment = document.createDocumentFragment(),
  elem = document.createElement("div"),
  p = document.createElement("p");

p.innerHTML = "frag ";
oFragment.appendChild(p);
elem.appendChild(oFragment);
document.body.appendChild(elem);

看起來(lái)變化不多，無(wú)非就是中間生成一個(gè)文檔片段
var oFragment = document.createDocumentFragment();
生成dom先插入文檔片段
oFragment.append(p);
最后一步前先把文檔片段插入將被插入頁(yè)面的父元素
elem.append(oFragment);
實(shí)際上這些寫法我都不怎么常用,估計(jì)大多數(shù)人都愛(ài)用字符串插入,簡(jiǎn)單快捷,代碼量都喜人

var str = "str",
document.body.innerHTML = str;

然后我們實(shí)際測(cè)試一下這三種方法效率到底怎樣?
我們?cè)陧?yè)面放置三個(gè)列表元素,然后分別用三種方法遍歷1000次生成看看;

實(shí)測(cè)數(shù)據(jù)如下:

次數(shù)	Element用時(shí)	Fragment用時(shí)	字符串用時(shí)
1	14.9560546875ms	18.69482421875ms	3.69921875ms
2	15.73388671875ms	17.1826171875ms	4.7451171875ms
3	15.19482421875ms	16.35205078125ms	3.850830078125ms
4	11.967041015625ms	13.6240234375ms	5.048828125ms

可以看到實(shí)際差距大多數(shù)沒(méi)有想象大,有時(shí)候還會(huì)略差,不過(guò)字符串寫法一直穩(wěn)定并且效率最高.
據(jù)說(shuō)createDocumentFragment比直接操作DOM快70%,但是實(shí)踐里沒(méi)看到太明顯的效果,有時(shí)候甚至還不如直接操作,不知道是不是哪里變量因素沒(méi)考慮到,想了挺久,覺(jué)得原因可能是因?yàn)橐晃叶际呛竺嬉淮涡圆迦氲巾?yè)面,實(shí)際測(cè)得都是一次影響DOM的效率,另一個(gè)就是因?yàn)榻Y(jié)構(gòu)簡(jiǎn)單,互相之間不影響布局.基于這種疑點(diǎn)我試試另一個(gè)測(cè)試方法如下

直接生成文本元素然后插入頁(yè)面或者插入DocumentFragment比較,這么看實(shí)際DocumentFragment也就充當(dāng)一個(gè)容器的作用;因?yàn)樽址迦氩荒芤桓哦?去掉異常參考實(shí)測(cè)數(shù)據(jù)如下: