redux、immutablejs和mobx性能对比(三)
2019-11-06

四、我的结论

  通过第三部分的数据数据分析,我觉得我们可以得到以下结论:

    无论是在开发环境还是测试环下页面的首次加载速度结果都是: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的组件结构:

AppTodoHeaderTodoListTodoItemTodoItem......TodoFooter

     从左往右依次是redux、immutablejs和mobx:

  

    从console面板我们可以看出mobx为什么js执行时间最短,因为它只有两个组件执行了render方法,两个必要的组件,而纵观其它两者都有些不必要的render,虽然react的diff算法已经很快了,但是当数据量达到一定规模的时候,这种不必要的render会越积越多,造成了内存和cpu的性能浪费。

    至于为什么它们三者对于同一个事件执行的render方法会如此不同,这个并不在本文的探讨范围之内,这个涉及到这三者的原理,请大家自行百度吧。

六、参考资料

   1、源码

redux:https://github.com/kwzm/react-redux-todoimmutablejs:https://github.com/kwzm/react-redux-immutablejs-todomobx:https://github.com/kwzm/react-mobx-todo

  2、测试数据及图表

https://github.com/kwzm/redux-immutablejs-mobx-performance-test

  3、性能测试

全新Chrome Devtools Performance使用指南初探performance-监控网页于程序性能

七、最后的话

  其实我之前也从网上想找些现成的资料,但是无奈没有找到,所以借由目前正在学习immutablejs和mobx之机,随便做下性能的测试,但是其实这方面我完全是小白,包括如何进行性能测试,如何分析数据,我都是第一次做,所以如果有哪块不正确还请您指出,我们共同学习,谢谢!