性能优化

    如果你在React应用中遇到性能的瓶颈,请确保你是在生产环境下测试。

    默认地,React包含众多的帮助性的警告(warning)。这些警告在开发模式中非常有用。而然它们使得React体积庞大并性能下降,因此,你需要确保你是在生产模式下部署应用。

    如果你不确定你部署的模式是否正确,你可以在Chrome中安装。如果你访问的网站是React生产模式,图标背景是深色:

    如果你访问的网站是React开发模式,图标的背景将会是红色:

    Optimizing Performance - 图1

    正常情况下,你会在开发过程中使用开发模式,当给用户部署应用使用生产模式。

    如果你的工程使用Create React App,运行:

    这将会在你的工程中目录下创建生产模式的应用。

    记住,这是指针对于部署产品。对于普通的开发者,使用 npm start

    Single-File Builds

    我们提供了生产模式的React和React DOM的文件:

    1. <script src="https://unpkg.com/react@15/dist/react.min.js"></script>
    2. <script src="https://unpkg.com/react-dom@15/dist/react-dom.min.js"></script>

    需要记住的是以.min.js结尾的React文件仅适用于生产模式。

    如果使用的高效地Brunch构建,安装插件:

    1. # 使用npm
    2. npm install --save-dev uglify-js-brunch
    3. # 使用yarn
    4. yarn add --dev uglify-js-brunch

    然后,通过给build命令添加-p来创建生产模式应用。在开发模式下不要传递-p标志或者使用上述插件,因为其隐藏了有用的React警告(warning)并是构建速度降低。

    Browserify

    对于使用的高效地Browserify构建,安装下列插件:

    1. # 使用npm
    2. npm install --save-dev bundle-collapser envify uglify-js uglifyify
    3. # 使用Yarn
    4. yarn add --dev bundle-collapser envify uglify-js uglifyify

    为了创建生产模式的应用,确实你添加了下列的转化规则(顺序很重要):

    • envify确保能设置正确的构建环境。全局安装(-g)。
    • 能移除开发环境引入的文件。全局安装(-g)。
    • bundle-collapser插件可以用数字替换模块ID。
    • 最后,使用压缩打包结果(查看为什么)

    例如:

    1. browserify ./index.js \
    2. -g [ envify --NODE_ENV production ] \
    3. -g uglifyify \
    4. -p bundle-collapser/plugin \
    5. | uglifyjs --compress --mangle > ./bundle.js

    对于使用的高效地Rollupy构建,安装下列插件:

    1. # 如果使用的是npm
    2. npm install --save-dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-uglify
    3. # 如果使用的yarn
    4. yarn add --dev rollup-plugin-commonjs rollup-plugin-replace rollup-plugin-uglify

    为了创建生产模式的应用,确实你添加了下列插件(顺序很重要):

    • 插件确保构建正确的构建环境。
    • commonjs 插件使得Rollup支持CommonJS。
    • 插件压缩最终打包的文件。

    记住你仅需要在生产模式下使用,你不应该在开发模式下使用uglifyreplace插件,因为它隐藏了有用的React警告并使得构建速度变慢。

    Webpack

    注意:

    如果你使用的是Create React App, 查看这个例子.

    这个小节针对于你直接配置Webpack

    对于使用最高效地Rollupy构建,确保在生产配置下添加下面插件:

    1. new webpack.DefinePlugin({
    2. 'process.env': {
    3. NODE_ENV: JSON.stringify('production')
    4. }
    5. }),
    6. new webpack.optimize.UglifyJsPlugin()

    更多的信息可以了解

    记住你仅需要在生产模式下使用。你不应该在开发模式下使用UglifyJsPluginDefinePlugin插件,因为它隐藏了有用的React警告并使得构建速度变慢。

    使用Chrome Timeline分析组件性能

    在开发模式中,你可以在支持相关功能的浏览器中使用性能工具来可视化组件安装(mount),更新(update)和卸载(unmount)的各个过程。例如:

    在Chrome操作如下:

    1. 通过添加?react_perf查询字段加载你的应用(例如:http://localhost:3000/?react_perf)

    2. 执行你想要分析的操作,不要超过20秒,否则Chrome可能会挂起。

    3. 停止记录。

    4. User Timing下,React事件将会分组列出。

    注意,上述数据是相对的,组件会在生产环境中有更好的性能。然而,这对你分析由于错误导致不相关的组件的更新、分析组件更新的深度和频率很有帮助。

    目前Chrome,Edge和IE支持该特性,但是我们使用了标准的 User Timing API,因此我们期待将来会有更多的浏览器支持。

    React创建和维护了渲染UI的内部状态。其包括了组件返回的React元素。这些内部状态使得React只有在必要的情况下才会创建DOM节点和访问存在DOM节点,因为对JavaScript对象的操作是比DOM操作更快。这被称为”虚拟DOM”,React Native也基于上述原理。

    当组件的propsstate更新时,React通过比较新返回的元素和之前渲染的元素来决定是否有必要更新DOM元素。如果二者不相等,则更新DOM元素。

    在部分场景下,组件可以通过重写生命周期函数shouldComponentUpdate来优化性能。shouldComponentUpdate函数会在重新渲染流程前触发。shouldComponentUpdate的默认实现中返回的是true,使得React执行更新操作。

    1. shouldComponentUpdate(nextProps, nextState) {
    2. return true;
    3. }

    如果你的组件在部分场景下不需要更行,你可以在shouldComponentUpdate返回false来跳过整个渲染流程(包括调用render和之后流程)。

    shouldComponentUpdate

    下面有一个组件子树,其中SCU代表shouldComponentUpdate函数返回结果。vDOMEq代表渲染的React元素是否相等。最后,圆圈内的颜色代表组件是否需要reconcile(译者注:reconcile代表React在每次需要渲染时,会先比较当前DOM内容和待渲染内容的差异, 然后再决定如何最优地更新DOM)

    Optimizing Performance - 图2

    对于C1和C3,shouldComponentUpdate返回false,所以React需要向下遍历,对于C6,shouldComponentUpdate返回false,并且需要渲染的元素不相同,因此React需要更新DOM节点。

    最后一个值得注意的例子是C8.React必须渲染这个组件,但是由于返回的React元素与之前渲染的元素相比是相同的,因此不需要更新DOM节点。

    注意,React仅仅需要修改C6的DOM,这是必须的。对于C8来讲,通过比较渲染元素被剔除,对于C2子树和C7,因为shouldComponentUpdate被剔除,甚至都不需要比较React元素,也不会调用render方法。

    仅当props.colorstate.count发生改变时,组件需要更新,你可以通过shouldComponentUpdate函数设置:

    1. class CounterButton extends React.Component {
    2. constructor(props) {
    3. super(props);
    4. this.state = {count: 1};
    5. }
    6. shouldComponentUpdate(nextProps, nextState) {
    7. if (this.props.color !== nextProps.color) {
    8. return true;
    9. }
    10. if (this.state.count !== nextState.count) {
    11. return true;
    12. }
    13. return false;
    14. }
    15. render() {
    16. return (
    17. <button
    18. color={this.props.color}
    19. onClick={() => this.setState(state => ({count: state.count + 1}))}>
    20. Count: {this.state.count}
    21. </button>
    22. );
    23. }
    24. }

    在上面的代码中,shouldComponentUpdate函数仅仅检查props.color 或者 state.count是否发生改变。如果这些值没有发生变化,则组件不会进行更新。如果你的组件更复杂,你可以使用类似于对propsstate的所有属性进行”浅比较”这种模式来决定组件是否需要更新。这种模式非常普遍,因此React提供了一个helper实现上面的逻辑:继承React.PureComponent。因此,下面的代码是一种更简单的方式实现了相同的功能:

    1. class CounterButton extends React.PureComponent {
    2. constructor(props) {
    3. super(props);
    4. this.state = {count: 1};
    5. }
    6. render() {
    7. return (
    8. <button
    9. color={this.props.color}
    10. onClick={() => this.setState(state => ({count: state.count + 1}))}>
    11. Count: {this.state.count}
    12. </button>
    13. );
    14. }
    15. }

    大多数情况下,你可以使用React.PureComponent而不是自己编写shouldComponentUpdate。但React.PureComponent仅会进项浅比较,因此如果在props和state会突变(译者注:就是引用不发生变化,但指向的内容发生变化)导致浅比较失败的情况下就不能使用React.PureComponent

    如果props和state属性存在更复杂的数据结构,这可能是一个问题。例如,我们编写一个ListOfWords组件展现一个以逗号分隔的单词列表,在父组件WordAdder,当你点击一个按钮时会给列表添加一个单词。下面的代码是不正确的:

    1. class ListOfWords extends React.PureComponent {
    2. }
    3. }
    4. class WordAdder extends React.Component {
    5. constructor(props) {
    6. super(props);
    7. this.state = {
    8. words: ['marklar']
    9. };
    10. this.handleClick = this.handleClick.bind(this);
    11. }
    12. handleClick() {
    13. // This section is bad style and causes a bug
    14. const words = this.state.words;
    15. words.push('marklar');
    16. this.setState({words: words});
    17. }
    18. render() {
    19. return (
    20. <div>
    21. <button onClick={this.handleClick} />
    22. <ListOfWords words={this.state.words} />
    23. </div>
    24. );
    25. }
    26. }

    问题是PureComponent只进行在旧的this.props.words与新的this.props.words之间进行前比较。因此在WordAdder组件中handleClick的代码会突变words数组。虽然数组中实际的值发生了变化,但旧的this.props.words和新的this.props.words值是相同的,即使ListOfWords需要渲染新的值,但是还是不会进行更新。

    不可变数据的力量

    避免这类问题最简单的方法是不要突变(mutate)props和state的值。例如,上述handleClick方法可以通过使用concat重写:

    ES6对于数组支持 ,使得解决上述问题更加简单。如果你使用的是Create React App,默认支持该语法。

    1. handleClick() {
    2. this.setState(prevState => ({
    3. words: [...prevState.words, 'marklar'],
    4. }));
    5. };

    你可以以一种简单的方式重写上述代码,使得改变对象的同时不会突变对象,例如,如果有一个colormap的对象并且编写一个函数将colormap.right的值改为blue

    1. function updateColorMap(colormap) {
    2. colormap.right = 'blue';
    3. }

    在不突变原来的对象的条件下实现上面的要求,我们可以使用Object.assign方法:

    1. function updateColorMap(colormap) {
    2. return Object.assign({}, colormap, {right: 'blue'});
    3. }

    updateColorMap方法返回一个新的对象,而不是修改原来的对象。Object.assign属于ES6语法,需要polyfill。

    JavaScript提案添加了,能够更简单地更新对象而不突变对象。

    1. function updateColorMap(colormap) {
    2. return {...colormap, right: 'blue'};
    3. }

    如果你使用的是Create React App,Object.assign和对象展开符默认都是可用的。

    Immutable.js 是解决上述问题的另外一个方法,其提供了通过结构共享实现(Structural Sharing)地不可变的(Immutable)、持久的(Persistent)集合:

    • 不可变(Immutable): 一个集合一旦创建,在其他时间是不可更改的。
    • 持久的(Persistent): 新的集合可以基于之前的结合创建并产生突变,例如:set。原来的集合在新集合创建之后仍然是可用的。
    • 结构共享(Structural Sharing): 新的集合尽可能通过之前集合相同的结构创建,最小程度地减少复制操作来提高性能。

    不可变性使得追踪改变非常容易。改变会产生新的对象,因此我们仅需要检查对象的引用是否改变。例如,下面是普通的JavaScript代码:

    1. const x = { foo: 'bar' };
    2. const y = x;
    3. y.foo = 'baz';

    虽然y被编辑了,但是因为引用的是相同的对象x,所以比较返回true

    在这个例子中,因为当改变x时返回新的引用,我们可以确信地判定被改变了。

    其他两个可以帮助我们使用不可变数据的库分别是:和immutability-helper.