四、我的結論
通過第三部分的數據數據分析，我覺得我們可以得到以下結論：
- 無論是在開發環境還是測試環下頁面的首次加載速度結果都是：redux>immutablejs>mobx，但是他們之間的差距並不是很大。
- 10000條-100000條數據的頁面加載時間的增量明顯也高於10000-1000條數據的頁面加載時間增量。
- 無論是在開發環境還是生產環境下點擊完成某個todo所需的頁面渲染速度結果都是：mobx>immutablejs>redux，正好和頁面的首次加載時間相反，但是它們之間的差距還是蠻大的，具體表現在：
- mobx的渲染速度一騎絕塵大幅度領先其它兩者，尤其是在開發環境下，而且數據量越多越明顯。
- immutablejs和redux的差距在1000條和10000條數據時並不明顯，但是在100000條數據的時候有了明顯差距。
- mobx在1000條到100000條數據的增量並不明顯幅度很小，尤其是開發環境下，與此同時redux的增量要大於immutablejs，immutablejs大概處於它們倆之間。
從第三部分的統計圖上我目前能看到的信息就是這么多，聰明的你沒准能夠得出更多有用的信息，所以我把我的測試數據以及統計原圖的git倉庫打在下面，你們可以盡情的下載查看分析：
https://github.com/kwzm/redux-immutablejs-mobx-performance-test
五、深入的思考
其實如果讀到這里，我相信你和我一樣雖然通過紙面的數據得到了想要的結論，但是腦海里還是有各種疑問：
-
- 為什么mobx的用戶操作渲染速度會那么快
- 影響它們三者渲染速度的罪魁禍首又是誰
下面來讓我通過一組圖片來為你們解開這其中的緣由：
我選取了生產環境下10000條數據時，chrome的performance面板上的Summary餅狀圖來作為實例
從左往右依次為redux、immutablejs和mobx
我先介紹一下餅狀圖里面各項的含義：
-
- 黃色(Scripting)：JavaScript執行
- 紫色(Rendering)：樣式計算和布局，即重排
- 綠色(Painting)：重繪
- 灰色(other)：其它事件花費的時間
- 白色(Idle)：空閑時間
從中我們可以看到雖然出了Scripting其它四項也有差異，但是差異並不大，最大的差異點還是Scripting，也就是說js代碼的執行時間才是影響三者性能的主要原因，那么為什么三者的js執行時間會有如此大的差異呢？為了解釋這個問題，我在每個組件的render方法中添加了console.log語句，讓我看看當點擊操作發生后控制台輸出了什么。
在此之前，我先簡單介紹一下todoList的組件結構：
-
- App
- TodoHeader
- TodoList
- TodoItem
- TodoItem
- ......
- TodoFooter
- App
從左往右依次是redux、immutablejs和mobx：
從console面板我們可以看出mobx為什么js執行時間最短，因為它只有兩個組件執行了render方法，兩個必要的組件，而縱觀其它兩者都有些不必要的render，雖然react的diff算法已經很快了，但是當數據量達到一定規模的時候，這種不必要的render會越積越多，造成了內存和cpu的性能浪費。
至於為什么它們三者對於同一個事件執行的render方法會如此不同，這個並不在本文的探討范圍之內，這個涉及到這三者的原理，請大家自行百度吧。
六、參考資料
1、源碼
2、測試數據及圖表
3、性能測試
七、最后的話
其實我之前也從網上想找些現成的資料，但是無奈沒有找到，所以借由目前正在學習immutablejs和mobx之機，隨便做下性能的測試，但是其實這方面我完全是小白，包括如何進行性能測試，如何分析數據，我都是第一次做，所以如果有哪塊不正確還請您指出，我們共同學習，謝謝！
此乃作者原創作品，如需轉載，請在標題標明【轉載】並附上原文鏈接，謝謝。