作者 |?馬可 ? ? ?

小程序編譯器是百度開(kāi)發(fā)者工具中的編譯構(gòu)建模塊，用來(lái)將小程序代碼轉(zhuǎn)換成運(yùn)行時(shí)代碼。舊版編譯器由于業(yè)務(wù)發(fā)展，存在編譯慢、內(nèi)存占用高的問(wèn)題，我們對(duì)編譯器做了一次大規(guī)模的重構(gòu)，采用自研架構(gòu)，做了多線程、代碼緩存、sourcemap 等多項(xiàng)優(yōu)化，在性能和內(nèi)存占用上都有很大提升。全文介紹了新版編譯器的設(shè)計(jì)思路和優(yōu)化方法，以及一些能夠用在通用打包工具里的技術(shù)點(diǎn)。? ?

01

前言

小程序編譯器在小程序開(kāi)發(fā)、預(yù)覽、發(fā)布各個(gè)階段都需要使用，因此編譯器性能會(huì)直接影響到開(kāi)發(fā)者開(kāi)發(fā)效率，也會(huì)影響到開(kāi)發(fā)者工具的使用體驗(yàn)。 由于舊版的編譯器（基于 webpack4）在構(gòu)建大型項(xiàng)目時(shí)會(huì)很慢，內(nèi)存占用也高，一直被開(kāi)發(fā)者吐槽。我們經(jīng)過(guò)大量的調(diào)研和開(kāi)發(fā)，最后采用完全自研架構(gòu)做新編譯，針對(duì)小程序項(xiàng)目構(gòu)建做了大量?jī)?yōu)化，基本解決了舊編譯存在的問(wèn)題。 下圖是部分項(xiàng)目構(gòu)建時(shí)間對(duì)比：

新版編譯器相對(duì)于舊版實(shí)現(xiàn)了 2~7 倍的性能提升，并且支持實(shí)時(shí)編譯、熱重載等特性，內(nèi)存占用更少，構(gòu)建產(chǎn)物更優(yōu)。

下面從 框架選型、新編譯器工作原理、性能和產(chǎn)物優(yōu)化方法 等方面介紹新版編譯器的成長(zhǎng)之路。

GEEK TALK

02

框架選型

在進(jìn)行新版編譯器設(shè)計(jì)時(shí)，需要明確當(dāng)前的痛點(diǎn)問(wèn)題：性能，優(yōu)先解決性能問(wèn)題。其他新技術(shù)和新想法對(duì)編譯器有幫助的也一起實(shí)施。

舊版編譯器基于 webpack4 存在如下幾個(gè)問(wèn)題：

大型項(xiàng)目構(gòu)建速度太慢。

dev 啟動(dòng)慢、增量編譯慢，僅支持 loader 緩存，bundle 無(wú)緩存也比較慢。

基于 webpack4 做擴(kuò)展開(kāi)發(fā)，需要 patch 部分模塊才能工作，維護(hù)困難。

部分 webpack bundle 過(guò)程無(wú)法針對(duì)小程序代碼結(jié)構(gòu)進(jìn)行優(yōu)化，存在無(wú)效構(gòu)建。

新編譯的設(shè)計(jì)目標(biāo)：

更快的全量編譯速度，消除 webpack 存在的無(wú)效構(gòu)建過(guò)程。

支持全緩存，加快首次和增量編譯速度。

支持實(shí)時(shí)編譯，減少 dev 啟動(dòng)和二次編譯時(shí)間。

支持多線程編譯加速，支持頁(yè)面熱重載。

優(yōu)化產(chǎn)物結(jié)構(gòu)，減少產(chǎn)物體積。

2.1 主流構(gòu)建工具

下面介紹的是我們調(diào)研過(guò)的主流前端構(gòu)建工具，每個(gè)工具都有適用場(chǎng)景和優(yōu)缺點(diǎn)。

在新版本編譯器架構(gòu)設(shè)計(jì)時(shí)，其他構(gòu)建工具的設(shè)計(jì)理念和技術(shù)特點(diǎn)都值得參考。

Webpack 構(gòu)建過(guò)程：

Webpack 優(yōu)點(diǎn)：功能完善、社區(qū)活躍、可配置性強(qiáng)、有很強(qiáng)的擴(kuò)展性。

Webpack 缺點(diǎn)：配置復(fù)雜、構(gòu)建速度慢，二次開(kāi)發(fā)困難。

Parcel 構(gòu)建過(guò)程：

Parcel 優(yōu)點(diǎn)：無(wú)需配置，構(gòu)建速度快，原生支持多線程和全緩存，多線程之間共享數(shù)據(jù)通過(guò) lmdb 進(jìn)行，避免跨線程通信開(kāi)銷(xiāo)。

Parcel 缺點(diǎn)：生態(tài)小，自定義性有限，大量采用 Node 插件，兼容性也差一些。

Vite 構(gòu)建過(guò)程：

Vite 優(yōu)點(diǎn)：配置較為簡(jiǎn)單，按需編譯，啟動(dòng)快，dev 時(shí)有不錯(cuò)的體驗(yàn)。

Vite 缺點(diǎn)：生態(tài)小，dev 和 發(fā)布走兩套構(gòu)建流程。

其他小程序平臺(tái)：

微信基于 gulp 和 C++?模塊做小程序構(gòu)建，并且對(duì) npm 模塊做了預(yù)構(gòu)建，在性能和開(kāi)發(fā)體驗(yàn)上做的比較好。

支付寶基于 webpack 做小程序構(gòu)建，并且使用了 esbuild 加速代碼壓縮。

抖音小程序使用自研編譯器，構(gòu)建流程比較簡(jiǎn)單。

2.2 新版編譯器

在設(shè)計(jì)新編譯框架時(shí)，借鑒了主流打包工具的工作流程，結(jié)合小程序代碼特點(diǎn)，決定不做通用打包工具，重點(diǎn)優(yōu)化小程序打包性能。

最終選擇了自研編譯器的方案，并做了大量?jī)?yōu)化工作，新版編譯器優(yōu)化點(diǎn)有如下幾個(gè)方面：

1.支持多 Compiler 協(xié)同工作，將動(dòng)態(tài)庫(kù)開(kāi)發(fā)等多類(lèi)型項(xiàng)目構(gòu)建解耦。

2.編譯階段全流程緩存，節(jié)省二次構(gòu)建時(shí)間 90% 以上。

3.dev 開(kāi)發(fā)默認(rèn)采用按需編譯，提升單頁(yè)編譯性能。

4.支持 babel 和 swc 多線程編譯，提升全量編譯速度 2 ~ 7 倍。

5.采用新版 sourcemap 協(xié)議，移除非必要解析合并，將 bundle 階段耗時(shí)大幅縮減。

6.對(duì) js、css、swan 模板編譯均做了構(gòu)建時(shí)標(biāo)記優(yōu)化，減少 bundle 合并耗時(shí)。

7.對(duì)于預(yù)覽、發(fā)布階段的 js 壓縮和混淆，采用了 terser 和 esbuild 并行方案，esbuild 用于快速打出預(yù)覽包，terser 可以保證壓縮率用于發(fā)布包。

從結(jié)果看，新編譯器從速度、資源占用和可維護(hù)性上相對(duì)于舊版都有顯著的提升。

GEEK TALK

03

新版編譯器工作原理

新編譯器的處理流程和 parcel 比較類(lèi)似，Compiler 控制處理流程，Processor 進(jìn)行代碼轉(zhuǎn)換，基本流程如下：

其中幾個(gè)重要的模塊：

CompileEntry 編譯器為入口模塊，包含 cli 通信、dev server 通信、命令調(diào)用等。

CompileManager 為編譯管理器，用于依賴(lài)資源下載和管理以及多個(gè) Compiler 協(xié)同構(gòu)建。

Compiler 為編譯器模塊，用于將項(xiàng)目源碼編譯成運(yùn)行時(shí)代碼，項(xiàng)目構(gòu)建時(shí) Compiler 可能有多個(gè)。

Processor 為單元處理器，用于處理 代碼轉(zhuǎn)換、代碼合并 等單個(gè)編譯任務(wù)。

注：小程序 App 項(xiàng)目有 1 個(gè)Compiler，動(dòng)態(tài)庫(kù)和動(dòng)態(tài)擴(kuò)展項(xiàng)目 2 個(gè)Compiler。

3.1 Compiler 編譯器

用于編譯單個(gè)小程序項(xiàng)目，將開(kāi)發(fā)者原始代碼編譯為可運(yùn)行代碼。

工作職能：

1.創(chuàng)建運(yùn)行上下文，提供 config、fs 文件處理、watcher 監(jiān)控、logger 等模塊，給 Processor 使用。

2.全量編譯、文件變更時(shí)二次編譯；這里二次編譯也是走一遍全量編譯流程，不過(guò)大部分用的是緩存結(jié)果。

3.管理、調(diào)度、運(yùn)行 Processor 處理單元。

4.維護(hù) Processor 依賴(lài)關(guān)系和結(jié)果緩存。

特點(diǎn)：

1.實(shí)現(xiàn)全流程緩存，將每個(gè) Processor 的輸入?yún)?shù)、輸出結(jié)果寫(xiě)入緩存，在有緩存情況下二次編譯時(shí)長(zhǎng)可減少 90% 。

2.支持按需編譯，每次按需單頁(yè)編譯、增量編譯、全量編譯 都走同樣的 Processor 處理流程。

3.通過(guò) Proxy 機(jī)制自動(dòng)計(jì)算緩存參數(shù)依賴(lài)，不用手動(dòng)為每個(gè) Processor 生成緩存 hash，相對(duì)于 webpack 或 parcel 減少 bug 產(chǎn)生。

4.僅維護(hù) Processor 依賴(lài)關(guān)系，不維護(hù) ModuleGraph，簡(jiǎn)化處理流程。

關(guān)于全流程緩存每家打包器都有自己的實(shí)現(xiàn)方案，基本原理是根據(jù)當(dāng)前輸入?yún)?shù)和依賴(lài)情況為處理單元生成一個(gè)唯一 hash，hash 一致則結(jié)果一致。

webpack 和 parcel 由于維護(hù)了 ModuleGraph，緩存的計(jì)算和重用會(huì)復(fù)雜一些。小程序編譯器僅根據(jù) Processor 入?yún)⒑驼{(diào)用依賴(lài)進(jìn)行計(jì)算。

3.2?Processor 單元處理器

Processor 有如下特性：

1.在輸入?yún)?shù)一致的情況下，保證輸出一致，輸入和輸出都必須可序列化為 json ，實(shí)現(xiàn)了 Processor 全緩存。

2.Processor 中的 uri 為構(gòu)建 ID，在單次構(gòu)建過(guò)程中 ID 一致則處理結(jié)果一致，例如處理 app.js 文件，uri 為：js:app.js，好處是可以統(tǒng)一 Processor 資源處理路徑。

3.Processor 之間支持互相調(diào)用：processWith 調(diào)用并繼續(xù)執(zhí)行，processWithResult 調(diào)用并等待返回結(jié)果。

注意：這里的輸入?yún)?shù)包含 uri、app config, contextFreeData。

幾種常用的 Processor：

1.JS Processor 將 es6 代碼轉(zhuǎn)換成 es5 代碼，這是最耗時(shí)的模塊。

2.Swan Processor 將 swan 模板代碼轉(zhuǎn)換成 view 層 js 代碼。

3.Css Processor 使用 postcss 處理 css 中的單位轉(zhuǎn)換、依賴(lài)收集等工作。

4.Bundle Processor 將前面 transformer 處理結(jié)果按照 bundle 算法合并文件并輸出結(jié)果。

Processor 工作流程：

Processor 處理流程需要經(jīng)過(guò) transform -> bundle 的過(guò)程，在小程序里 js, css, swan 模板的 bundle 可以分開(kāi)并行處理，這里和 webpack 的處理模式不一樣，和 parcel 的 pipeline 類(lèi)似。

3.3?性能和產(chǎn)物優(yōu)化方法

3.3.1 多核心編譯優(yōu)化

由于 Node 中多線程模塊初始化速度和通信效率比多進(jìn)程好一些，新編譯選擇使用 多線程 做多核心優(yōu)化。

多線程編譯有 2 種方案選擇：

方案1：基于 processor 做多線程調(diào)度，由于 processor 間支持相互調(diào)用，實(shí)際處理會(huì)很復(fù)雜且有通信成本。

舊的編譯器做過(guò)基于webpack 的 workerthread-loader，性能提升有限（10%~15%）。

parcel 基于 lmdb 公共緩存消除線程間通信，保證讀寫(xiě)效率，是一個(gè)比較好的解決方法。

方案2：僅對(duì) js 轉(zhuǎn)譯做多線程調(diào)度，僅有一來(lái)一回 2 次通信成本。

使用 jest-worker 和 babel transform 做 js 多線程轉(zhuǎn)譯或者用 swc 多線程做 js 轉(zhuǎn)譯。

由于大部分構(gòu)建時(shí)間在 js 轉(zhuǎn)譯這里（js 中有大量 node_modules 依賴(lài)，均需要轉(zhuǎn)換），css 和 swan 模塊轉(zhuǎn)換耗時(shí)少。

最終選擇方案2 僅做 js 多線程轉(zhuǎn)譯，處理流程簡(jiǎn)單且收益較好，整體提升如下：

使用 jest-worker 多線程 babel 轉(zhuǎn)譯，4 線程可提升 1 倍以上速度。

使用 swc 做 js 轉(zhuǎn)譯，4 線程提升 4 倍以上速度。

JS Processor 多線程處理：

其中：

uri：?為處理器構(gòu)建 ID

contextFreeData：?單次構(gòu)建中不可變數(shù)據(jù)，例如 app.json 中的配置項(xiàng)

context args：全局參數(shù)，例如優(yōu)化實(shí)驗(yàn)開(kāi)關(guān)、多線程開(kāi)關(guān)等

在 js 轉(zhuǎn)換處理時(shí)規(guī)定了 transformer 統(tǒng)一轉(zhuǎn)換接口，基于接口實(shí)現(xiàn)了 babel 單線程、babel 多線程、swc 轉(zhuǎn)換 3 種處理器，并且可隨時(shí)做處理器切換。

對(duì)于不同的編譯環(huán)境可以做到靈活設(shè)置：

1.開(kāi)發(fā)者工具中開(kāi)發(fā)者根據(jù)機(jī)器配置情況可以切換 多線程、swc 編譯模式，提升效率。

2.云編譯流水線默認(rèn)開(kāi)多線程編譯提高性能。

3.webIDE 默認(rèn)開(kāi)單線程降低資源消耗。

3.3.2 SWC 編譯優(yōu)化

新編譯器多線程模式相對(duì)于舊編譯提升了 1 倍左右，在 dev 開(kāi)發(fā)時(shí)一些大型項(xiàng)目頁(yè)面首次編譯還是有些慢，需要10秒以上，主要耗時(shí)在 js transform 這里。

swc 目前在 js 轉(zhuǎn)譯上基本成熟了，且大部分場(chǎng)景能提升 4 倍以上轉(zhuǎn)譯速度，因此增加了 swc 多線程轉(zhuǎn)譯支持，將大型項(xiàng)目頁(yè)面首次編譯控制在了 5 秒以?xún)?nèi)。

需要編寫(xiě) 2 個(gè) swc 插件來(lái)適配 swc 轉(zhuǎn)譯：

@swanide/swc-require-rename 將 require/import/export 中的模塊提取路徑信息，以便于后續(xù)在 js 中分析模塊依賴(lài)關(guān)系。

@swanide/swc-web-debug 對(duì) js 代碼進(jìn)行插樁處理，用來(lái)支持真機(jī)調(diào)試中的斷點(diǎn)調(diào)試。

swc 編譯帶來(lái)的性能提升是巨大的，在使用中也發(fā)現(xiàn)了一些問(wèn)題：

1.swc 存在內(nèi)存泄露，在 dev 階段如果全量編譯次數(shù)過(guò)多，會(huì)導(dǎo)致內(nèi)存占用很高，需手動(dòng)重啟編譯器。

2.swc 插件支持的 api 較少，一部分 babel 容易實(shí)現(xiàn)的功能，在 swc 中很難處理。

3.swc 由于使用 rust 編寫(xiě)插件，插件在不同 @swc/core 版本間不能通用，需要為不同平臺(tái)生成 swc 插件，在部署上會(huì)麻煩一些。

在實(shí)際使用中，對(duì)于一部分 swc 不能很好處理的場(chǎng)景，會(huì)降級(jí)到 babel 處理。

3.3.3 代碼壓縮和運(yùn)行時(shí)緩存

在 dev 階段，編譯后的代碼是沒(méi)有經(jīng)過(guò)壓縮的，可以在模擬器中運(yùn)行。在預(yù)覽發(fā)布階段由于限制了包體積，需要做代碼壓縮以減少產(chǎn)物體積。

可選的代碼壓縮工具有如下 3 個(gè)：

1.terser 壓縮率高，產(chǎn)物體積小，速度最慢。

2.swc 壓縮快，mangle 支持不完善，壓縮率較差。

3.esbuild 壓縮最快（比 terser 快了 10 倍以上），支持 mangle，代碼壓縮率不如 terser。

最后經(jīng)過(guò)對(duì)比考慮，選擇了如下壓縮方案：

1.預(yù)覽階段由于不需要 sourcemap，移除 sourcemap，并使用 esbuild 做代碼壓縮，提高預(yù)覽速度（對(duì)于自動(dòng)預(yù)覽場(chǎng)景有很大提升）。

2.發(fā)布階段使用 terser 做多線程壓縮，并保留 sourcemap。

運(yùn)行時(shí)緩存 指的是構(gòu)建過(guò)程的中間結(jié)果都在內(nèi)存中做了緩存，包括 Processor 處理結(jié)果 和 代碼壓縮結(jié)果，在二次構(gòu)建時(shí)可以節(jié)省大部分重新構(gòu)建時(shí)間。由于緩存中保留的是字符串和 json 對(duì)象，相對(duì)于基于 webpack 的舊版編譯器有 40% ~ 60% 的內(nèi)存節(jié)省，在內(nèi)存占用上處于可接受范圍。

3.3.4 Swan 模板處理優(yōu)化

舊的 swan 模板處理使用 swan-loader 進(jìn)行模板轉(zhuǎn)換，由于設(shè)計(jì)時(shí)沒(méi)有處理好模板 import 作用域，導(dǎo)致