前言

假设你有两棵各有1000个节点的树，传统树对比算法需要十亿级别的操作。那根本不可能用在浏览器里——一更新就死机。老实说，React团队发现，在实际Web应用中。树的变化符合一些规律，于是他们大胆做了3个假设，把复杂度降到了线性。虽然有些场景会误判，但在99%的情况下它准得吓人还快得离谱。

今天我们就来揭开这3个“神级假设”，还有React是怎么基于它们对比DOM的。

一、3个假设：React的“赌注”

1. 同层对比两个不同类型的元素会产生不同的树。比如
   变成 React会直接销毁旧子树。重建新子树，不会浪费时间去比较子节点。老实说，
2. 唯一标识开发者可以通过 key 属性告诉React哪些子元素是稳定的。比如列表顺序变化时有key就能识别“这个li还是那个li”，只是挪了个位置。
3. 同级子节点只在该层比较不会跨层级移动节点。 如果某个节点从子节点变成了父节点的兄弟。React会销毁重建，而不是复用。

假设，React设计出了基于广度优先遍历的Diff算法。

二、节点类型不同：直接“拆房重建”

如果旧树是

新树是 React压根不看子节点。直接删掉旧节点及其所有子节点，重新创建 及子节点。

// 旧


// 新

即使 是一样的。整个组件也会被卸载再重新挂载，Counters's state 会丢失，生命周期重新走一遍。

尽量保持DOM类型稳定，比如别把

随意改成 .

三、同一类型节点：保留DOM。只更新属性和子节点

如果新旧节点类型相同（比如都是

)，React会保留该节点的DOM元素，接下来对比属性，更新改变的属性。接着递归对比子节点，

// 旧：

hello
// 新：

world

React保留 <|vq_image_12552|>- div> 。把 className 从 "" 改为 "'new'",接下来对比文本子节点，把 "'hello'" 改成 "'world'". 这时子节点的对比就进入“列表对比”阶段。

四、列表对比：没有key VS 有key

This is most exciting part of Diff.

再看没有key时，React 的 “暴力”

A - B - C // New : C - A - B If you have a list of elements that are all same type,and order changes but you do not give m keys React can only compare m by position.

// Old: A - B - C // New: C - A - B 

The way React does it:

1. A old vs C new => different,update A to become C.
2. B old vs A new => different,update B to become A.
3. C old vs B new => different,update C to become B.
. The final result is correct but performed three updates. In reality you could move one element and reuse two ors.

说到有key时，移动插入删除三步走

• A = key=A B = key=B C = key=C New order: C= key=C A= key=A B= key=B

。

---