不要再說虛擬 DOM 有多快了

JavaScript 程式設計師 · 發表 2018-11-20 12:03:12

摘要： react 如果你覺得它很快，那麼這篇文章可能就是你所缺少的我經常聽到有人在群裡，或者在社群裡說的一個很嚴重的錯誤，那就是說 React 的 Virtual Dom 是以快出名的，比原生 Dom 快多了，啥啥啥的，每次都一兩句話說不清楚，所以下次有誰再說 React ...

ofollow,noindex" target="_blank">react

如果你覺得它很快，那麼這篇文章可能就是你所缺少的

我經常聽到有人在群裡，或者在社群裡說的一個很嚴重的錯誤，那就是說 React 的 Virtual Dom 是以快出名的，比原生 Dom 快多了，啥啥啥的，每次都一兩句話說不清楚，所以下次有誰再說 React 是以快出名的，你就把這篇文章丟給他，下面進入正題。

在過去的幾年裡，你一直在跟蹤 JavaScript 社群的發展，你至少聽說過 Virtual DOM（React，Vue.js 2，Riot.js，Angular 2等等）。他們承諾（或者更確切地說，他們的宣傳）更快的渲染介面，特別是更新，減少麻煩。你很快的上手了使用虛擬DOM的應用程式，這很好。幾個月後，您的應用程式現在變得越來越複雜，你可能從使用者互動到螢幕更新只需要一兩秒鐘的更新。你可能會想，這東西很神奇，應該會比 jQuery 快，但是實際上不是這個樣子的。

雖然我同意虛擬 DOM 為我們提供了很多便利，但我將解釋為什麼我認為根據定義，更快的渲染和更快的更新是不正確的。要付出代價，其利益並不是大多數人想象或至少希望的。

要閱讀本文，您需要熟悉DOM。理想情況下，您至少可以使用 DOM API。如果你只使用 DOM API 構建東西，你可能不需要這篇文章，但我仍然希望你閱讀它並在評論中留下一點評語。

渲染和更新

讓我們來看看手動執行 DOM 節點的建立和更新的鳥瞰圖。這對於理解虛擬DOM如何工作以及它解決了哪些問題非常重要。

在談論 JavaScript Web 應用程式時，使用者介面的更改通過 DOM 操作發生。這個過程分為兩個階段：

JS 部分：定義 JavaScript 世界中的變化
DOM 部分：使用 DOM API 函式和屬性執行更改

效能是根據整個過程的速度來衡量的，但瞭解每部分的速度也很重要，以便了解要優化的內容。

有兩種方法可以建立和更新DOM樹的各個部分。

①字串方式建立

使用字串既快速又簡單，但在更新方面並不是非常精細。對於字串，JS部分是它如此之快的原因。您可以在幾毫秒內建立一段代表5000個節點的HTML。這是一個例子：

const userList = document.getElementById("user-list");

// JS 部分
const html = users.map(function (user) {
return `
<div id="${user.id}" class=”user”>
<h2 class="header">${user.firstName} ${user.lastName}</h2>
<p class="email"><a href=”mailto:${user.email}”>EMAIL</a></p>
<p class="avg-grade">Average grade: ${user.avgGrade}</p>
<p class="enrolled">Enrolled: ${user.enrolled}</p>
</div>
`
}).join("");

// DOM 部分
userList.innerHTML = html;

我提到使用這種方法時存在侷限性。請考慮以下示例：

const search = document.getElementById("search");
search.innerHTML = `<input class="search" type="text" value="foo">`;
// Change value to "bar"?
search.innerHTML = `<input class="search" type="text" value="bar">`;

雖然看起來上面的內容很簡單，但它實際上並不起作用。當我們執行上面的程式碼時，原始<input> 元素被替換而不是更新，例如，如果使用者有焦點的欄位，他們將失去焦點。

建立和更新 DOM 樹的另一種方法是使用 DOM 物件。就你必須編寫的程式碼而言，這種方法非常冗長，而且總體來說它也慢得多。

讓我們使用這個方法重寫使用者列表示例：

const userList = document.getElementById（“user-list”）;
// JS part 
const = document.createDocumentFragment（）; 
users.forEach（function（user）{ 
const div = document.createElement（“div”）; 
div.id = user.id; 
div.className =“user”; 
const header = document.createElement（“h2”）; 
h2 .className =“header”; 
h2.appendChild（
document.createTextNode（`$ {user.firstName} $ {user.lastName}`）
）; 
// .... 
frag.appendChild（div）; 
}）;
// DOM部分
userList.innerHTML =“”; 
userList.appendChild（FRAG）;

這看起來不太好，但它仍然是建立DOM節點的有效方法。它還有一個優點，即我們能夠將它與第三方庫（如D3）混合使用，以執行 HTML 字串不易處理的事情。在真正的優勢，雖然是執行粒度更新現有的樹時：

const search = document.getElementById（“search”）; 
search.innerHTML =`<input class ="search" type ="text"value ="foo">`; 
//將值更改為“bar”？
search.querySelector（"input"）。value ="bar";

這次我們結合快速方便的字串 HTML 方法來建立初始 UI，然後我們使用 DOM 操作方法來更新 value 屬性。不像我們第一次這樣做，<input> 現在沒有被替換，所以它不會像第一個例子那樣引起 UX 故障。

進入虛擬DOM

讓我們回到輸入示例的第一個版本：

const search = document.getElementById("search");
search.innerHTML = `<input class="search" type="text" value="foo">`;
// Change value to "bar"?
search.innerHTML = `<input class="search" type="text" value="bar">`;

如果我們引數化值部分，它將如下所示：

const search = document.getElementById("search");
const renderInput = function (value) {
search.innerHTML = `<input class="search" type="text" value="${value}">`;
};
renderInput("foo");
// Change value to "bar"?
renderInput("bar");

好吧，新 renderInput() 功能肯定看起來很酷，但我們已經知道這不是好方法。

如果我們有一些騷操作可以讓我們繼續使用類似的東西，但同時弄清楚我們想要做什麼並做正確的事情呢？第二次 renderInput() 被呼叫，我們只更新 value 屬性，所以只更新該屬性而不是重新渲染整個屬性<input> ？

我們說過建立和更新 DOM 樹的整個過程分為兩個階段。使用虛擬 DOM，DOM 階段應該儘可能高效，代價是在 JS 階段完成的額外工作。這項額外的工作會做 diff(不要以為 js 計算就不花費代價)，因此它的另一個名稱將是開銷。根據定義，虛擬 DOM 比精心設計的手動更新慢，但它為我們提供了一個更方便的 API 來建立 UI。

虛擬DOM比精心設計的手動更新慢。

為什麼有些開發人員認為Virtual DOM更快

在虛擬DOM（尤其是React）的早期，傳播了一個神話，即虛擬 DOM 使 DOM 快速更新。正如我們在前面的章節中看到的那樣，這在技術上是不可行的。DOM 更新就是它們的原因，並且沒有任何魔法可以使它更快：它必須在瀏覽器的本機程式碼中進行優化。

可以看到 React 主頁裡面沒有提到效能，而是開發人員的便利性。

React 的基本思維模式是每次有變動就整個重新渲染整個應用。如果沒有 Virtual DOM，簡單來想就是直接重置 innerHTML。很多人都沒有意識到，在一個大型列表所有資料都變了的情況下，重置 innerHTML 其實是一個還算合理的操作... 真正的問題是在 “全部重新渲染” 的思維模式下，即使只有一行資料變了，它也需要重置整個 innerHTML，這時候顯然就有大量的浪費。

您仍然可以看到比較各種虛擬 DOM 實現的基準測試，並且一些措辭會誤導新開發人員認為虛擬 DOM 是當今事實上的標準，並且不值得對其他技術進行基準測試。然而，有一些基準可以將它與其他技術進行比較，例如 Aerotwist 的 React +效能文章，它描繪了虛擬 DOM 在巨集觀方案中所處位置的更真實的畫面。

我們得到了什麼？這值得麼？

虛擬DOM最終是一種執行 DOM 更新的迴圈方式。但是，它打開了通向有趣架構的大門，例如將檢視視為狀態函式，或者編寫和組合檢視元件。虛擬 DOM 帶來了很多好東西，儘管瘋狂的效能水平不是其中之一。您可以將其視為 Python 或 PHP 中的編碼與 C 中的編碼之間的差異。我們以效能為代價獲得更多的開發人員工具。換句話說，這是一種權衡。

另一方面，開發人員的時間丟失也是一些實現方面的事情。虛擬 DOM 試圖弄清楚它需要執行哪些更改的部分是由人類實現的，因此它並不總是萬無一失。有時你必須介入。在某些情況下，無法進行干預。對於絕對效能至關重要的事情，它甚至可能不是一種選擇。

衡量您的表現並根據硬資料來決定。

最重要的是，虛擬DOM只是您可以使用的工具之一。衡量您的表現並根據硬資料來決定。資料繫結仍然非常可行，我們已經看到您也可以手動完成所有操作。它絕對不是萬能的，因此沒有必要與虛擬DOM結合。

結論

React 厲害的地方並不是說它比 DOM 快，而是說不管你資料怎麼變化，我都可以以最小的代價來進行更新 DOM。方法就是我在記憶體裡面用心的資料重新整理一個虛擬 DOM 樹，然後新舊 DOM 進行比較，找出差異，再更新到 DOM 樹上。

這就是所謂的 diff 演算法，雖然說 diff 演算法號稱演算法複雜度 O(n) 可以得到最小操作結果，但實際上 DOM 樹很大的時候，遍歷兩棵樹進行各種對比還是有效能損耗的，特別是我在頂層 setState 一個簡單的資料，你就要整棵樹 walk 一遍，而真實中我可以一句 jQuery 就搞定，所以就有了shouldComponentUpdate 這種東西。

框架的意義在於為你掩蓋底層的 DOM 操作，讓你用更宣告式的方式來描述你的目的，從而讓你的程式碼更容易維護。沒有任何框架可以比純手動的優化 DOM 操作更快，因為框架的 DOM 操作層需要應對任何上層 API 可能產生的操作，它的實現必須是普適的。

針對每一個點，都可以寫出比任何框架更快的手動優化，但是那有什麼意義呢？在構建一個實際應用的時候，你難道為每一個地方都去做手動優化嗎？出於可維護性的考慮，這顯然不可能。框架給你的保證是，你在不需要手動優化的情況下，我依然可以給你提供過得去的效能。

本文由taoweng 創作，採用知識共享署名4.0 國際許可協議進行許可

本站文章除註明轉載/出處外，均為本站原創或翻譯，轉載前請務必署名

最後編輯時間為: Nov 20, 2018 at 12:03 pm