最近在處理大list（infinite scroll view）時，發現元素多了之后react渲染開始變得卡頓，想找一找問題出在哪里了，在參考了一些博客和做了一番研究之后，給大家來個總結。redux的store中的數據量太大，肯定是會影響性能的，但是跟其本身占的內存並沒有太大關系，影響的是一些別的東西，請往下看。
1.action觸發大量reducer的開銷
store過分龐大，就是意味着state樹的分支很多，也就導致節點對應的reducer特別多，派發一個action，會把所有的reducer都跑一遍，最后觸發對應的action修改state的操作，這對性能會有一定影響，有的人說用combineReducers，用了這個action還是會把所有reducer跑一遍，combineReducers只是把state節點分離了而已，用來關注當前state節點的操作，跟action沒關系，如果你在兩個reducer里面有重名的action type，他兩都會觸發，證明還是會都跑一遍。這里推薦使用 redux-ignore https://github.com/omnidan/redux-ignore，可以防止觸發跟某reducer不相關的其他action。
2.state樹的內存開銷(沒有太大關系)
所謂的state tree就是一個json object。在棧里面存了一個引用，在堆里面存了一個對象，就算state樹很大層級很多，基本也不可能達到G級別的，況且，在正確設計state樹的情況下，這是不可能也不合理的，redux推薦設計盡可能最小化的state樹，只放必要的節點，其他的應該交由組件自己的state來維護。
3.通過connect()連接store的subscriber，在store改變時被觸發的開銷
如果每個UI component都連接一堆props到store自然是很恐怖的，因此redux推薦只在最外部的組件中做connect，也就是container，然后在container中引用其他component來渲染，component自身的一些狀態改變可以用react自己的state來維護。
4.渲染大型虛擬DOM的開銷
首先react-redux框架中的connect已經幫我們優化了最外層的container，只會渲染改變的部分，至於container中的其他component，可以通過shouldComponentUpdate()來判斷是否重新渲染組件，這也是可以輕松完成的性能優化。但是當處理大list時（上拉無限加載），在dom元素越來越多時，渲染還是明顯會出現卡頓，雖然react只會將虛擬dom改變的部分渲染到真實dom（暫且相信react在大量數據下的diff算法，官方說很高效，事實也確實如此），但是如果改動部分的dom節點本身就是一個龐大的量級（比如一次性改變或插入一萬個dom節點），那么渲染就會卡頓，redux作者做過一個壓力測試，結論是渲染一萬個node時，操作會有輕微的延遲。當然，正常的app應該是不會有上千node的，假如真的有，那絕大部分都不是用戶可見的（比如一個很長很長的scroll view，切換tab回來的時候還保持滾動位置，不自動刷新dom，就會導致一次性重新插入大量dom）。這樣情況下，可以用 react-infinite https://github.com/seatgeek/react-infinite，原理是只渲染用戶能看見，以及即將看見的。其余的都合並起來放在一個dummy node里。