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

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

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180111B0TSTW00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动