react-aomini（第三彈），贏在小巧，性能方面，幹翻react-redux仍是能夠的

到目前爲止，react-aomini最大的特色就是簡單粗暴（react-aomini是我的寫的一個談不上框架的小框架，不瞭解的能夠看看我以前寫的兩篇博文，react-redux？mobx？或許我須要更加小巧玲瓏的和小巧玲瓏的react框架（第二彈）正式命名--aomini），你們感興趣的能夠從react-aomini github簽出代碼看看，代碼寫的也沒拾掇過，見笑見笑，看個思路，簡單輕量是實現了，可是你們仍是會疑惑，那真的能投入實戰嗎，性能到底咋樣呢？實不相瞞，我我的也是比較好奇，畢竟我也沒有測試過，不過我仍是蠻有信心的，由於輕量就是不爲求全，只爲解決最尖銳的那個問題，因此最接近原生，原生確定比在外面套層外套跑的快啦，因此相信react-aomini不會太挫，不過說是這麼說，仍是要數據來講話。 爲告終果更加有參考意義，咱們就拿當下最流行的react-redux框架來進行性能對比，react-aomini和react-redux做爲實驗組，並加入react原生做爲參照組。咱們的性能測試對比主要是採用控制三個不一樣的框架做爲惟一變量進行實驗，三個實驗對象中對同一個模塊進行相同數量級的調用，分別記錄耗時數據。 接下來簡要說明一下咱們的實驗，咱們會對每一個實驗體（也就是react-aomini，react和react-redux）分別進行百級、千級、萬級以及十萬級的模塊加載，而後分別對全部模塊進行更新操做，模塊加載暫不做爲統計數據，咱們取更新操做的耗時做爲實驗數據，每組取十個數據做爲一組。爲了方便起見，我使用其中最簡單的react原生代碼進行實驗說明，代碼以下： Module1.js

class Module1 extends React.Component{
	constructor(){
		super();
		this.state = {
			moduleQuantity:900
		};
	}
	render(){
		let { moduleQuantity } = this.props;
		return (
			<div>
				<p>--------Module1---------</p>
				<input type="number" value={moduleQuantity} onChange={this.setValue.bind(this)} />
			</div>
			)
	}
	componentDidUpdate(prevProps, prevState) {
		console.log("Module1 did update")
	}
	setValue(e){
		console.log(e.target.value);
		let { setModuleQuantity } = this.props;
		setModuleQuantity(e.target.value);
	}
}
複製代碼

MoudleX.js代碼以下：

/**
* siblings2
*/
class ModuleX extends React.Component{
	constructor(){
		super();
		this.startTime = 0;
		this.state = {
			updateCount:1
		};
	}
	render(){
		let {moduleQuantity} = this.props;
		let { updateCount } = this.state;
		console.log("&&&&&&&&&&&",updateCount)
		let subNum = Number(moduleQuantity || 0);
		return (
			<div>
				<p>---------ModuleX---------</p>
				兄弟節點Module1的值:{moduleQuantity}
				<button onClick={this.updateX.bind(this)}>更新</button>
				{
					subNum <= 0 ? "":(
						Array(subNum).fill(1).map((item,i)=>{
							return (
								<SubModuleX key={i} mIndex={i+1} updateCount={updateCount} />
							)
						})
					)
				}
			</div>
			)
	}
	componentWillUpdate(nextProps, nextState) {
		this.startTime = 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 } = this.state;
		this.setState({
			updateCount:updateCount+1
		});
	}
}
複製代碼

最重要的一個實驗模塊SubModuleX代碼以下：

class SubModuleX extends React.Component{
	constructor(props) {
		super(props);
		this.state = {};
	}
	render() {
		let { mIndex, updateCount } = this.props;
		return <div>sub module {mIndex},update count:{updateCount}</div>
	}
}
複製代碼

App.js文件以下：

class App extends React.Component{
    constructor(){
        super();
        this.name = "App";
        this.state = {
            moduleQuantity:900
        }
    }
    render(){
        let {moduleQuantity} = this.state;
        console.log("moduleQuantity:",moduleQuantity)
        return (
            <div>
                <Module1 moduleQuantity={moduleQuantity} setModuleQuantity={this.setModuleQuantity.bind(this)} />
                <ModuleX moduleQuantity={moduleQuantity} />
            </div>
            )
    }
    setModuleQuantity(moduleQuantity){
        this.setState({
            moduleQuantity
        })
    }
}
複製代碼

實驗代碼如上簡要說明一下，十分簡單。其中Module1模塊主要是一個moduleQuantity的輸入框，也就是控制實驗數量的一個輸入，ModuleX模塊中獲取moduleQuantity後，對SubModuleX進行循環裝載，模塊加載完後，纔算是準備好進行實驗，這裏注意，咱們並無將模塊的加載耗時做爲實驗數據，而是將更新模塊耗時做爲實驗數據。 爲了數據更具備參考意義，這裏貼一下我實驗環境參數：mac pro，單核 i7處理器2.4GHz，8G內存，google瀏覽器最新版本61.0.3163.100。 開始咱們的實驗後，咱們只須要點擊ModuleX中的更新按鈕，全部模塊更新完畢後，會打印出每次的耗時。咱們將實驗結果記錄並繪成折線圖，結果以下：

以上結果能夠看出，在千級模塊調用內，耗時幾乎都在100毫秒內，差距並不大，在實際開發中感覺一定不明顯，可是已經一目瞭然。隨着數量級的增大，到了萬級的模塊調用，性能明顯進一步拉大，react均值在450ms，react-aomini的均值在600ms，而react-redux在800ms上下。此後，數量級規模越大，差距拉開也加大，十萬級調用中，react-redux均值在13s以上，比react-aomini耗時多出將近6s。 從以上實驗結果能夠得出，react原生是最快的，而披上了一件毛皮大衣的react-redux意料之中墊了底，react-aomini披上一件小背心輕裝上陣，性能仍是可喜的。 因此以上能夠得出兩個結論： 一、react-aomini性能沒有問題，能夠放心投入生產； 二、畢竟十萬級的模塊數量的大工程原本已經很少了，何況是同時對全部模塊進行更新就更加不可能了，因此react-redux即便披了件大外衣很重，但並無太影響它的機能，因此選用哪一個框架，性能問題能夠不用過多關注啦。 實驗結果擺在這了，秒殺react-redux，react-aomini仍是沒有問題滴，畢竟小巧玲瓏仍是有必定優點的。 不過做爲開發者不能盲目吹噓，這個項目不是爲了跟react-redux進行pk而生的，是爲了解決react-redux開發路徑過長的問題，適用於微小型的項目，這個設計初衷只是便於狀態的管理，爲了保持微小項目的靈活性和開發便捷性，大型項目仍是不太適用的，容易形成代碼的不清晰。 好了，代碼會進行持續優化，感興趣的話就持續關注吧。