腳本之家服務器常用軟件

快捷導航

分享一款超好用的JavaScript 打包壓縮工具

更新時間：2020年04月26日 09:57:23 作者：Vincent Chan 的巴士站

這篇文章主要介紹了寫一個飛快的 JavaScript 打包壓縮工具，非常好用，本文給大家分享實現思路,需要的朋友可以參考下

背景

平時大家在開發(fā) Js 項目的時候，可能已經離不開 webpack 等打包工具了。而 webpack 打包速度大概就是“能用“的水平。大概去年開始，我就開始在構想，如果能寫一個極速的打包工具，功能未必需要很強，可能對小項目非常有用。去年我用 C++ 寫完 parser 之后，便沒什么動力寫下去了。但是最近發(fā)現有這個想法的不止我一個，Figma 的 CTO 業(yè)余之際寫了一個打包器 https://github.com/evanw/esbuild ，可以說完完全全實現了我想象中的需求，不過他是用 Go 語言實現的。我看到這個項目時心里一想，這不是我去年就想做的事嗎，這 push 我趕緊把打包壓縮部分完成。

代碼

Github 地址： https://github.com/vincentdchan/jetpack.js

優(yōu)化思路

并行 Parsing

毫無疑問，每一個 js 文件的 parsing 可以在不同線程完成，這就需要支持并行的語言。由于 parsing 的結果是 AST，所以需要可以共享內存的語言（排除通過 messeage parsing 實現多線程的語言）。滿足以上兩個要求的語言不多。 Evan 選擇了 Go，我選擇了 C++。

減少遍歷次數

要想速度快，就要減少 AST 的遍歷次數。最好就是只遍歷一次來生成代碼，在 Parsing 構建 AST 的時候就收集足夠的信息。但是這也意味著只能做比較淺層次的優(yōu)化，不能做深層次的壓縮（死代碼消除，tree shaking 都做不了）。

架構

由上述思路我總結出了以下打包的架構：

并行 parse 文件
作用域提升、生成框架代碼、重命名變量
并行生成代碼
合并輸出文件

流程圖如下：

打包壓縮原理

本章節(jié)主要講如何“最簡單“地壓縮 Js 代碼。本章節(jié)假設讀者對編譯原理有一定了解，知道什么是 AST。如果不懂請直接跳到下文「性能」章節(jié)。

字面量替換

字面替換最簡單。規(guī)則有一下幾個：

undefined 替換為 void 0
true 替換為 !0 , false 替換為 !1

:warning: 注意：在 ES 中，undefined 是標識符（Identifier)，而不是關鍵字，也就是說你可以定義一個叫 undefined 的變量，所以這個時候不能簡單地替換為 void 0

常量折疊

計算簡單的運算：

var two = 1 + 1;
var foobar = 'foo' + 'bar';

轉換成

var two = 2;
var foobar = 'foobar';

:warning: 注意：這里要注意實現的平臺和 js 的差異，比如在 C++ 里面大整數相加可能會溢出，而在 Js 會自動轉換成 bigint. 加法問題就如此，其他運算符問題更多。如果要完整實現常量折疊，可能要部分實現 js 引擎。

變量別名

別名就是要給變量重新賦予比較短的變量名。從字母一直排上去，abcd，一個字母用完了用兩個字母。實現起來也很簡單，用一個計數器，一直加上去就可。最后每個變量分配一個數字，把這個數字映射到相應的英文字母上，有點像 36 進制轉換成字母的面試題。不過這里有一點值得注意的是，變量名第一個字母不能是數字，第二個字母開始可以是數字，要考慮到這一點，才能盡可能“壓榨”變量名。

為了盡可能地“壓榨”變量名，同一級的作用域里面的變量名是可以使用相同的變量名。到下一級的時候，對子作用域進行合并。

舉個例子：

function Mother() {
	var e = 'capture'; // d 不能使用跟子作用域同樣的變量名，不然子作用域無法捕獲這個變量
	function A(a, b, c, d) {
 console.log(e);
	}
	
	function B(a, b, c) { // B 跟 A 函數同級，分配同樣的變量名
	 // ...
	}
}

上述例子中，A 和 B 都沒有子作用域了，變量名從 0 開始分配。到給 Mother 下 e 分配變量名時，找到子作用域最大的計數器。分配最多的子作用域 A 分配了 4 個，所以 B 計數器從 5 開始分配，所以給 e 分配了5，所以 e 就得到了這個名字。

所以變量別名就是從 AST 的葉子開始向上構造，一直分配到根結點把所有作用域都分配完為止。

小技巧

這里 esbuild 采用了比較聰明的技巧。它統(tǒng)計了所有變量的引用次數，然后進行排序，引用次數最多的變量分配到的名字就是盡量短的，這樣也可以減少編譯出來 js 的體積。我在寫 jetpack 打包的時候，也借鑒了這種做法。

模塊合并

模塊合并的辦法有很多。webpack 采用的是用 function 把每個函數包起來，放到了一個長長的數組里面，然后實現了自己的 require，esbuild 也采用了類似的方法。

Rollup.js 實現的方法則是作用域提升（Scope hoisting），把模塊都放到根作用域。這里我采用的方法也是作用域提升。

假設有 a.js 文件：

export function A() {
 console.log('a');
}

然后有 main.js 文件：

import { A as ExternalA } from './a';

function A() {
 console.log('local A');
}

export function main() {
 A() + ExternalA();
}

使用 jetpack 打包完的結果：

// a.js
function A() {
 console.log('a');
}

// main.js
function A_0() {
 console.log('local A');
}

function main() {
 A_0() + A();
}

export { main };

難點在于作用域合并。實際上在 ES modules 里面不同 modules 之間引用是一個圖結構。

C++ 的優(yōu)化

除了策略上的優(yōu)化，C++ 還提供了諸多基礎數據結構/內存方面的優(yōu)化。

shared_ptr

AST 的結點全部使用 shared_ptr，有人可能認為這是一個很大的開銷。但是早期的時候我實現過一個裸指針版本（不釋放內存），并沒有測出有明顯差距。

使用 shared ptr 很重要一個原因是，一個子樹可能被其他類擁有（打包模塊，Scope，ES Module 管理器）。這個時候如果用 unique ptr 的話就會 gg。只能說 GC 大法好。

對于 C++ 這種沒有 GC 的語言有一個毛病就是：析構 AST 非常耗時。AST 夠大的話能耗上十幾 ms（這個時間跟 gc 比有何優(yōu)勢？），所以因此我也能想出了一個辦法： 不釋放內存 ……。

最后說一句： GC 大法好 。

robin hood hashing

由于打包器中大量使用哈希表，所以提高哈希表速度尤其重要，這里我使用了 robin hood hashing

參見： https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-01-overview/

在 hash 方面我有一個設想，就是像 Lua 一樣，對于短字符，在字符串創(chuàng)建的時候把 hash 記下來，這樣在多次使用哈希表的時候可以節(jié)省 hash 的時間（但是要求字符串是 immutable 的）。為此我專門寫了個 String 類，最后的結果是總體速度慢了 2-3x，測出來是 immutable 字符串拼接耗時太多，最后放棄了這個方案。

jemalloc

Parsing 過程中需要大量分配 node，大家都知道很明顯 C++ 的 new 并不夠快。經過測試在 macOS 下使用 jemalloc 會讓 parsing 速度提升 1 倍。使用系統(tǒng) malloc 會導致 parsing 速度比 Go 慢 1x 左右，慢在 new 。

當然了，內存池我也試過的，測出來速度基本和 jemalloc 一樣，所以就直接用 jemalloc 了。

性能