Visual Studio Code 最近將其內(nèi)置的 JavaScript 大小減少了 20%，節(jié)省了超過 3.9 MB。這種減少不僅降低了下載和存儲需求，而且由于在運行 JavaScript 之前需要掃描的源代碼更少，因此也提高了啟動速度。這個減小是通過一個新的構建步驟 “名稱混淆壓縮” 實現(xiàn)的，而非刪除任何代碼或進行重大重構。

?

workbench.js 隨時間變化大小，右側兩個下降點：VS Code 1.74 第一大跌幅結果來源于混淆壓縮私有屬性，VS Code 1.80 第二小跌幅來源于混淆壓縮 export。

混淆壓縮私有屬性

混淆壓縮源碼后 JavaScript 仍包含許多長標識符名稱如 extensionIgnoredRecommendationsService。作者本來以為 esbuild 已經(jīng)將這些標識符簡化了，比如：

const someLongVariableName = 123;

console.log(someLongVariableName);

變?yōu)楦痰模?/p>

const x = 123;

console.log(x);

由于 JavaScript 以源文本形式發(fā)布，減少標識符名稱的長度實際上可以減小程序的大小。這種優(yōu)化可能看起來有些荒謬，但在 JavaScript 世界里確實頂瓜瓜。

盡管 esbuild 實現(xiàn)了混淆功能，默認情況下只有當確定混淆不會改變代碼行為時才對名稱進行處理。

因此，在實踐中，esbuild 只對局部變量名和參數(shù)名進行處理。

也就是說，esbuild 這種保守策略意味著許多無法確認是否安全修改名稱被忽略了。

怎么辦呢？

作者團隊最終利用 TypeScript 對混淆代碼進行驗證，正如 TypeScript 可以在常規(guī)代碼中捕獲未知的屬性訪問一樣，TypeScript 編譯器能夠捕獲到一個屬性已經(jīng)被混淆但對它的引用沒有正確更新的情況。

解決思路：可以將 TypeScript 源碼進行混淆，然后使用被改變標識符名稱的新 TypeScript 進行編譯。這種方式會使得對于是否無意間破壞了代碼有更高的把握。

同時，通過使用 TypeScript，可以真正找到所有私有屬性（而不是僅以 _ 開始的屬性），甚至還可以利用 TypeScript 的現(xiàn)有重命名功能來智能地重命名符號，而不會意外改變對象形狀。

他們提出了新的大致工作流程： 使用 TypeScript's AST 針對每個在代碼庫中發(fā)現(xiàn)的私有或受保護屬性：

如果該屬性需要被修改：

通過尋找未使用過的符號名稱計算出一個新名稱

使用 TypeScript 生成所有引用該屬性的重命名編輯 將所有重命名編輯應用于 TypeScript 源碼 編譯帶有修改過名稱的新編輯過的 Typescript 資源 結果大部分有效。

當然，也有一些例外需要處理：

當前類內(nèi)唯一性并不能滿足要求，在超類和子類之間也必須具備唯一性。根本原因是 TypeScripts 私有關鍵字只是一個編譯時裝飾器，并不能真正防止超級和子類訪問私有屬性。

如果不小心處理，則可能導致重新命名時產(chǎn)生名稱沖突（幸運地是 Typescript 將其報告為錯誤）。

在某些情況下，子類公開繼承自父類受保護權限，在很多例子里面都屬于錯誤操作，需要禁止此處進行混淆。

這樣構建成功后，混淆私有屬性后 VS Code 主要 workbench.js 文件大小從 12.3MB 降低至 10.6MB , 減少近 14%。這也帶來 5% 加載速度提高，因為需要掃描文本量減少。

混淆壓縮 export

另一方面，其實 provideWorkspaceTrustExtensionProposals 等長名字，或者 localize 函數(shù)（用于 UI 顯示字符串）明顯還有改善空間。

針對它的處理是：導出符號名稱。只要導出僅供內(nèi)部使用，就可以縮短它們而不改變代碼行為。

最終，經(jīng)過優(yōu)化，總體上文件比沒有進行名稱壓縮小了 20%。

在整個 VS Code 中，名稱壓縮從編譯源碼移除 3.9MB JavaScript 代碼，這既降低了下載大小和安裝大小，也使每次啟動 VS Code 需要掃描 JS 代碼量減少 3.9MB。

審核編輯：劉清