当 virtual-dom 比手动操作更快时？

Question

我现在正在研究 virtual-dom，我想知道 virtual-dom 是否真的比手动操作视图快。现在我明白了 virtual-dom 和 diff 算法可以防止不必要的重流，例如当我们想要改变它时：

<div>
    <div>a</div>
    <div>b</div>
</div>

对此：

<div>
    <div>c</div>
    <div>d</div>
</div>

因此，当我们使用直接操作时，我们可能会有 4 次重排：2 次用于删除每个 div 并创建新的 div。我们还将对 dom 进行更多操作，因为我们应该创建新元素（也许从 dom 中删除 -> 创建新 dom -> 设置属性 -> 安装到文档比直接编辑 dom 属性更快？）。另一方面，我们有快速漂亮的差异算法，它生成 2 个补丁只是为了替换我们的 div 内容，可能我们会有 1 次重排。（如果我在写re-flows的时候写错了，请告诉我）

在这种情况下，virtual-dom 可能是规则，但是当我们有 2 个真正不同的树时，我们不会从 diff 中获得很多好处，所以我们可能会防止一些重流，但是是时候生成新树并运行 diff 和补丁要长得多。这是我的第二个问题。例如，在https://github.com/Matt-Esch/virtual-dom库的动机中，他们说：“因此，当您的应用程序状态更改时，您只需创建一个虚拟树或 VTree，而不是更新 DOM”。每次当我需要更改视图中的某些内容时，构建一个新的虚拟树真的很好吗？

当然，我会尝试做一些测试来评估性能，但我想知道一些更多的技术方面和原因，为什么 virtual-dom 真的更好，或者，也许不是？

Answer 1

因此，当我们使用直接操作时，我们可能会有 4 次重流：2 次用于删除每个 div 并创建新的 div。

如果您批量处理 DOM 操作，并且不将它们与需要读取布局状态的操作（例如读取计算样式、计算偏移量）交错，那么所有这些操作加在一起只会导致一次回流。

如今浏览器的回流和重绘算法也相当先进，只需调整文档的部分内容，并简单地重新合成移动的图层，如果不改变尺寸，则无需重新绘制它们。

如果您担心性能，您应该使用浏览器的性能分析工具，看看到底是什么拖慢了您的速度，以及在进行过早优化之前是否可以使用本机实用程序对其进行优化。

我认为 virtual dom 更适用于某些情况（例如服务器）发出整页 DOM 树但您只想应用差异的情况。