主要比较参数：
- 库体积，打包项目体积
- 开发体验
- 性能对比
在对比参数前首先分析一下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多不少，体积这方面基本可以忽略。