目前，前端领域中 React 势头正盛，使用者众多却少有能够深入剖析内部实现机制和原理。本系列文章希望通过剖析 React 源码，理解其内部的实现原理，知其然更要知其所以然。
React diff 作为 Virtual DOM 的加速器，其算法上的改进优化是 React 整个界面渲染的基础，以及性能提高的保障，同时也是 React 源码中最神秘、最不可思议的部分，本文从源码入手，深入剖析 React diff 的不可思议之处。
- 阅读本文需要对 React 有一定的了解，如果你不知何为 React，请详读 React 官方文档。
- 如果你对 React diff 存在些许疑惑，或者你对算法优化感兴趣，那么本文值得阅读和讨论。
前言
React 中最值得称道的部分莫过于 Virtual DOM 与 diff 的完美结合，特别是其高效的 diff 算法，让用户可以无需顾忌性能问题而”任性自由”的刷新页面，让开发者也可以无需关心 Virtual DOM 背后的运作原理，因为 React diff 会帮助我们计算出 Virtual DOM 中真正变化的部分，并只针对该部分进行实际 DOM 操作，而非重新渲染整个页面，从而保证了每次操作更新后页面的高效渲染，因此 Virtual DOM 与 diff 是保证 React 性能口碑的幕后推手。
行文至此，可能会有读者质疑：React 无非就是引入 diff 这一概念，且 diff 算法也并非其首创，何必吹嘘的如此天花乱坠呢？
其实，正是因为 diff 算法的普识度高，就更应该认可 React 针对 diff 算法优化所做的努力与贡献，更能体现 React 开发者们的魅力与智慧！
传统 diff 算法
计算一棵树形结构转换成另一棵树形结构的最少操作，是一个复杂且值得研究的问题。传统 diff 算法通过循环递归对节点进行依次对比，效率低下，算法复杂度达到 O(n^3)，其中 n 是树中节点的总数。O(n^3) 到底有多可怕，这意味着如果要展示1000个节点，就要依次执行上十亿次的比较。这种指数型的性能消耗对于前端渲染场景来说代价太高了！现今的 CPU 每秒钟能执行大约30亿条指令，即便是最高效的实现，也不可能在一秒内计算出差异情况。
因此，如果 React 只是单纯的引入 diff 算法而没有任何的优化改进，那么其效率是远远无法满足前端渲染所要求的性能。
通过下面的 demo 可以清晰的描述传统 diff 算法的实现过程。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
let result = []; // 比较叶子节点 const diffLeafs = function(beforeLeaf, afterLeaf) { // 获取较大节点树的长度 let count = Math.max(beforeLeaf.children.length, afterLeaf.children.length); // 循环遍历 for (let i = 0; i < count; i++) { const beforeTag = beforeLeaf.children[i]; const afterTag = afterLeaf.children[i]; // 添加 afterTag 节点 if (beforeTag === undefined) { result.push({type: "add", element: afterTag}); // 删除 beforeTag 节点 } else if (afterTag === undefined) { result.push({type: "remove", element: beforeTag}); // 节点名改变时，删除 beforeTag 节点，添加 afterTag 节点 } else if (beforeTag.tagName !== afterTag.tagName) { result.push({type: "remove", element: beforeTag}); result.push({type: "add", element: afterTag}); // 节点不变而内容改变时，改变节点 } else if (beforeTag.innerHTML !== afterTag.innerHTML) { if (beforeTag.children.length === 0) { result.push({ type: "changed", beforeElement: beforeTag, afterElement: afterTag, html: afterTag.innerHTML }); } else { // 递归比较 diffLeafs(beforeTag, afterTag); } } } return result; } |
因此，如果想要将 diff 思想引入 Virtual DOM，就需要设计一种稳定高效的 diff 算法，而 React 做到了！
那么，React diff 到底是如何实现的呢？
详解 React diff
传统 diff 算法的复杂度为 O(n^3)，显然这是无法满足性能要求的。React 通过制定大胆的策略，将 O(n^3) 复杂度的问题转换成 O(n) 复杂度的问题。
diff 策略
- Web UI 中 DOM 节点跨层级的移动操作特别少，可以忽略不计。
- 拥有相同类的两个组件将会生成相似的树形结构，拥有不同类的两个组件将会生成不同的树形结构。
- 对于同一层级的一组子节点，它们可以通过唯一 id 进行区分。
基于以上三个前提策略，React 分别对 tree diff、component diff 以及 element diff 进行算法优化，事实也证明这三个前提策略是合理且准确的，它保证了整体界面构建的性能。
- tree diff
- component diff
- element diff
本文中源码 ReactMultiChild.js
tree diff
基于策略一，React 对树的算法进行了简洁明了的优化，即对树进行分层比较，两棵树只会对同一层次的节点进行比较。
既然 DOM 节点跨层级的移动操作少到可以忽略不计，针对这一现象，React 通过 updateDepth 对 Virtual DOM 树进行层级控制，只会对相同颜色方框内的 DOM 节点进行比较，即同一个父节点下的所有子节点。当发现节点已经不存在，则该节点及其子节点会被完全删除掉，不会用于进一步的比较。这样只需要对树进行一次遍历，便能完成整个 DOM 树的比较。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
updateChildren: function(nextNestedChildrenElements, transaction, context) { updateDepth++; var errorThrown = true; try { this._updateChildren(nextNestedChildrenElements, transaction, context); errorThrown = false; } finally { updateDepth--; if (!updateDepth) { if (errorThrown) { clearQueue(); } else { processQueue(); } } } } |
分析至此，大部分人可能都存在这样的疑问：如果出现了 以然。
React diff 作为 Virtual DOM 的加速器，其算法上的改进优化是 React 整个界面渲染的基础，以及性能提高的保障，同时也是 React 源码中最神秘、最不可思议的部分，本文从源码入手，深入剖析 React diff 的不可思议之处。
- 阅读本文需要对 React 有一定的了解，如果你不知何为 React，请详读 React 官方文档。
- 如果你对 React diff 存在些许疑惑，或者你对算法优化感兴趣，那么本文值得阅读和讨论。
前言
React 中最值得称道的部分莫过于 Virtual DOM 与 diff 的完美结合，特别是其高效的 diff 算法，让用户可以无需顾忌性能问题而”任性自由”的刷新页面，让开发者也可以无需关心 Virtual DOM 背后的运作原理，因为 React diff 会帮助我们计算出 Virtual DOM 中真正变化的部分，并只针对该部分进行实际 DOM 操作，而非重新渲染整个页面，从而保证了每次操作更新后页面的高效渲染，因此 Virtual DOM 与 diff 是保证 React 性能口碑的幕后推手。
行文至此，可能会有读者质疑：React 无非就是引入 diff 这一概念，且 diff 算法也并非其首创，何必吹嘘的如此天花乱坠呢？
其实，正是因为 diff 算法的普识度高，就更应该认可 React 针对 diff 算法优化所做的努力与贡献，更能体现 React 开发者们的魅力与智慧！
传统 diff 算法
计算一棵树形结构转换成另一棵树形结构的最少操作，是一个复杂且值得研究的问题。传统 diff 算法通过循环递归对节点进行依次对比，效率低下，算法复杂度达到 O(n^3)，其中 n 是树中节点的总数。O(n^3) 到底有多可怕，这意味着如果要展示1000个节点，就要依次执行上十亿次的比较。这种指数型的性能消耗对于前端渲染场景来说代价太高了！现今的 CPU 每秒钟能执行大约30亿条指令，即便是最高效的实现，也不可能在一秒内计算出差异情况。
因此，如果 React 只是单纯的引入 diff 算法而没有任何的优化改进，那么其效率是远远无法满足前端渲染所要求的性能。
通过下面的 demo 可以清晰的描述传统 diff 算法的实现过程。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
let result = []; // 比较叶子节点 const diffLeafs = function(beforeLeaf, afterLeaf) { // 获取较大节点树的长度 let count = Math.max(beforeLeaf.children.length, afterLeaf.children.length); // 循环遍历 for (let i = 0; i < count; i++) { const beforeTag = beforeLeaf.children[i]; const afterTag = afterLeaf.children[i]; // 添加 afterTag 节点 if (beforeTag === undefined) { result.push({type: "add", element: afterTag}); // 删除 beforeTag 节点 } else if (afterTag === undefined) { result.push({type: "remove", element: beforeTag}); // 节点名改变时，删除 beforeTag 节点，添加 afterTag 节点 } else if (beforeTag.tagName !== afterTag.tagName) { result.push({type: "remove", element: beforeTag}); result.push({type: "add", element: afterTag}); // 节点不变而内容改变时，改变节点 } else if (beforeTag.innerHTML !== afterTag.innerHTML) { if (beforeTag.children.length === 0) { result.push({ type: "changed", beforeElement: beforeTag, afterElement: afterTag, html: afterTag.innerHTML }); } else { // 递归比较 diffLeafs(beforeTag, afterTag); } } } return result; } |
因此，如果想要将 diff 思想引入 Virtual DOM，就需要设计一种稳定高效的 diff 算法，而 React 做到了！
那么，React diff 到底是如何实现的呢？
详解 React diff
传统 diff 算法的复杂度为 O(n^3)，显然这是无法满足性能要求的。React 通过制定大胆的策略，将 O(n^3) 复杂度的问题转换成 O(n) 复杂度的问题。
diff 策略
- Web UI 中 DOM 节点跨层级的移动操作特别少，可以忽略不计。
- 拥有相同类的两个组件将会生成相似的树形结构，拥有不同类的两个组件将会生成不同的树形结构。
- 对于同一层级的一组子节点，它们可以通过唯一 id 进行区分。
基于以上三个前提策略，React 分别对 tree diff、component diff 以及 element diff 进行算法优化，事实也证明这三个前提策略是合理且准确的，它保证了整体界面构建的性能。
- tree diff
- component diff
- element diff
本文中源码 ReactMultiChild.js
tree diff
基于策略一，React 对树的算法进行了简洁明了的优化，即对树进行分层比较，两棵树只会对同一层次的节点进行比较。
既然 DOM 节点跨层级的移动操作少到可以忽略不计，针对这一现象，React 通过 updateDepth 对 Virtual DOM 树进行层级控制，只会对相同颜色方框内的 DOM 节点进行比较，即同一个父节点下的所有子节点。当发现节点已经不存在，则该节点及其子节点会被完全删除掉，不会用于进一步的比较。这样只需要对树进行一次遍历，便能完成整个 DOM 树的比较。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
updateChildren: function(nextNestedChildrenElements, transaction, context) { updateDepth++; var errorThrown = true; try { this._updateChildren(nextNestedChildrenElements, transaction, context); errorThrown = false; } finally { updateDepth--; if (!updateDepth) { if (errorThrown) { clearQueue(); } else { processQueue(); } } } } |
