React 应用的性能优化之路

本文讲的是React 应用的性能优化之路，

要点梗概

React 应用主要的性能问题在于多余的处理和组件的 DOM 比对。为了避免这些性能陷阱，你应该尽可能的在shouldComponentUpdate 中返回 false 。

简而言之，归结于如下两点：

  1. 加速 shouldComponentUpdate 的检查
  2. 简化 shouldComponentUpdate 的检查

免责声明！

文章中的示例是用 React + Redux 写的。如果你用的是其它的数据流库，原理是相通的但是实现会不同。

在文章中我没有使用 immutability (不可变)库，只是一些普通的 es6 和一点 es7。有些东西用不可变数据库要简单一点，但是我不准备在这里讨论这一部分内容。

React 应用的主要性能问题是什么？

  1. 组件中那些不更新 DOM 的冗余操作
  2. DOM 比对那些无须更新的叶子节点
    • 虽则 DOM 比对很出色并加速了 React ，但计算成本是不容忽视的

React 默认的渲染行为是怎样的？

我们来看一下 React 是如何渲染组件的。

初始化渲染

在初始化渲染时，我们需要渲染整个应用
（绿色 ＝ 已渲染节点）

每一个节点都被渲染 —— 这很赞！现在我们的应用呈现了我们的初始状态。

提出改变

我们想更新一部分数据。这些改变只和一个叶子节点相关

理想更新

我们只想渲染通向叶子节点的关键路径上的这几个节点

默认行为

如果你不告诉 React 别这样做，它便会如此
（橘黄色 ＝ 浪费的渲染）

哦，不！我们所有的节点都被重新渲染了。

React 的每一个组件都有一个 shouldComponentUpdate(nextProps, nextState) 函数。它的职责是当组件需要更新时返回true ， 而组件不必更新时则返回 false 。返回 false 会导致组件的 render 函数不被调用。React 总是默认在shouldComponentUpdate 中返回 true，即便你没有显示地定义一个 shouldComponentUpdate 函数。

// 默认行为
shouldComponentUpdate(nextProps, nextState) {
    return true;
}

这就意味着在默认情况下，你每次更新你的顶层级的 props，整个应用的每一个组件都会渲染。这是一个主要的性能问题。

我们如何获得理想的更新？

尽可能的在 shouldComponentUpdate 中返回 false 。

简而言之：

  1. 加速 shouldComponentUpdate 的检查
  2. 简化 shouldComponentUpdate 的检查

加速 shouldComponentUpdate 检查

理想情况下我们不希望在 shouldComponentUpdate 中做深等检查，因为这非常昂贵，尤其是在大规模和拥有大的数据结构的时候。

class Item extends React.component {
    shouldComponentUpdate(nextProps) {
      // 这很昂贵
      return isDeepEqual(this.props, nextProps);
    }
    // ...
}

一个替代方法是_只要对象的值发生了变化，就改变对象的引用_。

const newValue = {
    ...oldValue
    // 在这里做你想要的修改
};

// 快速检查 —— 只要检查引用
newValue === oldValue; // false

// 如果你愿意也可以用 Object.assign 语法
const newValue2 = Object.assign({}, oldValue);

newValue2 === oldValue; // false

在 Redux reducer 中使用这个技巧：

// 在这个 Redux reducer 中，我们将改变一个 item 的 description
export default (state, action) {

    if(action.type === 'ITEM_DESCRIPTION_UPDATE') {

        const { itemId, description } = action;

        const items = state.items.map(item => {
            // action 和这个 item 无关 —— 我们可以不作修改直接返回这个 item
            if(item.id !== itemId) {
              return item;
            }

            // 我们想改变这个 item
            // 这会保留原本 item 的值，但
            // 会返回一个更新过 description 的新对象
            return {
              ...item,
              description
            };
        });

        return {
          ...state,
          items
        };
    }

    return state;
}

如果你采用这个方法，那你只需在 shouldComponentUpdate 函数中作引用检查

// 超级快 —— 你所做的只是检查引用！
shouldComponentUpdate(nextProps) {
    return isObjectEqual(this.props, nextProps);
}

isObjectEqual 的一个实现示例

const isObjectEqual = (obj1, obj2) => {
    if(!isObject(obj1) || !isObject(obj2)) {
        return false;
    }

    // 引用是否相同
    if(obj1 === obj2) {
        return true;
    }

    // 它们包含的键名是否一致？
    const item1Keys = Object.keys(obj1).sort();
    const item2Keys = Object.keys(obj2).sort();

    if(!isArrayEqual(item1Keys, item2Keys)) {
        return false;
    }

    // 属性所对应的每一个对象是否具有相同的引用？
    return item2Keys.every(key => {
        const value = obj1[key];
        const nextValue = obj2[key];

        if(value === nextValue) {
            return true;
        }

        // 数组例外，再检查一个层级的深度
        return Array.isArray(value) &&
            Array.isArray(nextValue) &&
            isArrayEqual(value, nextValue);
    });
};

const isArrayEqual = (array1 = [], array2 = []) => {
    if(array1 === array2) {
        return true;
    }

    // 检查一个层级深度
    return array1.length === array2.length &&
        array1.every((item, index) => item === array2[index]);
};

简化 shouldComponentUpdate 检查

先看一个_复杂_的 shouldComponentUpdate 示例

// 关注分离的数据结构（标准化数据）
const state = {
    items: [
        {
            id: 5,
            description: 'some really cool item'
        }
    ]

    // 表示用户与系统交互的对象
    interaction: {
        selectedId: 5
    }
};

如果这样组织你的数据，会使得在 shouldComponentUpdate 中进行检查变得_困难_

import React, { Component, PropTypes } from 'react'

class List extends Component {

    propTypes = {
        items: PropTypes.array.isRequired,
        iteraction: PropTypes.object.isRequired
    }

    shouldComponentUpdate (nextProps) {
        // items 中的元素是否发生了改变？
        if(!isArrayEqual(this.props.items, nextProps.items)) {
            return true;
        }

        // 从这里开始事情会变的很恐怖

        // 如果 interaction 没有变化，那可以返回 false （真棒！）
        if(isObjectEqual(this.props.interaction, nextProps.interaction)) {
            return false;
        }

        // 如果代码运行到这里，我们知道：
        //    1. items 没有变化
        //    2. interaction 变了
        // 我们需要 interaction 的变化是否与我们相干

        const wasItemSelected = this.props.items.any(item => {
            return item.id === this.props.interaction.selectedId
        })
        const isItemSelected = nextProps.items.any(item => {
            return item.id === nextProps.interaction.selectedId
        })

        // 如果发生了改变就返回 true
        // 如果没有发生变化就返回 false
        return wasItemSelected !== isItemSelected;
    }

    render() {
        <div>
            {this.props.items.map(item => {
                const isSelected = this.props.interaction.selectedId === item.id;
                return (<Item item={item} isSelected={isSelected} />);
            })}
        </div>
    }
}

问题1：shouldComponentUpdate 体积庞大

你可以看出一个非常简单的数据对应的 shouldComponentUpdate 即庞大又复杂。这是因为它需要知道数据的结构以及它们之间的关联。shouldComponentUpdate 函数的复杂度和体积只随着你的数据结构增长。这_很容易_导致两点错误：

  1. 在不应该返回 false 的时候返回 false（应用显示错误的状态）
  2. 在不应该返回 true 的时候返回 true（引发性能问题）

为什么要让事情变得这么复杂？你只想让这些检查变得简单一点，以至于你根本就不必考虑它们。

问题2：父子级之间强耦合

通常而言，应用都要推广松耦合（组件对其它的组件知道的越少越好）。父组件应该尽量避免知晓其子组件的工作原理。这就允许你改变子组件的行为而无须让父级知晓这些变化（假设 PropsTypes 保持不变）。它还允许子组件独立运转，而不必让父级紧密的控制其行为。

解决办法：压平你的数据

通过压平（合并）你的数据结构，你可以重新使用非常简单的引用检查来看是否有什么发生了变化。

const state = {
    items: [
        {
            id: 5,
            description: 'some really cool item',

            // interaction 现在存在于 item 的内部
            interaction: {
                isSelected: true
            }
        }
    }
};

这样组织你的数据使得在 shouldComponentUpdate 中做检查变得_简单_

import React, {Component, PropTypes} from 'react'

class List extends Component {

    propTypes = {
        items: PropTypes.array.isRequired
    }

    shouldComponentUpdate(nextProps) {
        // so easy，麻麻再也不用担心我的更新检查了
        return isObjectEqual(this.props, nextProps);
    }

    render() {
        <div>
            {this.props.items.map(item => {

                return (
                <Item item={item}
                    isSelected={item.interaction.isSelected} />)
            })}
        </div>
    }
}

如果你想要更新 interaction 你就改变整个对象的引用

// redux reducer
export default (state, action) => {

    if(action.type === 'ITEM_SELECT') {

        const { itemId } = action;

        const items = state.items.map(item => {
            if(item.id !== itemId) {
                return item;
            }

            // 改变整个对象的引用
            return {
                ...item,
                interaction: {
                    isSelected: true
                }
            }
        })

        return {
            ...state,
            items
        };
    }

    return state;
};

误区：引用检查与动态 props

一个创建动态 props 的例子

class Foo extends React.Component {
    render() {
        const {items} = this.props;

        // 这个对象每次都有一个新的引用
        const newData = { hello: 'world' };

        return <Item name={name} data={newData} />
    }
}

class Item extends React.Component {

    // 即便前后两个对象的值相同，检查也总会返回true，因为 `data` 每次都会得到一个新的引用
    shouldComponentUpdate(nextProps) {
        return isObjectEqual(this.props, nextProps);
    }
}

通常我们不会在组件中创建一个新的 props 把它传下来 。但是，这在循环中更为常见

class List exntends React.Component {
    render() {
        const {items} = this.props;

        <div>
            {items.map((item, index) => {
                // 这个对象每次都会获得一个新引用
                const newData = {
                    hello: 'world',
                    isFirst: index === 0
                };

                return <Item name={name} data={newData} />
            })}
        </div>
    }
}

这在创建函数时很常见

import myActionCreator from './my-action-creator';

class List extends React.Component {
    render() {
        const {items, dispatch} = this.props;

        <div>
            {items.map(item => {
                // 这个函数的引用每次都会变
                const callback = () => {
                    dispatch(myActionCreator(item));
                }

                return <Item name={name} onUpdate={callback} />
            })}
        </div>
    }
}

解决问题的策略

  1. 避免在组件中创建动态的 props

改善你的数据模型，这样你就可以直接把 props 传下来

  1. 把动态 props 转化成满足全等（===）的类型传下来

eg:

  • boolean
  • number
  • string

const bool1 = true;
const bool2 = true;

bool1 === bool2; // true

const string1 = 'hello';
const string2 = 'hello';

string1 === string2; // true

如果你实在需要传递动态对象，那就把它当作字符串传下来，再在子级进行解构

render() {
    const {items} = this.props;

    <div>
        {items.map(item => {
            // 每次获得新引用
            const bad = {
                id: item.id,
                type: item.type
            };

            // 相同的值可以满足严格的全等 '==='
            const good = `${item.id}::${item.type}`;

            return <Item identifier={good} />
        })}
    </div>
}

特殊情况：函数

  1. 如果可以的话，尽量避免传递函数。相反，让子组件自由的 dispatch 动作。这还有个附加的好处就是把业务逻辑移出组件。
  2. 在 shouldComponetUpdate 中忽略函数检查。这样不是很理想，因我们不知道函数的值是否变化了。
  3. 创建一个 data -> function 的不可变绑定。你可以在 componentWillReceiveProps 函数中把它们存到 state 中去。这样就不会在每一次 render 时拿到新的引用。这个方法极度笨重，因为你须要维护和更新一个函数列表。
  4. 创建一个拥有正确 this 绑定的中间组件。这也不够理想，因为你在层级中引入了一个冗余层。
  5. 任何其它你能够想到的、能够避免每次 render 调用时创建一个新函数的方法。

方案4 的示例

// 引入另外一层 'ListItem'
<List>
    <ListItem> // 你可以在这里创建正确的 this 绑定
        <Item />
    </ListItem>
</List>

class ListItem extends React.Component {

    // 这样总能得到正确的 this 绑定，因为它绑定在了实例上
    // 感谢 es7！
    const callback = () => {
        dispatch(doSomething());
    }

    render() {
        return <Item callback={this.callback} item={this.props.item} />
    }
}

工具

以上列出来的所有规则和技巧都是通过使用性能测量工具发现的。使用工具可以帮助你发现你的应用的具体性能问题所在。

console.time

这一个相当简单：

  1. 开始一个计时器
  2. 做点什么
  3. 停止计时器

一个比较好的做法是使用 Redux 中间件：

export default store => next => action => {
    console.time(action.type)

    // `next` 是一个函数，它接收 'action' 并把它发送到 ‘reducers' 进行处理
    // 这会导致你应有的一次重渲
    const result = next(action);

    // 渲染用了多久？
    console.timeEnd(action.type);

    return result;
};

用这个方法可以记录你应用的每一个 action 和它引起的渲染所花费的时间。你可以快速知道哪些 action 渲染时间最长，这样当你解决性能问题时就可以从那里着手。拿到时间值还能帮助你判断你所做的性能优化是否奏效了。

React.perf

这个工具的思路和 console.time 是一致的，只不过用的是 React 的性能工具：

  1. Perf.start()
  2. do stuff
  3. Perf.stop()

Redux 中间件示例：

import Perf from 'react-addons-perf';

export default store => next => action => {
    const key = `performance:${action.type}`;
    Perf.start();

    // 拿到新的 state 重渲应用
    const result = next(action);
    Perf.stop();

    console.group(key);
    console.info('wasted');
    Perf.printWasted();
    // 你可以在这里打印任何你感兴趣的 Perf 测量值

    console.groupEnd(key);
    return result;
};

与 console.time 方法类似，它能让你看到你每一个 action 的性能指标。更多关于 React 性能 addon 的信息请点击这里

浏览器工具

CPU 分析器火焰图表在寻找你的应用程序的性能问题时也能发挥作用。

在做性能分析时，火焰图表会展示出每一毫秒你的代码的 Javascript 堆栈的状态。在记录的时候，你就可以确切地知道任意时间点执行的是哪一个函数，它执行了多久，又是谁调用了它。—— Mozilla






原文发布时间为：2016年06月09日


本文来自合作伙伴掘金，了解相关信息可以关注掘金网站。

时间： 2024-11-18 14:47:28

React 应用的性能优化之路的相关文章

Web前端性能 优化进阶路

简单的说,我们的性能优化实践分为三个阶段:初探期.立规期.创新期, 每个阶段大概持续半年左右,有足够的时间形成一些优化思路的沉淀. 一:初探期2010年底我们开始接手搜索List页面,这是中文站历史最为悠久的页面之一,当时它的生命体征正如它的年龄一样,非常虚弱:当时的基调网络监控显示,页面的完全加载的时间是16秒!作为以"快"为核心业务指标的搜索页面,这个状态显然已是无法承担重任了.性能是一定要优化的,但我们也面临着大多数前端同学所面临的共性问题 - 业务需求紧张,况且我们是 刚刚接手

MySQL性能优化之路---修改配置文件my.cnf_Mysql

在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分.对于Discuz!论坛程序也是如此,MySQL的设置是否合理优化,直接影响到论坛的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验进行判断,然后设置合理的参数. 下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分,一是服务器物理硬件的优化,二是MySQL自身(my.cnf)的优化. 一.服务

丰趣海淘：跨境电商平台的前端性能优化实践

原文出自[听云技术博客]:http://blog.tingyun.com/web/article/detail/586 随着互联网的发展,尤其是在2000年之后浏览器技术渐渐成熟,Web产品也越来越丰富,这时我们被浏览器窗口内的丰富"内容"所吸引,关注HTML/CSS,深入研究Dom.Bom和浏览器的渲染机制等,接触JavaScript库,"前端"这个职业,由此而生. 前端技术在这10多年中飞速发展,到了今天,我们可能发现"内容"的美在视觉上是有

LAMP服务器性能优化技巧之Apache服务器优化_Linux

1.Zend Performance Suite简介 对于Apache要把 PHP 编译其中,或者采用 DSO (动态共享对象)模式,不要采用 CGI 方式.采用DSO最重要的原因是效率.Apache是模块化设计的,所以它可以加载各种各样的服务器端脚本解释器来支持动态的网页.但是随着页面访问量的增大,CGI已经不看重负,为了提高效率.所以选择把最常调用的模块编译成动态共享对象(DSO).zend出品的ZendPerformanceSuite,这是一个Apache服务器的性能测试和优化的工具.可以

LAMP服务器性能优化技巧之加速PHP_Linux

Apache服务器优化.PHP优化.Mysql优化 1.使用eaccelerator 我们上面的介绍Apache服务器的优化,如果您曾经浏览过 PHP 的网页时,或许会发现:怎么 PHP 的速度慢慢的,这是怎么一回事啊?PHP 不是号称速度上面的反应是很快速的吗?怎么会慢慢的呢?这是由于 PHP 的程序代码去调用了太多的函式库,而这些函式库每次调用都需要由硬盘读出来,有没有办法提升 PHP 的执行速度啊.如果我们可以将这些在硬盘里面的函式库先读到高速缓存中( Cache ),由于内存的速度可比硬

如何利用工具提高 React 页面渲染性能之 Perf

前言 用 React 一段时间了,也做了不少列表页.在用 React 做无限下拉加载的列表页时发现个问题:页面前几页渲染速度还挺快的,但是越往下拉加载内容页面的渲染就越慢.这是怎么回事呢?让我们先来看下 React 的组件渲染流程吧. React 的组件渲染流程 React 的组件渲染分为初始化渲染和更新渲染.在初始化时,React 会调用根组件下所有组件的 render 方法进行渲染. 在每个生命周期更新时,React 会先调用 shouldComponentUpdate(nextProps,

LAMP服务器性能优化技巧之Linux主机优化_Linux

目前LAMP (Linux + Apache + MySQL + PHP) 近几年来发展迅速,已经成为Web 服务器的事实标准. LAMP这个词的由来最早始于德国杂志"c't Magazine",Michael Kunze在1990年最先把这些项目组合在一起创造了LAMP的缩写字.这些组件虽然并不是开开始就设计为一起使用的,但是,这些开源软件都可以很方便的随时获得并免费获得.这就导致了这些组件经常在一起使用.在过去的几年里,这些组件的兼容性不断完善,在一起的应用情形变得非常普便.为了改

阿里高级数据库专家何登成：AliSQL性能优化与功能突破的演进之路

首届阿里巴巴在线技术峰会(Alibaba Online Technology Summit),将于7月19日-21日 20:00-21:30 在线举办.本次峰会邀请到阿里集团9位技术大V,分享电商架构.安全.数据处理.数据库.多应用部署.互动技术.Docker持续交付与微服务等一线实战经验,解读最新技术在阿里集团的应用实践. 本次峰会全部开放,免费注册,3天夜间技术交流.每场1.5小时深度分享.长时间互动答疑.素材第一时间公开.用户组同步搭建, 我们希望搭建起业内开发者与阿里技术专家在线交流分享

从小站到大站的技术架构优化之路－网站架构与前端服务性能优化

一.课程目的 2015年,5月的某天,正在上班,突然看线公司群里开始发出携程网访问500的信息,于是乎,大家小扯的一下,大家并没有想到后来发生的事情的事情会如此震惊,开始官方的微博确认问题为,正遭受攻击,但后来内部的技术人员泄漏出"数据库被物理删除!" 这个对于技术的人员来说,可以说是非常惊讶的消息,大家开始了各种疑问,怎么确定是数据库引起,作为一个大公司怎么会有这种问题产生,数据库作为底层核心,为什么恢复机制是那么薄弱. 陆续消息中,最后传出,由于运维人员的类似于自动化系统操作不当,