四、我的結論

　通過第三部分的資料資料分析，我覺得我們可以得到以下結論：

1. 無論是在開發環境還是測試環下頁面的首次載入速度結果都是：redux>immutablejs>mobx，但是他們之間的差距並不是很大。
2. 10000條-100000條資料的頁面載入時間的增量明顯也高於10000-1000條資料的頁面載入時間增量。
3. 無論是在開發環境還是生產環境下點選完成某個todo所需的頁面渲染速度結果都是：mobx>immutablejs>redux，正好和頁面的首次載入時間相反，但是它們之間的差距還是蠻大的，具體表現在：

• mobx的渲染速度一騎絕塵大幅度領先其它兩者，尤其是在開發環境下，而且資料量越多越明顯。
• immutablejs和redux的差距在1000條和10000條資料時並不明顯，但是在100000條資料的時候有了明顯差距。
• mobx在1000條到100000條資料的增量並不明顯幅度很小，尤其是開發環境下，與此同時redux的增量要大於immutablejs，immutablejs大概處於它們倆之間。

　　　從第三部分的統計圖上我目前能看到的資訊就是這麼多，聰明的你沒準能夠得出更多有用的資訊，所以我把我的測試資料以及統計原圖的git倉庫打在下面，你們可以盡情的下載檢視分析：

五、深入的思考

　　其實如果讀到這裡，我相信你和我一樣雖然通過紙面的資料得到了想要的結論，但是腦海裡還是有各種疑問：

• • 為什麼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

 　　　　從左往右依次是redux、immutablejs和mobx：

　　　　從console面板我們可以看出mobx為什麼js執行時間最短，因為它只有兩個元件執行了render方法，兩個必要的元件，而縱觀其它兩者都有些不必要的render，雖然react的diff演算法已經很快了，但是當資料量達到一定規模的時候，這種不必要的render會越積越多，造成了記憶體和cpu的效能浪費。

　　　　至於為什麼它們三者對於同一個事件執行的render方法會如此不同，這個並不在本文的探討範圍之內，這個涉及到這三者的原理，請大家自行百度吧。

六、參考資料

 　　1、原始碼

　　2、測試資料及圖表

　　3、效能測試

七、最後的話

　　其實我之前也從網上想找些現成的資料，但是無奈沒有找到，所以藉由目前正在學習immutablejs和mobx之機，隨便做下效能的測試，但是其實這方面我完全是小白，包括如何進行效能測試，如何分析資料，我都是第一次做，所以如果有哪塊不正確還請您指出，我們共同學習，謝謝！