?????♀? 編者按：真不是標(biāo)題黨。本文作者是螞蟻集團(tuán)前端工程師有知，介紹如何更改 3 個(gè)字符，便可以實(shí)現(xiàn) 10 倍的沙箱性能提升。

確實(shí)會(huì)慢，但不多 ??

qiankun2 自發(fā)布以來(lái)，常被人詬病慢、有性能問(wèn)題。雖在大部分場(chǎng)景下，這個(gè)問(wèn)題表現(xiàn)的并不明顯，不會(huì)對(duì)應(yīng)用造成可感知的影響（2m JS 的解析約增加 200ms 耗時(shí)，單個(gè)函數(shù)調(diào)用增加耗時(shí)可忽略不計(jì)）。大部分情況下應(yīng)用渲染慢，真的就是因?yàn)槟愕?JS 太大（一個(gè)不分片的超大的 bundle），接口響應(yīng)太長(zhǎng)，UI 不夠有「彈性」導(dǎo)致的。

但在面臨一些 CPU 密集型的 UI 操作時(shí)，如圖表、超量 DOM 變更（1000以上）等場(chǎng)景，確實(shí)存在明顯的卡頓現(xiàn)象。所以我們也不好反駁什么，通常的解決方案就是推薦用戶關(guān)閉沙箱來(lái)提升性能。

去年底我們?cè)鴩L試過(guò)一波優(yōu)化，雖然略有成效，但整體優(yōu)化幅度不大，因?yàn)橛幸恍┍匾L問(wèn)耗時(shí)省不掉，最終以失敗告終。

重啟優(yōu)化之路 ??

近期有社區(qū)用戶又提到了這個(gè)問(wèn) 題，加之年初的時(shí)候「獲取」到了一些靈感，中秋假期在家決定對(duì)這個(gè)問(wèn)題重新做一次嘗試。

我們知道 qiankun 的沙箱核心思路其實(shí)是這樣的：

此前主要的性能問(wèn)題出在應(yīng)用的代碼會(huì)頻繁的訪問(wèn)沙箱，比如 Symbol.unscopables?[1]?在圖表場(chǎng)景很容易就達(dá)到千萬(wàn)級(jí)次的訪問(wèn)。

優(yōu)化的思路也很簡(jiǎn)單，就是要減少全局變量在 proxy 里的 lookup 次數(shù)。比如可以先緩存起來(lái)，后續(xù)訪問(wèn)直接走作用域里的緩存即可：

看上去很完美，不過(guò)手上沒(méi)有 windows 設(shè)備沒(méi)法驗(yàn)證（M1性能太強(qiáng)測(cè)不出來(lái)），于是先提了個(gè) pr?[2]。

驗(yàn)證 ??

假期結(jié)束來(lái)公司，借了臺(tái) windows 設(shè)備，驗(yàn)證了一下。

糟了，沒(méi)效果。優(yōu)化前跟優(yōu)化后的速度幾乎沒(méi)有變化。??

想了下覺(jué)得不應(yīng)該啊，理論上來(lái)講多少得有點(diǎn)作用才是，百思不得其解。

苦惱之際，突然好像想到了什么，于是做出了下面的修改：

改動(dòng)更簡(jiǎn)單，就是將 var 聲明換成了 const，立馬保存驗(yàn)證一把。

直接起飛！

場(chǎng)景 1：vue 技術(shù)棧下大 checkbox 列表變更

在有沙箱的情況下，耗時(shí)基本與原生框架的一致了。

場(chǎng)景 2：10000 個(gè) dom 插入/變更

在 vue 的 event handler 中做原生的 10000 次 的 for 循環(huán)，然后插入/更新 10000 個(gè) dom，記錄中間的耗時(shí)：

可以看到，這個(gè)優(yōu)化后的提升已經(jīng)不止 10 倍了，都超過(guò) 50 倍了，跟原生的表現(xiàn)基本無(wú)異。

如何做到的 ??

完成最后的性能飛躍，實(shí)際上我只改了 3 個(gè)字符，就是把 with 里的 var 換成了 const，這是為什么呢？其實(shí)我之前的這篇文章早就告訴了我答案：ES 拾遺之 with 聲明與 var 變量賦值（https://www.yuque.com/kuitos/gky7yw/mhfzh7），里面有一個(gè)重要的結(jié)論：

因?yàn)?windowProxy 里有所有的全局變量，那么我們之前使用 var 去嘗試做作用域緩存的方案其實(shí)是無(wú)效的，聲明的變量實(shí)際還是在全局的詞法環(huán)境中的，也就避免不了作用域鏈的查找。而換成 const，就可以順利的將變量寫(xiě)到 with 下的詞法環(huán)境了。

one more thing ??

至此，如果以后你的應(yīng)用在微前端場(chǎng)景下表現(xiàn)的不盡如人意，請(qǐng)先考慮：

1. 是否是應(yīng)用的打包策略不合理，導(dǎo)致 bundle 過(guò)大 js 執(zhí)行耗時(shí)過(guò)長(zhǎng)

2. 是否是前置依賴邏輯過(guò)多執(zhí)行過(guò)慢（如接口響應(yīng)），阻塞了頁(yè)面渲染

3. 是否是微應(yīng)用的加載策略不合理，導(dǎo)致過(guò)晚的加載

4. 沒(méi)有加載過(guò)渡動(dòng)畫(huà)，只有硬生生的白屏

別再試圖甩鍋給微前端了，瑞思拜??。

?? 相關(guān)鏈接

[1] https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Symbol/unscopables

[2] https://github.com/kuitos/import-html-entry/pull/82/files