使用React或者RN开发APP如果不知道Diff算法的话简直是说不过去啊。毕竟“知其然，知其所以然”这句老话从远古喊到现代了。
以下内容基本是官网文章的一个总结、压缩。这次要谦虚一下，毕竟深入研究RN的时间不多，如果有什么理解的不对的地方还请各位读者指正。
用React官网的Thinking in React作为例子。
这几个组件的结构是这样的：
FilterableProductTable
SearchBar
ProductTable
ProductCategoryRow
ProductRow
相关代码，省去不必要的以后是这样的：
class ProductCategoryRow extends React.Comonent {
render() {
return (<tr><th colSpan="2">{this.props.category}</th></tr>);
}
};
class ProductRow extends React.Component{
render() {
return (
<tr>
<td>{name}</td>
<td>{this.props.product.price}</td>
</tr>
);
}
};
class ProductTable extends React.Component {
render() {
return (
<table>
<tbody>{rows}</tbody>
</table>
);
}
};
class SearchBar extends React.Component{
render() {
return (
<form>
//...略...
</form>
);
}
};
class FilterableProductTable extends React.Component{
render() {
return (
<div>
<SearchBar />
<ProductTable products={this.props.products} />
</div>
);
}
};
ReactDOM.render(
<FilterableProductTable products={PRODUCTS} />,
document.getElementById('container')
);
上面的例子说明React的组件最后组成了一个树形结构。在React绘制的时候，会在内存里对应每一个组件建立一个节点，并最终形成一个和组件树结构一样的树。我们就叫这个树叫影子树（这个叫法不是出自官方）。我们可以理解为这个影子树包含了React App组建的结构和一些属性值。
在组件发生变化的时候（一般是调用了setState），React会形成一个影子树二号。然后对比影子树1号和影子树2号的不同。
我们知道对比两个树的最小不同的时间复杂度是O(n3
)，n是树里的节点数。这个复杂度下，稍有量级的应用都会遇到一个问题：无法忽略的慢。于是，FB的同学们使用了更加高效的启发式算法，把复杂度降低到了O(n)。
但是，不管是什么算法最后都需要对比两个节点的不同。有三种情况需要考虑：
一、节点之间的比较
节点，英语里的Node，包括两种类型:一个是React组件，一个是HTML的DOM。下文也是同样的含义。
节点类型不同
如果是HTML DOM不同的话，直接使用新的替换旧的。
如果是组件类型不同的话也直接使用新的替换旧的。
HTML DOM类型相同
在React里样式并不是一个纯粹的字符串，而是一个对象，这样的话在样式发生改变的时候只需要改变替换变化以后的样式。修改完当前节点之后，递归处理该节点的子节点。
组件类型相同
组件类型相同的，使用React机制处理。一般是使用新的props替换掉旧的props，并在之后调用组件的componentWill/DidReceiveProps方法，之前的组件的render方法会被调用。节点的比较机制开始递归作用于这个它的子节点上。
二、两个列表之间的比较
一列节点中的一个发生了改变，React并没有什么好方法来处理这个问题。循环新旧两个列表，并找出不同是React唯一的处理方法。
但是，有一个可以把这个算法的复杂度降低的办法。那就是我们在生成一列节点的时候给每一个节点上添加一个key。这个key只需要在这一列节点中唯一，不需要全局唯一。
三、取舍
需要注意的是，上面的启发式算法是基于两点假设:
*类型想听的节点总是生成同样的树，而类型不同的节点也总是生成不同的树。
*可以为多次render都表现稳定的节点设置key。
上面的节点之间的比较算法基本就是基于这两个假设而实现的。也就是要提高React应用的效率，需要我们按照这两点假设来开发。
否则，React会重获整个APP。那就是噩梦一样的情况了。
网友评论