React 性能：使用 PureRenderMixin 渲染大列表

Question

我举了一个 TodoList 示例来反映我的问题，但显然我的实际代码更复杂。

我有一些这样的伪代码。

var Todo = React.createClass({
  mixins: [PureRenderMixin], 
  ............ 
}

var TodosContainer = React.createClass({
  mixins: [PureRenderMixin],    

  renderTodo: function(todo) {
     return <Todo key={todo.id} todoData={todo} x={this.props.x} y={this.props.y} .../>;
  },

  render: function() {
     var todos = this.props.todos.map(this.renderTodo)
     return (
          <ReactCSSTransitionGroup transitionName="transition-todo">
                 {todos}
          </ReactCSSTransitionGroup>,
     );
  }

});

我所有的数据都是不可变的，PureRenderMixin 使用得当，一切正常。修改 Todo 数据时，仅重新渲染父级和已编辑的 todo。

问题是，有时我的列表会随着用户滚动而变大。而当单个 Todo 更新时，渲染父级需要越来越多的时间，在所有的 todo 上调用 shouldComponentUpdate，然后再渲染单个 todo。

如您所见，Todo 组件除了 Todo 数据之外还有其他组件。这是所有 todos 渲染所需的数据并且是共享的（例如，我们可以想象 todos 有一个“displayMode”）。拥有许多属性会使shouldComponentUpdate 的执行速度稍慢一些。

此外，使用ReactCSSTransitionGroup 似乎也慢了一点，因为ReactCSSTransitionGroup 必须呈现自己，ReactCSSTransitionGroupChild 甚至在调用 todos 的shouldComponentUpdate 之前。 React.addons.Perf 表明 ReactCSSTransitionGroup > ReactCSSTransitionGroupChild 渲染对于列表的每个项目都是浪费时间。

所以，据我所知，我使用PureRenderMixin，但如果列表更大，这可能还不够。我的表现仍然没有那么差，但想知道是否有简单的方法来优化我的渲染。

有什么想法吗？

---

编辑：

到目前为止，我的大列表是分页的，所以我现在将这个大列表拆分为一个页面列表，而不是一个大列表。这允许有更好的性能，因为每个页面现在都可以实现shouldComponentUpdate。现在当页面中的 item 发生变化时，React 只需要调用在页面上迭代的主渲染函数，并且只从单个页面调用渲染函数，这样可以大大减少迭代工作。

但是，我的渲染性能仍然与我拥有的页码 (O(n)) 成线性关系。因此，如果我有数千页，它仍然是同一个问题 :) 在我的用例中不太可能发生，但我仍然对更好的解决方案感兴趣。

我很确定可以通过将大列表拆分为树（如持久数据结构）来实现 O(log(n)) 渲染性能，其中 n 是项目（或页面）的数量，并且其中每个节点都有权使用shouldComponentUpdate 短路计算

是的，我正在考虑类似于持久数据结构的东西，例如 Scala 或 Clojure 中的 Vector：

但是我担心 React，因为据我所知，在渲染树的内部节点时，它可能必须创建中间 dom 节点。根据用例，这可能是一个问题（and may be solved in future versions of React）

此外，由于我们使用的是 Javascript，我想知道 Immutable-JS 是否支持这一点，并使“内部节点”可访问。见：https://github.com/facebook/immutable-js/issues/541

编辑：我的实验的有用链接：Can a React-Redux app really scale as well as, say Backbone? Even with reselect. On mobile

Answer 1

在我们的产品中，我们还遇到了与渲染代码量相关的问题，我们开始使用 observables（参见 blog）。这可能会部分解决您的问题，因为更改 todo 将不再需要重新渲染包含列表的父组件（但添加仍然需要）。

它还可以帮助您更快地重新渲染列表，因为当 props 在 shouldComponentUpdate 上发生更改时，您的 todoItem 组件可能只会返回 false。

为了在渲染概览时进一步提高性能，我认为您的树/分页想法确实不错。使用 observable 数组，每个页面都可以开始监听特定范围内的数组拼接（使用 ES7 polyfill 或 mobservable）。这会引入一些管理，因为这些范围可能会随着时间而改变，但应该会让你达到 O(log(n))

所以你会得到类似的东西：

var TodosContainer = React.createClass({
  componentDidMount() {
     this.props.todos.observe(function(change) {
         if (change.type === 'splice' && change.index >= this.props.startRange && change.index < this.props.endRange)
             this.forceUpdate();
     });
  },    

  renderTodo: function(todo) {
     return <Todo key={todo.id} todoData={todo} x={this.props.x} y={this.props.y} .../>;
  },

  render: function() {
     var todos = this.props.todos.slice(this.props.startRange, this.props.endRange).map(this.renderTodo)
     return (
          <ReactCSSTransitionGroup transitionName="transition-todo">
                 {todos}
          </ReactCSSTransitionGroup>,
     );
  }

});

大型列表和反应的核心问题似乎是您不能将新的 DOM 节点转移到 dom 中。否则，您根本不需要“页面”来将数据划分为更小的块，您只需将一个新的 Todo 项拼接到 dom 中，就像在 jsFiddle 中使用 JQuery 所做的那样。如果您为每个待办事项使用ref，您仍然可以通过 react 来做到这一点，但我认为这将在系统周围工作，因为它可能会破坏协调系统？

Answer 2

这是我用 ImmutableJS 内部结构完成的 POC 实现。这不是一个公共 API，因此它还没有准备好投入生产，目前不处理极端情况，但它可以工作。

var ImmutableListRenderer = React.createClass({
  render: function() {
    // Should not require to use wrapper <span> here but impossible for now
    return (<span>
        {this.props.list._root ? <GnRenderer gn={this.props.list._root}/> : undefined}
        {this.props.list._tail ? <GnRenderer gn={this.props.list._tail}/> : undefined}
</span>);
  }   
})

// "Gn" is the equivalent of the "internal node" of the persistent data structure schema of the question
var GnRenderer = React.createClass({
    shouldComponentUpdate: function(nextProps) {
      console.debug("should update?",(nextProps.gn !== this.props.gn));
      return (nextProps.gn !== this.props.gn);
    },
    propTypes: {
        gn: React.PropTypes.object.isRequired,
    },
    render: function() {
        // Should not require to use wrapper <span> here but impossible for now
        return (
            <span>
                {this.props.gn.array.map(function(gnItem,index) { 
                    // TODO should check for Gn instead, because list items can be objects too...
                    var isGn = typeof gnItem === "object"
                    if ( isGn ) {
                        return <GnRenderer gn={gnItem}/>
                    } else {
                        // TODO should be able to customize the item rendering from outside
                        return <span>{" -> " + gnItem}</span>
                    }
                }.bind(this))}
            </span>
        );
    }
})

客户端代码如下

React.render(
    <ImmutableListRenderer list={ImmutableList}/>, 
    document.getElementById('container')
);

这是一个JsFiddle，它记录更新列表的单个元素（大小为N）后shouldComponentUpdate的调用次数：这不需要调用N次shouldComponentUpdate

更多实现细节分享在ImmutableJs github issue

Answer 3

最近我在尝试渲染一个包含 500 多条记录的表时遇到了性能瓶颈，reducers 是不可变的，我正在使用 reselect 来记忆复杂的选择器，在拉了一些头发之后，我发现问题已经解决了记忆所有选择器。