主要比較參數：
- 庫體積，打包項目體積
- 開發體驗
- 性能對比
在對比參數前首先分析一下redux和mobx的設計模式，redux和mobx都沒有使用傳統的mvc/mvvm形式，而且他們使用flux結構也略有不同，這個也是造成redux和mobx各項參數不同的緣由之一。
mvc/mvvm和flux的對比
如圖可知，mvc在處理多數據和復雜業務是有一定局限性的，一個view層可能會調用到無數個model層，當然解決這個問題的方法也是有的，我們可以將多個model抽象成一個model，例如處理基礎數據的model合成一個基礎model，但這樣編寫也會造成代碼的冗余以及沒必要的性能損耗。
flux對比mvc，代碼結構更加簡單、一目了然。action處理數據請求，然后將請求dispatch到store中，這樣設計也十分契合react單向數據流的概念。在本文提到的兩個框架redux和mobx也都是基於flux的設計概念，不同的是mobx在store和view中處理數據是使用的雙向綁定，如下圖。
雙向綁定無疑會增加性能消耗，但是mobx在雙向綁定的同時禁掉了react自身的刷新，要知道react shouldupdate生命周期是性能優化的大頭，mobx禁掉了這個性能會直接大幅提升，但這個和雙向綁定的性能消耗相比誰占用的性能更高，讓我們用數據比較。
庫體積，打包項目體積
我選用了兩個相似的項目，一個使用redux開發，一個mobx(之所以沒用兩個框架把一個項目寫兩遍是因為我太懶了)。
表紅的部分是抽出的lib和打包的js，一個是64.2k，一個是29.2k。
這個項目redux lib是webpack手動打包的，沒有像mobx項目用打包版本，體積是43.2k，app.js由於比mobx項目多使用了一個svg庫（32k），體積達到了62.3k，減去多的一個庫大概30.3k。
綜上，redux比mobx打包體積略大，幾乎可以忽略不記，但是lib包比mobx小20k，所以這輪redux勝，ヾ(=▽=)ノ。
開發體驗
- 學習成本：mobx基本看一遍，看看demo就能上手寫了；redux看兩天，寫了個練手demo才勉強會。
- 開發效率：由於mobx是雙向綁定的，開發的時候你會覺得mobx寫的都是有效代碼；redux寫同一個功能會多寫很多代碼，代碼邏輯繞啊繞。
- 代碼質量：redux直接寫，不做react渲染優化是個大坑，但是react渲染優化又比較繁瑣，可能還要添加第三方插件，增加不必要的代碼量。mobx基本不做渲染優化，渲染更新，是否更新的生命周期都被禁用了，還優化個屁。。。。
綜上 開發體驗上mobx比redux領先太多。
性能對比 此次比較是redux項目已經優化，mobx項目未優化的情況下進行的，mobx項目優化后會補坑
- 初始渲染
感官是mobx更快，但是實際....下面上圖。下面兩張圖是初次渲染的圖，明顯mobx在內存占用上更大，我考慮的原因mobx和redux渲染部分都是靠的react，這部分差別不大，主要是mobx多了雙向綁定導致最大內存數值很高。在布局和渲染方面mobx優勢明顯，主要得益於mobx禁用了react大部分的生命周期，很大程度的減少了刷新次數，這次用的redux項目已經是優化過了渲染次數的，但還是渲染這么多次不禁汗顏。javascript與事件這塊沒有做太多了解，待填坑。
- 內存穩定后測同樣操作的性能。
redux最大內存162，但渲染次數還是驚人。
mobx內存最大290，唯一欣慰的是渲染次數比較少。
總結
優化過后的redux項目性能比較好，mobx暫時還沒想到特別好的優化方案，找到了會補坑；框架體驗，開發效率，學習成本方面mobx更好，希望優化過后的mobx性能有所提升；代碼打包體積redux確實要小點，但是如果項目比較龐大，redux開發代碼會比mobx多不少，體積這方面基本可以忽略。