React性能優化-虛擬Dom原理淺析

本文譯自《Optimizing React: Virtual DOM explained》,做者是Alexey IvanovAndy Barnov,來自Evil Martians’ team團隊。javascript

譯者說:經過一些實際場景和demo,給你們描述React的Virtual Dom Diff一些核心的原理和規則,以及基於這些咱們能夠作些什麼提升應用的性能,很棒的文章。html


經過學習React的Virtual DOM的知識,去加速大家的應用吧。對框架內部實現的介紹,比較全面且適合初學者,咱們會讓JSX更加簡單易懂,給你展現React是如何判斷要不要從新render,解釋如何找到應用的性能瓶頸,以及給你們一些小貼士,如何避免常見錯誤。前端

React在前端圈內保持領先的緣由之一,由於它的學習曲線很是平易近人:把你的模板包在JSX,瞭解一下propsstate的概念以後,你就能夠輕鬆寫出React代碼了。java

若是你已經熟悉React的工做方式,能夠直接跳至「優化個人代碼」篇。node

但要真正掌握React,你須要像React同樣思考(think in React)。本文也會試圖在這個方面幫助你。react

下面看看咱們其中一個項目中的React table:git

"eBay上的一個巨大的React表格  用於業務。"

這個表裏有數百個動態(表格內容變化)和可過濾的選項,理解這個框架更精細的點,對於保證順暢的用戶體驗相當重要。github


當事情出錯時,你必定能感受到。輸入字段變得遲緩,複選框須要檢查一秒鐘,彈窗一個世紀後纔出現,等等。算法


爲了可以解決這些問題,咱們須要完成一個React組件的整個生命旅程,從一開始的聲明定義到在頁面上渲染(再而後可能會更新)。繫好安全帶,咱們要發車了!chrome

JSX的背後

這個過程通常在前端會稱爲「轉譯」,但其實「彙編」將是一個更精確的術語。

React開發人員敦促你在編寫組件時使用一種稱爲JSX的語法,混合了HTML和JavaScript。但瀏覽器對JSX及其語法毫無頭緒,瀏覽器只能理解純碎的JavaScript,因此JSX必須轉換成JavaScript。這裏是一個div的JSX代碼,它有一個class name和一些內容:

<div className='cn'>
  Content!
</div>

以上的代碼,被轉換成「正經」的JavaScript代碼,實際上是一個帶有一些參數的函數調用:

React.createElement(
  'div',
  { className: 'cn' },
  'Content!'
);

讓咱們仔細看看這些參數。

  • 第一個是元素的type。對於HTML標籤,它將是一個帶有標籤名稱的字符串。
  • 第二個參數是一個包含全部元素屬性(attributes)的對象。若是沒有,它也能夠是空的對象。
  • 剩下的參數均可以認爲是元素的子元素(children)。元素中的文本也算做一個child,是個字符串'Content!' 做爲函數調用的第三個參數放置。

你應該能夠想象,當咱們有更多的children時會發生什麼:

<div className='cn'>
  Content 1!
  <br />
  Content 2!
</div>
React.createElement(
  'div',
  { className: 'cn' },
  'Content 1!',              // 1st child
  React.createElement('br'), // 2nd child
  'Content 2!'               // 3rd child
)

咱們的函數如今有五個參數:

  • 一個元素的類型
  • 一個屬性對象
  • 三個子元素。

由於其中一個child是一個React已知的HTML標籤(<br/>),因此它也會被描述爲一個函數調用(React.createElement('br'))。

到目前爲止,咱們已經涵蓋了兩種類型的children:

  • 簡單的String
  • 另外一種會調用React.createElement

然而,還有其餘值能夠做爲參數:

  • 基本類型 false, null, undefined, true
  • 數組
  • React Components

可使用數組是由於能夠將children分組並做爲一個參數傳遞:

React.createElement(
  'div',
  { className: 'cn' },
  ['Content 1!', React.createElement('br'), 'Content 2!']
)

固然了,React的厲害之處,不只僅由於咱們能夠把HTML標籤直接放在JSX中使用,而是咱們能夠自定義本身的組件,例如:

function Table({ rows }) {
  return (
    <table>
      {rows.map(row => (
        <tr key={row.id}>
          <td>{row.title}</td>
        </tr>
      ))}
    </table>
  );
}

組件可讓咱們把模板分解爲多個可重用的塊。在上面的「函數式」(functional)組件的例子裏,咱們接收一個包含表格行數據的對象數組,最後返回一個調用React.createElement方法的<table>元素,rows則做爲children傳進table。

不管何時,咱們這樣去聲明一個組件時:

<Table rows={rows} />

從瀏覽器的角度來看,咱們是這麼寫的:

React.createElement(Table, { rows: rows });

注意,此次咱們的第一個參數不是String描述的HTML標籤,而是一個引用,指向咱們編寫組件時編寫的函數。組件的attributes如今是接收的props參數了。

把組件(components)組合成頁面(a page)

因此,咱們已經將全部JSX組件轉換爲純JavaScript,如今咱們有一大堆函數調用,它的參數會被其餘函數調用的,或者還有更多的其餘函數調用這些參數......這些帶參數的函數調用,是怎麼轉化成組成這個頁面的實體DOM的呢?

爲此,咱們有一個ReactDOM庫及其它的render方法:

function Table({ rows }) { /* ... */ } // defining a component

// rendering a component
ReactDOM.render(
  React.createElement(Table, { rows: rows }), // "creating" a component
  document.getElementById('#root') // inserting it on a page
);

ReactDOM.render被調用時,React.createElement最終也會被調用,返回如下對象:

// There are more fields, but these are most important to us
{
  type: Table,
  props: {
    rows: rows
  },
  // ...
}

這些對象,在React的角度上,構成了虛擬DOM。


他們將在全部進一步的渲染中相互比較,並最終轉化爲 真正的DOM(virtual VS real, 虛擬DOM VS 真實DOM)。

下面是另外一個例子:此次div有一個class屬性和幾個children:

React.createElement(
  'div',
  { className: 'cn' },
  'Content 1!',
  'Content 2!',
);

變成:

{
  type: 'div',
  props: {
    className: 'cn',
    children: [
      'Content 1!',
      'Content 2!'
    ]
  }
}

須要注意的是,那些除了typeattribute之外的屬性,本來是單獨傳進來的,轉換以後,會做爲在props.children以一個數組的形式打包存在。也就是說,不管children是做爲數組仍是參數列表傳遞都不要緊 —— 在生成的虛擬DOM對象的時候,它們最後都會被打包在一塊兒的。

進一步說,咱們能夠直接在組件中把children做爲一項屬性傳進去,結果仍是同樣的:

<div className='cn' children={['Content 1!', 'Content 2!']} />

在構建虛擬DOM對象完成以後,ReactDOM.render將會按下面的原則,嘗試將其轉換爲瀏覽器能夠識別和展現的DOM節點:

  • 若是type包含一個帶有String類型的標籤名稱(tag name)—— 建立一個標籤,附帶上props下全部attributes
  • 若是type是一個函數(function)或者類(class),調用它,並對結果遞歸地重複這個過程。
  • 若是props下有children屬性 —— 在父節點下,針對每一個child重複以上過程。

最後,獲得如下HTML(對於咱們的表格示例):

<table>
  <tr>
    <td>Title</td>
  </tr>
  ...
</table>

從新構建DOM(Rebuilding the DOM)

在實際應用場景,render一般在根節點調用一次,後續的更新會有state來控制和觸發調用。

請注意,標題中的「從新」!當咱們想更新一個頁面而不是所有替換時,React中的魔法就開始了。咱們有一些實現它的方式。咱們先從最簡單的開始 —— 在同一個node節點再次執行ReactDOM.render

// Second call
ReactDOM.render(
  React.createElement(Table, { rows: rows }),
  document.getElementById('#root')
);

這一次,上面的代碼的表現,跟咱們已經看到的有所不一樣。React將啓動其diff算法,而不是從頭開始建立全部DOM節點並將其放在頁面上,來肯定節點樹的哪些部分必須更新,哪些能夠保持不變。

那麼,它是怎樣工做的呢?其實只有少數幾個簡單的場景,理解它們將對咱們的優化幫助很大。請記住,如今咱們在看的,是在React Virtual DOM裏面用來表明節點的對象

場景1:type是一個字符串,type在通話中保持不變,props也沒有改變。

// before update
{ type: 'div', props: { className: 'cn' } }

// after update
{ type: 'div', props: { className: 'cn' } }

這是最簡單的狀況:DOM保持不變。

場景2:type仍然是相同的字符串,props是不一樣的。

// before update:
{ type: 'div', props: { className: 'cn' } }

// after update:
{ type: 'div', props: { className: 'cnn' } }

type仍然表明HTML元素,React知道如何經過標準DOM API調用來更改元素的屬性,而無需從DOM樹中刪除一個節點。

場景3:type已更改成不一樣的String或從String組件。

// before update:
{ type: 'div', props: { className: 'cn' } }

// after update:
{ type: 'span', props: { className: 'cn' } }

React看到的type是不一樣的,它甚至不會嘗試更新咱們的節點:old元素將和它的全部子節點一塊兒被刪除(unmounted卸載)。所以,將元素替換爲徹底不一樣於DOM樹的東西代價會很是昂貴。幸運的是,這在現實世界中不多發生。

劃重點,記住React使用===(triple equals)來比較type的值,因此這兩個值須要是相同類或相同函數的相同實例。

下一個場景更加有趣,一般咱們會這麼使用React。

場景4:type是一個component

// before update:
{ type: Table, props: { rows: rows } }

// after update:
{ type: Table, props: { rows: rows } }

你可能會說,「咦,但沒有任何變化啊!」,可是你錯了。


若是type是對函數或類的引用(即常規的React組件),而且咱們啓動了tree diff的過程,則React會持續地去檢查組件的內部邏輯,以確保render返回的值不會改變(相似對反作用的預防措施)。對樹中的每一個組件進行遍歷和掃描 —— 是的,在複雜的渲染場景下,成本可能會很是昂貴!

值得注意的是,一個componentrender(只有類組件在聲明時有這個函數)跟ReactDom.render不是同一個函數。

關注子組件(children)的狀況

除了上述四種常見場景以外,當一個元素有多個子元素時,咱們還須要考慮React的行爲。如今假設咱們有這麼一個元素:

// ...
props: {
  children: [
      { type: 'div' },
      { type: 'span' },
      { type: 'br' }
  ]
},
// ...

咱們想要交換一下這些children的順序:

// ...
props: {
  children: [
    { type: 'span' },
    { type: 'div' },
    { type: 'br' }
  ]
},
// ...

以後會發生什麼呢?

diffing的時候,若是React在檢查props.children下的數組時,按順序去對比數組內元素的話:index 0將與index 0進行比較,index 1和index 1,等等。對於每一次對比,React會使用以前提過的diff規則。在咱們的例子裏,它認爲div成爲一個span,那麼就會運用到情景3。這樣不是頗有效率的:想象一下,咱們已經從1000行中刪除了第一行。React將不得不「更新」剩餘的999個子項,由於按index去對比的話,內容從第一條開始就不相同了。

幸運的是,React有一個內置的方法(built-in)來解決這個問題。若是一個元素有一個key屬性,那麼元素將按key而不是index來比較。只要key是惟一的,React就會移動元素,而不是將它們從DOM樹中移除而後再將它們放回(這個過程在React裏叫mounting和unmounting)。

// ...
props: {
  children: [ // Now React will look on key, not index
    { type: 'div', key: 'div' },
    { type: 'span', key: 'span' },
    { type: 'br', key: 'bt' }
  ]
},
// ...

當state發生了改變

到目前爲止,咱們只聊了下React哲學裏面的props部分,卻忽視了另外很重要的一部分state。下面是一個簡單的stateful組件:

class App extends Component {
  state = { counter: 0 }

  increment = () => this.setState({
    counter: this.state.counter + 1,
  })

  render = () => (<button onClick={this.increment}>
    {'Counter: ' + this.state.counter}
  </button>)
}

state對象裏,咱們有一個keycounter。點擊按鈕時,這個值會增長,而後按鈕的文本也會發生相應的改變。可是,當咱們這樣作時,DOM中發生了什麼?哪部分將被從新計算和更新?

調用this.setState會致使re-render(從新渲染),但不會影響到整個頁面,而只會影響組件自己及其children組件。父母和兄弟姐妹都不會受到影響。當咱們有一個層級很深的組件鏈時,這會讓狀態更新變得很是方便,由於咱們只須要重繪(redraw)它的一部分。

把問題說清楚

咱們準備了一個小demo,以便你能夠在看到在「野蠻生長」的React編碼方式下最多見的問題,後續我也告訴你們怎麼去解決這些問題。你能夠在這裏看看它的源代碼。你還須要React Developer Tools,請確保瀏覽器安裝了它們。

咱們首先要看看的是,哪些元素以及何時致使Virtual DOM的更新。在瀏覽器的開發工具中,打開React面板並選擇「Highlight Updates」複選框:

"在Chrome中使用「突出顯示更新」複選框選中DevTools"

如今嘗試在表格中添加一行。如你所見,頁面上的每一個元素周圍都會顯示一個邊框。這意味着每次添加一行時,React都在計算和比較整個虛擬DOM樹。如今嘗試點擊一行內的counter按鈕。你將看到state更新後虛擬DOM如何更新 —— 只有引用了state key的元素及其children受到影響。

React DevTools會提示問題出在哪裏,但不會告訴咱們有關細節的信息:特別是所涉及的更新,是由diffing元素引發的?仍是被掛載(mounting)或者被卸載(unmounting)了?要了解更多信息,咱們須要使用React的內置分析器(注意它不適用於生產模式)。

添加?react_perf到應用的URL,而後轉到Chrome DevTools中的「Performance」標籤。點擊「錄製」(Record)並在表格上點擊。添加一些row,更改一下counter,而後點擊「中止」(Stop)。

"React DevTools的「Performance」選項卡"

在輸出的結果中,咱們關注「User timing」這項指標。放大時間軸直到看到「React Tree Reconciliation」這個組及其子項。這些就是咱們組件的名稱,它們旁邊都寫着[update]或[mount]。


咱們的大部分性能問題都屬於這兩類問題之一。


不管是組件(仍是從它分支的其餘組件)出於某種緣由都會在每次更新時re-mounted(慢),又或者咱們在大型應用上執行對每一個分支作diff,儘管這些組件並無發生改變,咱們不但願這些狀況的發生。

優化咱們的代碼:Mounting / Unmounting

如今,咱們已經瞭解到當須要update Virtual Dom時,React是依據哪些規則去判斷要不要更新,以及也知道了咱們能夠經過什麼方式去追蹤這些diff場景的背後發生了什麼,咱們終於準備好優化咱們的代碼了!首先,咱們來看看mounts/unmounts。

若是你可以注意到當一個元素包含的多個children,他們是由array組成的話,你能夠實現十分顯著的速度優化。

咱們來看看這個case:

<div>
  <Message />
  <Table />
  <Footer />
</div>

在咱們的Virtual DOM裏這麼表示:

// ...
props: {
  children: [
    { type: Message },
    { type: Table },
    { type: Footer }
  ]
}
// ...

這裏有一個簡單的Message例子,就是一個div寫着一些簡單的文本,和以及一個巨大的Table,比方說,超過1000行。它們(MessageTable)都是頂級div的子組件,因此它們被放置在父節點的props.children下,而且它們key都不會有。React甚至不會經過控制檯警告咱們要給每一個child分配key,由於children正在React.createElement做爲參數列表傳遞給父元素,而不是直接遍歷一個數組。

如今咱們的用戶已讀了一個通知,Message(譬如新通知按鈕)從DOM上移除。TableFooter是剩下的所有。

// ...
props: {
  children: [
    { type: Table },
    { type: Footer }
  ]
}
// ...

React會怎麼處理呢?它會看做是一個array類型的children,如今少了第一項,從前第一項是Message如今是Table了,也沒有key做爲索引,比較type的時候又發現它們倆不是同一個function或者class的同一個實例,因而會把整個Tableunmount,而後在mount回去,渲染它的1000+行子數據。

所以,你能夠給每一個component添加惟一的key(但在目特殊的case下,使用key並非最佳選擇),或者採用更聰明的小技巧:使用短路求值(又名「最小化求值」),這是JavaScript和許多其餘現代語言的特性。看:

// Using a boolean trick
<div>
  {isShown && <Message />}
  <Table />
  <Footer />
</div>

雖然Message會離開屏幕,父元素divprops.children仍然會擁有三個元素,children[0]具備一個值false(一個布爾值)。請記住true, false, null, undefined是虛擬DOM對象type屬性的容許值,咱們最終獲得了相似的結果:

// ...
props: {
  children: [
    false, //  isShown && <Message /> evaluates to false
    { type: Table },
    { type: Footer }
  ]
}
// ...

所以,有沒有Message組件,咱們的索引值都不會改變,Table固然仍然會跟Table比較(當type是一個函數或類的引用時,diff比較的成本仍是會有的),但僅僅比較虛擬DOM的成本,一般比「刪除DOM節點」並「從0開始建立」它們要來得快。

如今咱們來看看更多的東西。你們都挺喜歡用HOC的,高階組件是一個將組件做爲參數,執行某些操做,最後返回另一個不一樣功能的組件:

function withName(SomeComponent) {
  // Computing name, possibly expensive...
  return function(props) {
    return <SomeComponent {...props} name={name} />;
  }
}

這是一種常見的模式,但你須要當心。若是咱們這麼寫:

class App extends React.Component() {
  render() {
    // Creates a new instance on each render
    const ComponentWithName = withName(SomeComponent);
    return <SomeComponentWithName />;
  }
}

咱們在父節點的render方法內部建立一個HOC。當咱們從新渲染(re-render)樹時,虛擬DOM是這樣子的:

// On first render:
{
  type: ComponentWithName,
  props: {},
}

// On second render:
{
  type: ComponentWithName, // Same name, but different instance
  props: {},
}

如今,React會對ComponentWithName這個實例作diff,但因爲此時同名引用了不一樣的實例,所以全等比較(triple equal)失敗,一個完整的re-mount會發生(整個節點換掉),而不是調整屬性值或順序。注意它也會致使狀態丟失,如此處所述。幸運的是,這很容易解決,你須要始終在render外面建立一個HOC:

// Creates a new instance just once
const ComponentWithName = withName(Component);

class App extends React.Component() {
  render() {
    return <ComponentWithName />;
  }
}

優化個人代碼:Updating

如今咱們能夠確保在非必要的時候,不作re-mount的事情了。然而,對位於DOM樹根部附近(層級越上面的元素)的組件所作的任何更改都會致使其全部children的diffing和調整(reconciliation)。在層級不少、結構複雜的應用裏,這些成本很昂貴,但常常是能夠避免的。


若是有一種方法能夠告訴React你不用來檢查這個分支了,由於咱們能夠確定那個分支不會有更新,那就太棒了!


這種方式是真的有的哈,它涉及一個built-in方法叫shouldComponentUpdate,它也是組件生命週期的一部分。這個方法的調用時機:組件的render和組件接收到state或props的值的更新時。而後咱們能夠自由地將它們與咱們當前的值進行比較,並決定是否更新咱們的組件(返回truefalse)。若是咱們返回false,React將不會從新渲染組件,也不會檢查它的全部子組件。

一般來講,比較兩個集合(set)propsstate一個簡單的淺層比較(shallow comparison)就足夠了:若是頂層的值不一樣,咱們沒必要接着比較了。淺比較不是JavaScript的一個特性,但有不少小而美的庫utilities)可讓咱們用上那麼棒的功能。

如今能夠像這樣編寫咱們的代碼:

class TableRow extends React.Component {

  // will return true if new props/state are different from old ones
  shouldComponentUpdate(nextProps, nextState) {
    const { props, state } = this;
    return !shallowequal(props, nextProps)
           && !shallowequal(state, nextState);
  }

  render() { /* ... */ }
}

可是你甚至都不須要本身寫代碼,由於React把這個特性內置在一個類React.PureComponent裏面。它相似於 React.Component,只是shouldComponentUpdate已經爲你實施了一個淺的props/state比較。

這聽起來很「不動腦」,在聲明class繼承(extends)的時候,把Component換成PureComponent就能夠享受高效率。事實上,並非這麼「傻瓜」,看看這些例子:

<Table
    // map returns a new instance of array so shallow comparison will fail
    rows={rows.map(/* ... */)}
    // object literal is always "different" from predecessor
    style={ { color: 'red' } }
    // arrow function is a new unnamed thing in the scope, so there will always be a full diffing
    onUpdate={() => { /* ... */ }}
/>

上面的代碼片斷演示了三種最多見的反模式。儘可能避免它們!


若是你能注意點,在render定義以外建立全部對象、數組和函數,並確保它們在各類調用間,不發生更改 —— 你是安全的。


你在updated demo,全部table的rows都被「淨化」(purified)過,你能夠看到PureComponent的表現了。若是你在React DevTools中打開「Highlight Updates」,你會注意到只有表格自己和新行在插入時會觸發render,其餘的行保持不變。

[譯者說:爲了便於你們理解purified,譯者在下面插入了原文demo的一段代碼]

class TableRow extends React.PureComponent {
  render() {
    return React.createElement('tr', { className: 'row' },
      React.createElement('td', { className: 'cell' }, this.props.title),
      React.createElement('td', { className: 'cell' }, React.createElement(Button)),
    );
  }
};

不過,若是你火燒眉毛地all in PureComponent,在應用裏處處都用的話 —— 控制住你本身!

shallow比較兩組propsstate不是免費的,對於大多數基本組件來講,甚至都不值得:shallowComparediffing算法須要耗費更多的時間。

使用這個經驗法則:pure component適用於複雜的表單和表格,但它們一般會減慢簡單元素(按鈕、圖標)的效率。


感謝你的閱讀!如今你已準備好將這些看法應用到你的應用程序中。可使用咱們的小demo(用了沒有用PureComponent)的倉庫做爲你的實驗的起點。此外,請繼續關注本系列的下一部分,咱們計劃涵蓋Redux並優化你的數據,目標是提升整個應用的整體性能。

譯者說

正如原文末所說,Alex和Andy後續會繼續寫一個關於總體性能的系列,包括核心React和Redux等,我也會繼續跟蹤這個系列的文章,到時po到個人我的博客和知乎專欄《集異璧》,感興趣的同窗們能夠關注一下哈 :)

歡迎對本文的翻譯質量、內容的各類討論。如有表述不當,歡迎斧正。

2018.05.13,晴,杭州濱江
Yuying Wu


筆者 @Yuying Wu,前端愛好者 / 鼓勵師 / 新西蘭打工度假 / 鏟屎官。目前就任於某大型電商的B2B前端團隊。

感謝你讀到這裏。若是你和我同樣喜歡前端,喜歡搗騰獨立博客或者前沿技術,或者有什麼職業疑問,歡迎關注我以及各類交流哈。

獨立博客:wuyuying.com
知乎ID:@Yuying Wu
Github:Yuying Wu

相關文章
相關標籤/搜索