高效能 React 元件

發表於2016-08-12

TB1P4h_LpXXXXbGXpXXXXXXXXXX-900-500

前言

元件的重新渲染

說到 React 元件,肯定離不開元件的 props 和 state,我們可以在 props 和 state 存放任何型別的資料,通過改變 props 和 state,去控制整個元件的狀態。當 props 和 state 發生變化時,React 會重新渲染整個元件,元件重新渲染的過程可簡化如下圖:

c3c7f7f478d86c40530967b5b0fc12037bc71d22

當元件的 props 或 state 變化,React 將會構建新的 virtual DOM,使用 diff 演算法把新老的 virtual DOM 進行比較,如果新老 virtual DOM 樹不相等則重新渲染,相等則不重新渲染。DOM 操作是非常耗時的,這導致重新渲染也非常的耗時,因此要提高元件的效能就應該盡一切可能的減少元件的重新渲染。

假設有一個渲染完成的元件,如下圖:

c9a9e30223ef6188a4a498a8cfd92e346ba5c17d

接下來因為狀態改變,需要重新渲染下圖的綠色的節點,如下圖:

7a8b26b7b14319ae4bfedf385fcb092ac33927a4

一般的想法是隻需要更新下面的三個綠色節點就能夠完成元件的更新,如下圖:

5519a489525ef4b43ca636c2d05890f4cdbb8c94

事實上根據 React 的更新規則,只要元件的 props 或 state 發生了變化就會重新渲染整個元件,因此除了上述的三個綠色節點以外,還需要重新渲染所有的黃色的節點,如下圖:

ca1f450b3816ce5fa3411be1710ecc76d7552765

除了必要渲染的三個節點外,還渲染了其他不必要渲染的節點,這對效能是一個很大的浪費。如果對於複雜的頁面,這將導致頁面的整體體驗效果非常差。因此要提高元件的效能,就應該想盡一切方法減少不必要的渲染。

元件優化

Pure Component

如果一個元件只和 props 和 state 有關係,給定相同的 props 和 state 就會渲染出相同的結果,那麼這個元件就叫做純元件,換一句話說純元件只依賴於元件的 props 和 state,下面的程式碼表示的就是一個純元件。

shouldComponentUpdate

shouldComponentUpdate 這個函式會在元件重新渲染之前呼叫,函式的返回值確定了元件是否需要重新渲染。函式預設的返回值是 true,意思就是隻要元件的 props 或者 state 發生了變化,就會重新構建 virtual DOM,然後使用 diff 演算法進行比較,再接著根據比較結果決定是否重新渲染整個元件。函式的返回值為 false 表示不需要重新渲染。shouldComponentUpdate 在元件的重新渲染的過程中的位置如下圖:

354dc8a5e804e06986dae35a92309ec7685499d9

函式預設返回為 true,表示在任何情況下都進行重新渲染的操作,要減少重新渲染,只需要在一些不必要重新渲染的時候,使得函式的返回結果為 false。如果使得函式的結果一直為 false,這樣不管元件的狀態怎麼變化,元件都不會重新渲染,當然一般情況下沒有人會這樣幹。

PureRenderMixin

React 官方提供了 PureRenderMixin 外掛,外掛的功能就是在不必要的情況下讓函式shouldComponentUpdate 返回 false, 使用這個外掛就能夠減少不必要的重新渲染,得到一定程度上的效能提升,其使用方法如下:

檢視原始碼後發現這個外掛其實就是重寫了 shouldComponentUpdate 方法。

重寫的方法裡面根據元件的目前的狀態和元件接下來的狀態進行淺比較,如果元件的狀態發生變化則返回結果為 false,狀態沒有發生變化則返回結果為 true,把這個函式進行進一步的分解其實現如下:

就是分別去比較了函式的 props 和 state 的變化情況。

在 React 的最新版本里面,提供了 React.PureComponent 的基礎類,而不需要使用這個外掛。

狀態比較

假設在每一個元件中都使用 PureRenderMixin 這個外掛,我們來看一下使用這個外掛後的狀態的比較過程。假設我們有一個元件如下:

我們想要去改變這個元件的顏色,使其變為 blue

則狀態的比較就是下面的物件的比較。

72ca4706b371e37deaa3d63a3427c992b6b6911d

上圖的比較是簡單物件的比較,比較過程非常簡單而且快速。但是如果是比較複雜的物件的比較,比如日期、函式或者一些複雜的巢狀許多層的物件,這些會比較耗時,甚至沒法進行比較。

其實我們自己可以重寫 shouldComponentUpdate 這個函式,使得其能夠對任何事物進行比較,也就是深比較(通過一層一層的遞迴進行比較),深比較是很耗時的,一般不推薦這麼幹,因為要保證比較所花的時間少於重新渲染的整個元件所花的時間,同時為了減少比較所花的時間我們應該保證 props 和 state 儘量簡單,不要把不必要的屬性放入 state,能夠由其他屬性計算出來的屬性也不要放入 state 中。

Immutable.js

對於複雜的資料的比較是非常耗時的,而且可能無法比較,通過使用 Immutable.js 能夠很好地解決這個問題,Immutable.js 的基本原則是對於不變的物件返回相同的引用,而對於變化的物件,返回新的引用。因此對於狀態的比較只需要使用如下程式碼即可:

這類比較是非常快速的。

動靜分離

假設我們有一個下面這樣的元件:

這是一個可以滾動的表格,offsetTop 代表著可視區距離瀏覽器的的上邊界的距離,隨著滑鼠的滾動,這個值將會不斷的發生變化,導致元件的 props 不斷地發生變化,元件也將會不斷的重新渲染。如果使用下面的這種寫法:

因為 InnerTable 這個元件的 props 是固定的不會發生變化,在這個元件裡面使用pureRenderMixin 外掛,能夠保證 shouldComponentUpdate 的返回一直為 false, 因此不管元件的父元件也就是 OuterScroll 元件的狀態是怎麼變化,元件 InnerTable 都不會重新渲染。也就是子元件隔離了父元件的狀態變化。

通過把變化的屬性和不變的屬性進行分離,減少了重新渲染,獲得了效能的提升,同時這樣做也能夠讓元件更容易進行分離,更好的被複用。

Children

對於巢狀多層、複雜的元件,元件的子節點很多,元件的更新的時間也將花費更多,並且難於維護,資訊流從上往下由父元件傳遞到子元件單向流動,這可能會導致元件失去我們的控制。

children change over time

有如下的一個元件(現實中沒人會這樣寫,這只是一個 demo),元件每 1 秒渲染一次。

通過在 shouldComponentUpdate 函式裡面判斷元件的 children 是否相等決定是否重新進行渲染,由於 children 是 props 的一個屬性,應該每次都是一樣的,元件應該不會重新渲染,可是事實上元件每次都會重新渲染。

讓我們來看一下,children 的具體結構,如下圖:

63cb24b655ca5fd9cec7168d0716fd0be7a7f854

children 是一個比較複雜的物件,每次元件更新的時候都會重新構造,也就是說 children 是動態構建的,因此每次更新的時候都是不相等的。所以 shouldComponentUpdate 每次都會返回 true,因此元件每次都會重新渲染。可以用一個變數來代替 children,這樣每次構造的也會是相同的物件。

Independent children

再來看一個比較費力的做法,如下:

通過在 shouldComponentUpdate 中返回 false,元件將不會因為外界的狀態變化而發生改變,我們這樣做是因為元件 TargetContainerBudgetContainer 沒有從它們的父元素獲取任何資訊,這樣就不需要管外界的變化,把 children 和父元件進行了隔離,其實TwoColumnSplit 就是起了隔離的作用。對於不需要從外界獲取資料的元件,可以通過返回false 來隔離外界的變化,減少重新渲染。

Container and Component

我們也可以通過元件的容器來隔離外界的變化。容器就是一個資料層,而元件就是專門負責渲染,不進行任何資料互動,只根據得到的資料渲染相應的元件,下面就是一個容器以及他的元件。

容器不應該有 props 和 children,這樣就能夠把容器自己和父元件進行隔離,不會因為外界因素去重新渲染,也沒有必要重新渲染。

設想一下,如果設計師覺得這個元件需要移動位置,你不需要做任何的更改只需要把元件放到對應的位置即可,我們可以把它移到任何地方,可以放在不同的應用中,同時也可以應用於測試,我們只需要關心容器的內部的資料的來源即可,在不同的環境中編寫不同的容器。

c74de69b05661a277c6e9ad2ab12775b706af4d6

總結

  • Purity => Use shouldComponentUpdate & PureRenderMixin
  • Data Comparability => Use highly comparable data (immutability)
  • Loose coupling => Use for maintainability and performance
  • Children => Be careful of children, children create deep update,

    children are always change, we should insulate them from parent

參考資料

相關文章