reactaomini（第三弹），赢在小巧，性能方面，干翻reactredux还是可以的

到目前为止&＃xff0c;react-aomini最大的特点就是简单粗暴&＃xff08;react-aomini是个人写的一个谈不上框架的小框架&＃xff0c;不了解的可以看看我之前写的两篇博文&＃xff0c;react-redux&＃xff1f;mobx&＃xff1f;或许我需要更加小巧玲珑的和小巧玲珑的react框架&＃xff08;第二弹&＃xff09;正式命名--aomini&＃xff09;&＃xff0c;大家感兴趣的可以从react-aomini github签出代码看看&＃xff0c;代码写的也没拾掇过&＃xff0c;见笑见笑&＃xff0c;看个思路&＃xff0c;简单轻量是实现了&＃xff0c;但是大家还是会疑惑&＃xff0c;那真的能投入实战吗&＃xff0c;性能到底咋样呢&＃xff1f;实不相瞒&＃xff0c;我个人也是比较好奇&＃xff0c;毕竟我也没有测试过&＃xff0c;不过我还是蛮有信心的&＃xff0c;因为轻量就是不为求全&＃xff0c;只为解决最尖锐的那个问题&＃xff0c;所以最接近原生&＃xff0c;原生肯定比在外面套层外套跑的快啦&＃xff0c;所以相信react-aomini不会太挫&＃xff0c;不过说是这么说&＃xff0c;还是要数据来说话。 为了结果更加有参考意义&＃xff0c;我们就拿当下最流行的react-redux框架来进行性能对比&＃xff0c;react-aomini和react-redux作为实验组&＃xff0c;并加入react原生作为参照组。我们的性能测试对比主要是采用控制三个不同的框架作为唯一变量进行实验&＃xff0c;三个实验对象中对同一个模块进行相同数量级的调用&＃xff0c;分别记录耗时数据。 接下来简要说明一下我们的实验&＃xff0c;我们会对每个实验体&＃xff08;也就是react-aomini&＃xff0c;react和react-redux&＃xff09;分别进行百级、千级、万级以及十万级的模块加载&＃xff0c;然后分别对所有模块进行更新操作&＃xff0c;模块加载暂不作为统计数据&＃xff0c;我们取更新操作的耗时作为实验数据&＃xff0c;每组取十个数据作为一组。为了方便起见&＃xff0c;我使用其中最简单的react原生代码进行实验说明&＃xff0c;代码如下&＃xff1a; Module1.js

class Module1 extends React.Component{constructor(){super();this.state &＃61; {moduleQuantity:900};}render(){let { moduleQuantity } &＃61; this.props;return (

)}componentDidUpdate(prevProps, prevState) {console.log("Module1 did update")}setValue(e){console.log(e.target.value);let { setModuleQuantity } &＃61; this.props;setModuleQuantity(e.target.value);}
}


MoudleX.js代码如下&＃xff1a;

/**
* siblings2
*/
class ModuleX extends React.Component{constructor(){super();this.startTime &＃61; 0;this.state &＃61; {updateCount:1};}render(){let {moduleQuantity} &＃61; this.props;let { updateCount } &＃61; this.state;console.log("&&&&&&&&&&&",updateCount)let subNum &＃61; Number(moduleQuantity || 0);return (

)}componentWillUpdate(nextProps, nextState) {this.startTime &＃61; new Date().getTime();console.log("ModuleX will update")}componentDidUpdate(prevProps, prevState) {console.log("ModuleX did update using time:",new Date().getTime() - this.startTime)}updateX(){let { updateCount } &＃61; this.state;this.setState({updateCount:updateCount&＃43;1});}
}


最重要的一个实验模块SubModuleX代码如下&＃xff1a;

class SubModuleX extends React.Component{constructor(props) {super(props);this.state &＃61; {};}render() {let { mIndex, updateCount } &＃61; this.props;return

}
}


App.js文件如下&＃xff1a;

class App extends React.Component{constructor(){super();this.name &＃61; "App";this.state &＃61; {moduleQuantity:900}}render(){let {moduleQuantity} &＃61; this.state;console.log("moduleQuantity:",moduleQuantity)return (

)}setModuleQuantity(moduleQuantity){this.setState({moduleQuantity})}
}


实验代码如上简要说明一下&＃xff0c;十分简单。其中Module1模块主要是一个moduleQuantity的输入框&＃xff0c;也就是控制实验数量的一个输入&＃xff0c;ModuleX模块中获取moduleQuantity后&＃xff0c;对SubModuleX进行循环装载&＃xff0c;模块加载完后&＃xff0c;才算是准备好进行实验&＃xff0c;这里注意&＃xff0c;我们并没有将模块的加载耗时作为实验数据&＃xff0c;而是将更新模块耗时作为实验数据。 为了数据更具有参考意义&＃xff0c;这里贴一下我实验环境参数&＃xff1a;mac pro&＃xff0c;单核 i7处理器2.4GHz&＃xff0c;8G内存&＃xff0c;google浏览器最新版本61.0.3163.100。 开始我们的实验后&＃xff0c;我们只需要点击ModuleX中的更新按钮&＃xff0c;所有模块更新完毕后&＃xff0c;会打印出每次的耗时。我们将实验结果记录并绘成折线图&＃xff0c;结果如下&＃xff1a;

以上结果可以看出&＃xff0c;在千级模块调用内&＃xff0c;耗时几乎都在100毫秒内&＃xff0c;差距并不大&＃xff0c;在实际开发中感受必定不明显&＃xff0c;但是已经一目了然。随着数量级的增大&＃xff0c;到了万级的模块调用&＃xff0c;性能明显进一步拉大&＃xff0c;react均值在450ms&＃xff0c;react-aomini的均值在600ms&＃xff0c;而react-redux在800ms上下。此后&＃xff0c;数量级规模越大&＃xff0c;差距拉开也加大&＃xff0c;十万级调用中&＃xff0c;react-redux均值在13s以上&＃xff0c;比react-aomini耗时多出将近6s。 从以上实验结果可以得出&＃xff0c;react原生是最快的&＃xff0c;而披上了一件毛皮大衣的react-redux意料之中垫了底&＃xff0c;react-aomini披上一件小背心轻装上阵&＃xff0c;性能还是可喜的。 所以以上可以得出两个结论&＃xff1a; 1、react-aomini性能没有问题&＃xff0c;可以放心投入生产&＃xff1b; 2、毕竟十万级的模块数量的大工程本来已经不多了&＃xff0c;况且是同时对所有模块进行更新就更加不可能了&＃xff0c;所以react-redux即使披了件大外衣很重&＃xff0c;但并没有太影响它的机能&＃xff0c;所以选用哪个框架&＃xff0c;性能问题可以不用过多关注啦。 实验结果摆在这了&＃xff0c;秒杀react-redux&＃xff0c;react-aomini还是没有问题滴&＃xff0c;毕竟小巧玲珑还是有一定优势的。 不过作为开发者不能盲目吹嘘&＃xff0c;这个项目不是为了跟react-redux进行pk而生的&＃xff0c;是为了解决react-redux开发路径过长的问题&＃xff0c;适用于微小型的项目&＃xff0c;这个设计初衷只是便于状态的管理&＃xff0c;为了保持微小项目的灵活性和开发便捷性&＃xff0c;大型项目还是不太适用的&＃xff0c;容易造成代码的不清晰。 好了&＃xff0c;代码会进行持续优化&＃xff0c;感兴趣的话就持续关注吧。