React 性能优化大挑战：一次理解 Immutable data跟shouldComponentUpdate

作者： TechBridge Weekly/huli

https://blog.techbridge.cc/2018/01/05/react-render-optimization/

前阵子正在重构公司的专案，试了一些东西之后发现自己对于 React 的渲染机制其实不太了解，不太知道 render 什么时候会被触发。而后来我发现不只我这样，其实还有满多人对这整个机制不太熟悉，因此决定写这篇来分享自己的心得。其实不知道怎么优化倒还好，更惨的事情是你自以为在优化，其实却在拖慢效能，而根本的原因就是对 React 的整个机制还不够熟。被「优化」过的 component 反而还变慢了！这个就严重了。因此，这篇文章会涵盖到下面几个主题：

Component 跟 PureComponent 的差异

shouldComponentUpdate 的作用

React 的渲染机制

为什么要用 Immutable data structures

为了判别你到底对以上这些理解多少，我们马上进行几个小测验！有些有陷阱，请睁大眼睛看清楚啦！

React 小测验

第一题

以下程式码是个很简单的网页，就一个按钮跟一个叫做Content的元件而已，而按钮按下去之后会改变App这个 component 的 state。

classContentextendsReact.Component{

render(){

console.log('render content!');

return

Content

}

}

classAppextendsReact.Component{

handleClick=()=>{

this.setState({

a:1

})

}

render(){

console.log('render App!');

return(

setState

);

}

}

ReactDOM.render(

document.getElementById('container')

);

请问：当你按下按钮之后，console 会输出什么？

A. 什么都没有（App 跟 Content 的 render function 都没被执行到）

B. 只有 render App!（只有 App 的 render function 被执行到）

C. render App! 以及 render content!（两者的 render function 都被执行到）

第二题

以下程式码也很简单，分成三个元件：App、Table 跟 Row，由 App 传递 list 给 Table，Table 再用 map 把每一个 Row 都渲染出来。

classRowextendsComponent{

render(){

const{item,style}=this.props;

return(

{item.id}

)

}

}

classTableextendsComponent{

render(){

const{list}=this.props;

constitemStyle={

color:'red'

}

return(

{list.map(item=> )}

)

}

}

classAppextendsComponent{

state={

list:Array(10000).fill().map((val,index)=>({id:index}))

}

handleClick=()=>{

this.setState({

otherState:1

})

}

render(){

const{list}=this.state;

return(

changestate!

);

}

}

而这段程式码的问题就在于按下按钮之后，App的 render function 被触发，然后Table的 render function 也被触发，所以重新渲染了一次整个列表。

可是呢，我们点击按钮之后，list根本没变，其实是不需要重新渲染的，所以聪明的小明把 Table 从 Component 变成 PureComponent，只要 state 跟 props 没变就不会重新渲染，变成下面这样：

classTableextendsPureComponent{

render(){

const{list}=this.props;

constitemStyle={

color:'red'

}

return(

{list.map(item=> )}

)

}

}

// 不知道什么是 PureComponent 的朋友，可以想成他自己帮你加了下面的 function

shouldComponentUpdate(nextProps,nextState){

return!shallowEqual(this.props,nextProps)|| !shallowEqual(this.state,nextState)

}

把 Table 从 Component 换成 PureComponent 之后，如果我们再做一次同样的操作，也就是按下change state按钮改变 App 的 state，这时候会提升效率吗？

A. 会，在这情况下 PureComponent 会比 Component 有效率

B. 不会，两者差不多

C. 不会，在这情况下 Component 会比 PureComponent 有效率

第三题

接著让我来看一个跟上一题很像的例子，只是这次换成按按钮以后会改变 list：

classRowextendsComponent{

render(){

const{item,style}=this.props;

return(

{item.id}

)

}

}

classTableextendsPureComponent{

render(){

const{list}=this.props;

constitemStyle={

color:'red'

}

return(

{list.map(item=> )}

)

}

}

classAppextendsComponent{

state={

list:Array(10000).fill().map((val,index)=>({id:index}))

}

handleClick=()=>{

this.setState({

list:[...this.state.list,1234567]// 增加一个元素

})

}

render(){

const{list}=this.state;

return(

changestate!

);

}

}

这时候 Table 的 PureComponent 优化已经没有用了，因为 list 已经变了，所以会触发 render function。要继续优化的话，比较常用的手段是把 Row 变成 PureComponent，这样就可以确保相同的 Row 不会再次渲染。

classRowextendsPureComponent{

render(){

const{item,style}=this.props;

return(

{item.id}

)

}

}

classTableextendsPureComponent{

render(){

const{list}=this.props;

constitemStyle={

color:'red'

}

return(

{list.map(item=> )}

)

}

}

请问：把 Row 从 Component 换成 PureComponent 之后，如果我们再做一次同样的操作，也就是按下change state按钮改变 list，这时候会提升效率吗？

A. 会，在这情况下 PureComponent 会比 Component 有效率

B. 不会，两者差不多

C. 不会，在这情况下 Component 会比 PureComponent 有效率

React 的 render 机制

在公布答案之前，先帮大家简单複习一下 React 是如何把你的画面渲染出来的。

首先，大家都知道你在render这个 function 裡面可以回传你想渲染的东西，例如说

classContentextendsReact.Component{

render(){

return

Content

}

}

要注意的是这边 return 的东西不会直接就放到 DOM 上面去，而是会先经过一层 virtual DOM。其实你可以简单把这个 virtual DOM 想成 JavaScript 的物件，例如说上面 Content render 出来的结果可能是：

{

tagName:'div',

children:'Content'

}

最后一步则是 React 进行 virtual DOM diff，把上次的跟这次的做比较，并且把变动的部分更新到真的 DOM 上面去。

简单来说呢，就是在 React Component 以及 DOM 之间新增了一层 virtual DOM，先把你要渲染的东西转成 virtual DOM，再把需要更新的东西 update 到真的 DOM 上面去。

如此一来，就能够减少触碰到真的 DOM 的次数并且提升性能。

举个例子，假设我们实作一个非常简单的，按一个按钮之后就会改变 state 的小范例：

classContentextendsReact.Component{

render(){

}

}

classAppextendsReact.Component{

state={

text:'hello'

}

handleClick=()=>{

this.setState({

text:'world'

})

}

render(){

return(

setState

);

}

}

在程式刚开始执行时，渲染的顺序是这样的：

呼叫 App 的 render

呼叫 Content 的 render

拿到 virtual DOM

跟上次的 virtual DOM 做比较

把改变的地方应用到真的 DOM

这时候的 virtual DOM 整体应该会长得像这样：

{

tagName:'div',

children:[

{

tagName:'button',

children:'setState'

},{

tagName:'div',

children:'hello'

}

]

}

当你按下按钮，改变 state 了以后，执行顺序都跟刚刚一样：

呼叫 App 的 render

呼叫 Content 的 render

拿到 virtual DOM

这时候拿到的 virtual DOM 应该会长得像这样：

{

tagName:'div',

children:[

{

tagName:'button',

children:'setState'

},{

tagName:'div',

children:'world'// 只有这边变了

}

]

}

而 React 的 virtual DOM diff 演算法，就会发现只有一个地方改变，然后把那边的文字替换掉，其他部分都不会动到。

其实官方文件把这一段写得很好：

When you use React, at a single point in time you can think of the render() function as creating a tree of React elements. On the next state or props update, that render() function will return a different tree of React elements. React then needs to figure out how to efficiently update the UI to match the most recent tree.

大意就是你可以想像成 render function 会回传一个 React elements 的 tree，然后 React 会把这次的 tree 跟上次的做比较，并且找出如何有效率地把这差异 update 到 UI 上面去。

所以说呢，如果你要成功更新画面，你必须经过两个步骤：

render function

virtual DOM diff

因此，要优化效能的话你有两个方向，那就是：

不要触发 render function

保持 virtual DOM 的一致

我们先从后者开始吧！

提升 React 效能：保持 virtual DOM 的一致

因为有了 virtual DOM 这一层的守护，通常你不必太担心 React 的效能。

像是我们开头问答的第一题：

classContentextendsReact.Component{

render(){

console.log('render content!');

return

Content

}

}

classAppextendsReact.Component{

handleClick=()=>{

this.setState({

a:1

})

}

render(){

console.log('render App!');

return(

setState

);

}

}

ReactDOM.render(

document.getElementById('container')

);

你每次按下按钮之后，由于 App 的 state 改变了，所以会先触发 App 的 render function，而因为裡面有回传，所以也会触发 Content 的 render function。

因此你每按一次按钮，这两个 component 的 render function 就会个别被呼叫一次。所以答案是C. render App! 以及 render content!（两者的 render function 都被执行到）

可是尽管如此，真的 DOM 不会有任何变化。因为在 virtual DOM diff 的时候，React 会发现你这次跟上次的 virtual DOM 长得一模一样（因为没有东西改变嘛），就不会对 DOM 做任何操作。

如果能尽量维持 virtual DOM 的结构相似的话，可以减少一些不必要的操作，在这点上其实可以做的优化还很多，可以参考官方文件，裡面写的很详细。

提升 React 效能：不要触发 render function

虽然不必太过担心，但是 virtual DOM diff 也是需要执行时间的。虽然说速度很快，但再快也比不上完全不呼叫来的快，你说是吧。

对于这种「我们已经明确知道不该有变化」的情形，我们连 render 都不该呼叫，因为没必要嘛，再怎么呼叫都是一样的结果。如果 render 没有被呼叫的话，连 virtual DOM diff 都不需要执行，又提升了一些性能。

你应该有听过shouldComponentUpdate这个 function，就是来做这件事的。如果你在这个 function 中回传 false，就不会重新呼叫 render function。

classContentextendsReact.Component{

shouldComponentUpdate(){

returnfalse;

}

render(){

console.log('render content!');

return

Content

}

}

classAppextendsReact.Component{

handleClick=()=>{

this.setState({

a:1

})

}

render(){

console.log('render App!');

return(

setState

);

}

}

加上去之后，你会发现无论你按多次按钮，Content 的 render function 都不会被触发。

但是这个东西请小心使用，一个不注意你就会碰到 state 跟 UI 搭不上的情形，例如说 state 明明变成 world，可是 UI 显示的还是 Hello：

classContentextendsReact.Component{

shouldComponentUpdate(){

returnfalse;

}

render(){

}

}

classAppextendsReact.Component{

state={

text:'hello'

}

handleClick=()=>{

this.setState({

text:'world'

})

}

render(){

return(

setState

);

}

}

在上面的例子中，按下按钮之后 state 确实变成world，但是因为 Content 的shouldComponentUpdate永远都回传 false，所以不会再次触发 render，就看不到对应的新的 state 的画面了。

不过这有点极端，因为通常不会永远都回传 false，除非你真的确定这个 component 完全不需要 re-render。

比起这个，有一个更合理的判断基准是：

如果每一个 props 跟 state 都没有变，那就回传 false

classContentextendsReact.Component{

shouldComponentUpdate(nextProps,nextState){

return!shallowEqual(this.props,nextProps)|| !shallowEqual(this.state,nextState);

}

render(){

}

}

假设this.props是：

{

text:'hello'

}

而nextProps是：

{

text:'world'

}

那在比较的时候就会发现props.text变了，就可以顺理成章的呼叫 render function。还有另外一点是这边用shallowEqual来比较前后的差异，而不是用deepEqual。

这是出于效能上的考量。别忘了，你要执行这样的比较也是会吃资源的，尤其是在你的 object 很深很深的时候，要比较的东西可就多了，因此我们会倾向用shallowEqual，只要比较一层即可。

另外，前面有提到PureComponent这个东西，其实就是 React 提供的另外一种元件，差别就是在于它自动帮你加上上面那一段的比较。如果你想看原始码的话，在这边：

return(

!shallowEqual(oldProps,newProps)|| !shallowEqual(oldState,newState)

);

}

讲到这边，就可以来公佈第二题的解答了，答案是：A. 会，在这情况下 PureComponent 会比 Component 有效率，因为继承了 PureComponent 之后，只要 props 跟 state 没变，就不会执行 render function，也不会执行 virtual DOM diff，节省了许多开销。

shallowEqual 与 Immutable data structures

你刚开始在学 React 的时候，可能会被告诫说如果要更改资料，不能够这样写：

// 不能这样

newObject.id=2;

this.setState({

obj:newObject

})

// 也不能这样

arr.push(123);

this.setState({

list:arr

})

而是应该要这样：

this.setState({

obj:{

id:2

}

})

this.setState({

})

但你知道为什么吗？

这个就跟我们上面讲到的东西有关了。如同上面所述，其实使用PureComponent是一件很正常的事情，因为 state 跟 props 如果没变的话，本来就不该触发 render function。

而刚刚也提过PureComponent会帮你shallowEqual state 跟 props，决定要不要呼叫 render function。

在这种情况下，如果你用了一开始讲的那种写法，就会产生问题，例如说：

newObject.id=2;

this.setState({

obj:newObject

})

在这时候，我们就需要 Immutable data，Immutable 翻成中文就是永远不变的，意思就是：「当一个资料被创建之后，就永远不会变了」。那如果我需要更改资料的话怎么办呢？你就只能创一个新的。

constobj={

id:1,

text:'hello'

}

obj.text='world'// 这样不行，因为你改变了 obj 这个物件

// 你必须要像这样创造一个新的物件

constnewObj={

...obj,

text:'world'

}

有了 Immutable 的概念之后，shallowEqual就不会出错了，因为如果我们有新的资料，就可以保证它是一个新的 object，这也是为什么我们在用setState的时候总是要产生一个新的物件，而不是直接对现有的做操作。

/没有Immutable的概念前

constprops={

id:1,

list:[1,2,3]

}

constlist=props.list;

list.push(4)

nextProps={

...props,

list

}

props.list===nextProps.list// true

// 有了 Immutable 的概念后

constprops={

id:1,

list:[1,2,3]

}

constnextProps={

...props,

list:[...props.list,4]

}

props.list===nextProps.list// false

PureComponent 的陷阱

当我们遵守 Immutable 的规则之后，理所当然的就会想把所有的 Component 都设成 PureComponent，因为 PureComponent 的预设很合理嘛，资料没变的话就不呼叫 render function，可以节省很多不必要的比较。

那让我们回头来看开场小测验的最后一题：

classRowextendsPureComponent{

render(){

const{item,style}=this.props;

return(

{item.id}

)

}

}

classTableextendsPureComponent{

render(){

const{list}=this.props;

constitemStyle={

color:'red'

}

return(

{list.map(item=> )}

)

}

}

我们把Row变成了 PureComponent，所以只要 state 跟 props 没变，就不会 re-render，所以答案应该要是A. 会，在这情况下 PureComponent 会比 Component 有效率？

错，如果你把程式码看更清楚一点，你会发现答案其实是C. 不会，在这情况下 Component 会比 PureComponent 有效率。

你的前提是对的，「只要 state 跟 props 没变，就不会 re-render，PureComponent 就会比 Component 更有效率」。但其实还有另外一句话也是对的：「如果你的 state 或 props 『永远都会变』，那 PureComponent 并不会比较快」。

所以这两种的使用时机差异在于：state 跟 props 到底常常会变还是不会变？

上述的例子中，陷阱在于itemStyle这个 props，我们每次 render 的时候都创建了一个新的物件，所以对 Row 来说，儘管 props.item 是一样的，但是 props.style 却是「每次都不一样」。

如果你已经知道每次都会不一样，那 PureComponent 这时候就无用武之地了，而且还更糟。为什么？因为它帮你做了shallowEqual。

别忘记了，shallowEqual也是需要执行时间的。

已经知道 props 的比较每次都失败的话，那不如不要比还会来的比较快，所以在这个情形下，Component 会比 PureComponent 有效率，因为不用做shallowEqual。

这就是我开头提到的需要特别注意的部分。不要以为你把每个 Component 都换成 PureComponent 就天下太平，App 变超快，效能提升好几倍。不去注意这些细节的话，就有可能把效能越弄越糟。

最后再强调一次，如果你已经预期到某个 component 的 props 或是 state 会「很频繁变动」，那你根本不用换成 PureComponent，因为你实作之后反而会变得更慢。

总结

在研究这些效能相关的问题时，我最推荐这篇：React, Inline Functions, and Performance，解开了很多我心中的疑惑以及带给我很多新的想法。

例如说文末提到的 PureComponent 有时候反而会变慢，也是从这篇文章看来的，真心推荐大家抽空去看看。

前阵子跟同事一起把一个专案打掉重做，原本的共识是尽量用 PureComponent，直到我看到这篇文并且仔细思考了一下，发现如果你不知道背后的原理，还是不要轻易使用比较好。因此我就提议改成全部用 Component，等我们碰到效能问题要来优化时再慢慢调整。

最后附上一句我很喜欢的话，从React 巢状 Component 效能优化这篇看来的（这篇也是在讲最后提到的 PureComponent 的问题）：

虽然你知道可以优化，但不代表你应该优化。

参考资料：

High Performance React: 3 New Tools to Speed Up Your Apps

reactjs – Reconciliation

reactjs- Optimizing Performance

React is Slow, React is Fast: Optimizing React Apps in Practice

Efficient React Components: A Guide to Optimizing React Performance

觉得本文对你有帮助？请分享给更多人

关注「前端大全」，提升前端技能