React Native填坑之旅--Diff算法（番外）

使用React或者RN开发APP如果不知道Diff算法的话简直是说不过去啊。毕竟“知其然，知其所以然”这句老话从远古喊到现代了。

以下内容基本是官网文章的一个总结、压缩。这次要谦虚一下，毕竟深入研究RN的时间不多，如果有什么理解的不对的地方还请各位读者指正。

用React官网的Thinking in React作为例子。

这几个组件的结构是这样的：

FilterableProductTable
    SearchBar

    ProductTable
        ProductCategoryRow

        ProductRow

相关代码，省去不必要的以后是这样的：

class ProductCategoryRow extends React.Comonent {
  render() {
    return ({this.props.category});
  }
};

class ProductRow extends React.Component{
  render() {
    return (
      
        {name}
        {this.props.product.price}
      
    );
  }
};

class ProductTable extends React.Component {
  render() {
    return (
      {rows}
    );
  }
};

class SearchBar extends React.Component{
  render() {
    return (
      

        //...略...
      
    );
  }
};

class FilterableProductTable extends React.Component{
  render() {
    return (
      

        
        
      
    );
  }
};
 
ReactDOM.render(
  ,
  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。那就是噩梦一样的情况了。