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。那就是噩梦一样的情况了。

你可能感兴趣的:(javascript,数据结构与算法,ViewUI)