0

我正在使用 ag-grid-react 的 SPA React (15.6) 应用程序上使用 Chrome 开发人员工具进行一些性能分析，并且在将分析器的输出与现实相协调时有点麻烦。例如，在下面的屏幕截图中，连接的抽屉组件 (Connect(Drawer), 橙色条) “componentWillReceiveProps” 方法似乎需要大约 2 秒，但其下方没有任何内容。在查看了该方法本身可能需要这么长时间的代码后，我持怀疑态度，因此我在函数内的所有代码周围添加了一些“console.time”语句，并且低看：

抽屉组件WillReceiveProps：0.02001953125ms

这是我的 componentWillReceiveProps 的样子，供参考：

componentWillReceiveProps(nextProps) {
        console.time('Drawer componentWillReceiveProps');
        if (nextProps.changes.length !== this.props.changes.length &&
            nextProps.changes.length === 0 &&
            this.state.isDiscarding) {
            this.setState({isDiscarding: false});
        }
        console.timeEnd('Drawer componentWillReceiveProps');
    }

那么我在这里错过了什么？我（有点）明白用户计时 api 只显示标记的东西（我今天才刚刚学习这个，所以我对那个 api 的理解至少可以说......），所以它只是如果 React 实际上没有计时 componentWillReceiveProps 内部发生的事情？如果它有用，我正在使用重新选择和 Redux，但我会假设我的选择器在调用 componentWillReceiveProps 之前已经运行，但也许我错了？

无论如何，我认为 Chrome 火焰图有一些我不了解的基本内容，但我已经阅读了很多文章，但对我来说并没有加起来。

更新：添加了 componentWillReceiveProps 实现

反应铬配置文件

更新 2：添加指向 Chrome 配置文件的链接

如果有人有兴趣查看这里的实际配置文件链接，您可以通过打开 Chrome 开发工具，转到性能选项卡，然后单击“加载配置文件”来查看它：

https://www.dropbox.com/s/72e9kwyxr0myec3/delete_react_perf_user_timing?dl=0

更新 3：componentWillReceiveProps 解释

好的，所以看起来 componentWillReceiveProps 确实（以某种方式）最终调用了 mapStateToProps，这可以解释为什么它看起来在配置文件中花费了这么长时间。我猜测 componentWillReceiveProps 调用会被 redux connect 方法或类似的方法取代以完成它的工作，但我还没有验证 请参阅已接受的答案。无论如何，您可以在以下屏幕截图中看到这方面的证据：

componentWillReceiveProps 调用堆栈

4

1 回答 1

1

如果您仔细查看火焰图，是Connect(Drawer).componentWillReceiveProps调用需要很长时间，而不是 Drawer 组件本身，这就解释了为什么我在 Drawer 组件中的时序代码显示的时序与火焰图完全不同。该Connect(Drawer)组件是一个高阶组件，其全部目的是调用 mapStateToProps 和 mapDispatchToProps 将状态和动作创建者映射到组件上的道具。在这种情况下，我的mapStateToProps调用速度非常慢，这解释了图表中的结果。

附带说明一下，如果 react-redux 添加用户计时 API 以便 mapStateToProps 调用等会显示在火焰图中，那就太好了。

TL;DR请密切注意火焰图中的实际组件名称。

于 2018-07-12T12:19:49.373 回答