React總結篇之五_React組件的性能優化

一、單個React組件的性能優化
React利用Virtual DOM來提高渲染性能，雖然這能將每次DOM操作量減少到最小，計算和比較Virtual DOM依然是一個復雜的計算過程。如果能夠在計算Virtual DOM之前就能判斷渲染結果不會有變化，那樣可以干脆不要進行Virtual DOM計算和比較，速度就會更快。

1. 發現浪費的渲染時間
   在Chrome瀏覽器中安裝React Perf擴展，步驟省略（屬于操作部分）

2. 性能優化的時機
   “我們應該忘記忽略很小的性能優化，可以說97%的情況下，過早的優化是萬惡之源，而我們應該關心對性能影響最關鍵的那另外3%的代碼” --高德納
   對于合并多個字符串，怎樣合并，使用什么方法合并不大可能對整個應用造成關鍵的性能影響，這就是高納德所說的97%的情況，而選擇用什么樣的方式去定義組件的接口，如何定義state到prop的轉變，使用什么樣的算法來比對Virtual DOM，這些決定對性能和架構的影響是巨大的，就是那關鍵的3%。

3. React-Redux的shouldComponentUpdate的實現
   使用React-Redux，一個典型的React組件代碼文件最后一個語句代碼是這樣的：
   export default connect(mapStateToProps)(mapDispatchToProps)(Foo)
   以上，connect過程中實際上產生了一個無名的React組件類，這個類定制了shouldComponentUpdate的實現，實現邏輯是比對這次傳遞給內層傻瓜組件的props和上次的props，如果相同那就沒必要重新渲染了，可以返回false，否則就要返回true。
   但是，我們需要了解一下shouldComponentUpdate的實現方式，shouldComponentUpdate在比對prop和上次渲染所用的prop方面，依然用的是盡量簡單的方法，做的是所謂的“淺層比較”。簡單來說就是用JavaScript的===操作符來比較，如果prop的類型是字符串或者數字，只要值相同，那么“淺層比較”也會認為二者相同，但是，如果prop的類型是復雜對象，那么“淺層比較”的方式只看這兩個prop是不是同一個對象的引用，如果不是，哪怕這兩個對象中的內容完全一樣，也會被認為是兩個不同的prop。
   比如，在JSX中使用組件Foo的時候給名為style的prop賦值，代碼如下：
   <Foo style={{color:"red"}} />
   像上面這樣的使用方法，Foo組件利用React-Redux提供的shouldComponentUpdate函數實現，每一次渲染都會認為style這個prop發生了變化，因為每次都會產生一個新的對象給style，而在“淺層比較”中，只比較第一層，不會去比較對象里面是不是相等。那為什么不用深層比較呢？因為一個對象到底有多少層無法預料，如果遞歸對每個字段都進行“深層比較”，不光代碼更復雜，也可能會造成性能問題。
   上面的例子應該改成下面這樣：
   const fooStyle = {color:"red"} //確保這個初始化只執行一次，不要放在render中
   <Foo style={fooStyle} />
   同樣的情況也存在與函數類型的prop，React-Redux無從知道兩個不同的函數是不是做著同樣的事，要想讓它認為兩個prop是相同的，就必須讓這兩個prop指向同樣一個函數，如果每次傳給prop的都是一個新創建的函數，那肯定就沒法讓prop指向同一個函數了。
   看TodoList傳遞給TodoItem的onToggle和onRemove，在JSX中代碼如下：
   onToggle = {（）=>onToggleTodo(item.id)}
   onRemove = {（）=>onRemoveTodo(item.id)}
   這里賦值給onClick的是一個匿名的函數，而且是在賦值的時候產生的。也就是說，每次渲染一個TodoItem的時候，都會產生一個新的函數，這就是問題所在。辦法就是不要讓TodoList每次都傳遞新的函數給TodoItem。有兩種解決方式。
   （1）第一種方式，TodoList保證傳遞給TodoItem的onToggle永遠只能指向同一個函數對象，這是為了應對TodoItem的shouldComponentUpdate的檢查，但是因為TodoItem可能有多個實例，所以這個函數要用某種方法區分什么TodoItem回調這個函數，區分的辦法只能通過函數參數。
   在TodoList組件中，mapDispatchToProps產生的prop中onToggleTodo接受TodoItem的id作為參數，恰好勝任這個工作，所以，可以在JSX中代碼改為下面這樣：
   <TodoItem
   key=em.id
   id=em.id
   text=em.text
   completed=em.completed
   onToggle={onToggleTodo}
   onRemove={onRemoveTodo}
   />
   注意，除了onToggle和onRemove的值變了，還增加了一個新的prop名為id，這是讓每個TodoItem知道自己的id，在回調onToggle和onRemove時可以區分不同的Todo-Item實例。
   TodoList的代碼簡化了，但是TodoItem組件也要做對應改變，對應TodoItem組件的mapDispatchToProps函數代碼如下：
   const mapDispatchToProps = (dispatch,ownProps) =>({
   onToggleItem : () => ownProps.onToggle(ownProps.id)
   });
   mapDispatchToProps這個函數有兩個參數dispatch和ownProps，ownProps也就是父組件渲染當前組件時傳遞過來的props，通過訪問ownProps.id就能夠得到父組件傳遞過來的名為id的prop值。
   上面的mapDispatchToProps這個函數給TodoItem組件增加了名為onToggleItem的prop，調用onToggle，傳遞當前實例的id作為參數，在TodoItem的JSX中就應該使用onToggleItem，而不是直接使用TodoList提供的onToggle。
   （2）第二種方式，干脆讓TodoList不要給TodoItem傳遞任何函數類型prop，點擊事件完全由TodoItem組件自己搞定。
   在TodoList組件的JSX中，渲染TodoItem組件的代碼如下：
   <TodoItem
   key = em.id
   id = em.id
   text = em.text
   completed = em.completed
   />
   可以看到不需要onToggle和onRemove這些函數類型的prop，但依然有名為id的prop。
   在TodoItem組件中，需要自己通過react-redux派發action，需要改變的代碼如下：
   const mapDispatchToprops = (dispatch,ownProps) = >{
   const {id} = ownProps.id;
   return {
   onToggle : () => dispatch(toggleTodo(id)),
   onRemove : () => dispatch(removeTodo(id))
   }
   };
   對比這兩種方式，看一看到無論如何TodoItem都要使用react-redux，都需要定義產生定制prop的mapDispatchToProps，都需要TodoList傳入一個id，區別只在于actions是由父組件導入還是組件自己導入。
   相比而言，沒有多大必要讓action在TodoList導入然后傳遞一個函數給TodoItem，第二種讓TodoItem處理自己的一切事物，更符合高內聚的要求。

二、多個React組件的性能優化
和單個組件的生命周期一樣，React組件也要考慮3個階段：裝載階段、更新階段、卸載階段。其中，裝載階段基本沒什么可以優化的空間，因為這部分工作沒有什么可以省略的。而卸載階段，只有一個生命周期函數componentWillUnmount，這個函數做的事情只是清理componentDidMount添加的事件處理監聽等收尾工作，做的事情要比裝載過程少很多，所以也沒什么可以優化的空間。所以值得關注的過程，只剩下更新過程。

1. React的調和過程
   React在更新階段，很巧妙的對比原有的Virtual DOM和新生成的Virtual DOM（存在于內存中），找出兩者的不同，根據不同修改DOM樹，這樣只需做最小的必要改動。
   React在更新中找不同的過程，就叫做調和（Reconciliation）。
   React實際采用的算法的時間復雜度是O(N)。React的Reconciliation算法并不復雜，當React要對比兩個Virtual DOM的樹形結構的時候，從根節點開始遞歸往下對比，在樹形結構上，每個節點都可以看做這個節點以下子樹部分的根節點，所以其實這個對比算法可以從Virtual DOM上的任何一個節點開始執行。
   React首先檢查兩個根節點的類型是否相同，根據相同或者不同有不同處理方式。
   （1）節點類型不同的情況
   這時可以直接認為原來的樹形結構已經沒用，需要重新構建新的DOM樹，原有樹形上的React組件會經歷“卸載”的生命周期。這時，componentWillUnmount的方法會被調用，取而代之的組件則會經歷裝載過程的生命周期，組件的componentWillMount、render和componentDidMount方法會被依次調用。
   （2）節點類型相同的情況
   這時React就會認為原來的根節點只需要更新，不必將其卸載，也不會引發根節點的重新裝載。
   這時，有必要區分一下節點的類型，節點的類型可以分為兩類：一類是DOM元素類型，對應的就是HTML直接支持的元素類型，比如<div />,<span />和<p />;另一類是React組件，也就是利用React庫定制的類型。

   • 對于DOM元素類型，React會保留節點對應的DOM元素，只對樹形結構根節點上的屬性和內容做一下對比，然后只更新修改的部分。
   • 對于React組件類型，React會根據新節點的props去更新原來根節點的props實例，引發這個組件實例的更新過程，也就是按照順序引發下列函數：
     shouldComponentUpdate
     componentWillReceiveProps
     componentWillUpdate
     render
     componentDidUpdate
     在處理完根節點的對比之后，React的算法會對根節點的每個子節點重復一樣的動作，這時候每個子節點就會成為它所覆蓋部分的根節點，處理方式和它的父節點完全一樣。
     （3）多個子組件的情況
     當一個組件包含多個子組件，React的處理方式也非常的簡單直接。
     
     React發現多了一個TodoItem，會創建一個新的TodoItem組件實例，這個TodoItem組件實例需要經歷裝載過程，對于前兩個TodoItem實例，React會引發它們的更新過程。
     上面的例子是TodoItem序列后面增加了一個新的TodoItem實例，接下來在TodoItem序列前面增加一個TodoItem實例，代碼如下：
     
     像上面新的TodoItem實例插入在第一位的例子中，React會首先認為把text為First的TodoItem組件實例的text改成了Zero，text為Second的TodoItem組件實例的text改成了First，在后面多出了一個TodoItem組件實例，text內容為Second。這樣操作的后果就是，現存的兩個TodoItem實例的text屬性被改變了，強迫它們完成了一個更新過程。React提供了方法來克服這種浪費，但需要開發人員在寫代碼的時候提供一點幫助，這就是key的作用。
2. key的用法
   默認情況下，在React的眼里，確定每一個組件在組件序列中的唯一標識就是它的位置，所以它也完全不懂哪些子組件實際上并沒有改變，為了讓React更加“聰明”，就需要開發者提供一點幫助。
   如果在代碼中明確的告訴React每個組件的唯一標識，就可以幫助React在處理這個問題時聰明很多，告訴React每個組件“×××號”的途徑就是key屬性。假如讓待辦事項列表用JSX標識的代碼如下：
   <UI>
   <TodoItem key={1} text="First" completed={false} />
   <TodoItem key={2} text="Second" completed={false} />
   <UI />
   前面代碼的區別是每個TodoItem增加了名為key的prop，而且每個key是這個TodoItem實例的唯一id?，F在第一位增加一個TodoItem實例，并給一個唯一的key值0，React的處理方式會不一樣。
   <UI>
   <TodoItem key={0} text="Zero" completed={false} />
   <TodoItem key={1} text="First" completed={false} />
   <TodoItem key={2} text="Second" completed={false} />
   <UI />
   React根據key值，可以知道現在的第二個和第三個TodoItem實例其實就是之前的第一個和第二個實例，所以React就會把新創建的TodoItem實例插在第一位，對于原有的兩個TodoItem實例只用原有的props來啟動更新過程，這樣shouldComponentUpdate就會發生作用，避免無謂的更新操作。
   在一列子組件中，每個子組件的key值必須唯一，并且key值還需要是穩定不變的，因此數組的下標不能作為key使用。
   注意：雖然key是一個prop，但是接受key的組件并不能讀取到key的值，因為key和ref是React保留的兩個特殊的prop，并沒有預期讓組件直接訪問。
   

三、用reselect提高數據獲取性能

1. 兩階段選擇過程
   reselect庫的工作原理：只要相關狀態沒有改變，那就直接使用上一次的緩存結果。
   reselect庫被用來創造“選擇器”，即接受state作為參數的函數，這個選擇器函數返回的數據就是我們某個mapStateToProps需要的結果。
   reselect認為一個選擇器的工作可以分為兩個部分，把一個計算步驟分為兩個步驟：
   （1）從輸入參數state抽取第一層結果，將這第一層結果和之前抽取的第一層結果做比較，如果發現完全相同，就沒有必要進行第二部分運算了，選擇器直接把之前第二部分的運算結果返回就好了。注意：這一部分做的比較，就是JavaScript的===操作符比較，如果第一層結果是對象的話，只有是同一對象才會被認為是相同。
   （2）根據第一層結果計算出選擇器需要返回的最終結果。
   顯然，每次選擇器函數被調用時，步驟一都會被執行，但步驟一的結果被用來判斷是否可以使用緩存的結果，所以并不是每次都會調用步驟二的運算。
   剩下的事情就是確定選擇器步驟一和步驟二分別進行什么運算。原則很簡單，步驟一運算因為每次選擇器都要使用，所以一定要快，運算要非常簡單，最好就是一個映射運算，通常就只是從state參數中得到某個字段的引用就足夠，把剩下來的重活累活都交給步驟二去做。
   在TodoList的具體例子中，todos和filter的值直接決定了應該顯示什么樣的待辦事項，所以，步驟一是獲取todos和filter的值，步驟二是根據這兩個值進行計算。
   使用reselect需要安裝對應的npm包：
   npm install --save reselect
   
   reselect提供了創造選擇器的createSelector函數，這是一個高階函數，也就是接受函數為參數來產生一個新函數的函數。
   第一個參數是一個函數數組，每個元素代表了選擇器步驟一需要做的映射計算，這里我們提供了兩個函數getFilter和getTodos，代碼如下：
   const getFilter = （state）=>state.filter;
   const getTodos = （state） = >state.todos;
   createSelector函數的第二個參數代表步驟二的計算過程，參數為第一個參數的輸出結果。
   現在，可以在TodoList模塊中改用新定義的選擇器來獲取待辦事項數據了：
   import {selectVisibleTodos} from '../selector.js'
   const mapStateToProps = (state) =>{
   return {
   todos : selectVisibleTodos(state)
   }
   }
   Redux要求每個reducer不能修改state狀態，如果要返回一個新的狀態，就必須返回一個新的對象。這樣，如果state狀態樹上的某個節點沒有變化，那我們可以認為這個節點下的數據沒有改變，應用在reselect中，步驟一的運算就可以確定使用緩存的數據結果。
   雖然reselect的createSelector創造的選擇器并不是一個純函數，但是createSelector接受的所有函數參數都是純函數，雖然選擇器有“記憶”這個副作用，但只要輸入參數state沒有變化，產生的結果也就沒有變化，表現得卻類似于一個純函數。

2. 范式化狀態樹
   狀態樹的設計盡量范式化。所謂范式化，就是遵照關系型數據庫的設計原則，減少冗余數據。
   反范式化的設計：
   {
   id : 1, //待辦事項id
   text：“待辦事項1”, //待辦事項文字內容
   completed：false， //是否已完成
   type：{ //種類
   name：“緊急” ， //種類的名稱
   color：“red” //種類的顯示顏色
   }
   }
   范式化的設計：
   {
   id：1， //待辦事項id
   text：“待辦事項1” //待辦事項文字內容
   completed：false， //是否已完成
   typeId：1， 待辦事項所屬的種類id
   }
   用一個typeId代表類型，然后在Redux store上和Todos平級的根節點位置創建一個types字段，內容是一個數組，每個數組元素代表一個類型，一個種類的數據是類似下面的對象：
   {
   id：1， //種類id
   name：“緊急”， //種類的名稱
   color：“red” //種類的顯示顏色
   }
   當TodoItem要渲染內容時，從Redux Store狀態樹的todos字段下獲取的數據是不夠的，因為只有typeId。為了獲得對應的種類名稱和顏色，需要做一個類似關系型數據庫的join操作，到狀態樹的type字段下去尋找對應的typeId的種類數據。
   以上比較來看范式方式更合理。因為雖然join數據需要花費計算時間，但是用了reselect之后，大部分情況下都會命中緩存，實際上也就沒有花費很多計算時間了。