主要比较参数:
- 库体积,打包项目体积
- 开发体验
- 性能对比
在对比参数前首先分析一下redux和mobx的设计模式,redux和mobx都没有使用传统的mvc/mvvm形式,而且他们使用flux结构也略有不同,这个也是造成redux和mobx各项参数不同的缘由之一。
mvc/mvvm和flux的对比
mvc设计图 flux设计图如图可知,mvc在处理多数据和复杂业务是有一定局限性的,一个view层可能会调用到无数个model层,当然解决这个问题的方法也是有的,我们可以将多个model抽象成一个model,例如处理基础数据的model合成一个基础model,但这样编写也会造成代码的冗余以及没必要的性能损耗。
flux对比mvc,代码结构更加简单、一目了然。action处理数据请求,然后将请求dispatch到store中,这样设计也十分契合react单向数据流的概念。在本文提到的两个框架redux和mobx也都是基于flux的设计概念,不同的是mobx在store和view中处理数据是使用的双向绑定,如下图。
mobx设计图双向绑定无疑会增加性能消耗,但是mobx在双向绑定的同时禁掉了react自身的刷新,要知道react shouldupdate生命周期是性能优化的大头,mobx禁掉了这个性能会直接大幅提升,但这个和双向绑定的性能消耗相比谁占用的性能更高,让我们用数据比较。
库体积,打包项目体积
我选用了两个相似的项目,一个使用redux开发,一个mobx(之所以没用两个框架把一个项目写两遍是因为我太懒了)。
mobx项目表红的部分是抽出的lib和打包的js,一个是64.2k,一个是29.2k。
redux项目这个项目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多不少,体积这方面基本可以忽略。
网友评论