Prepack 介绍（译）

共计 11750 个字符，预计需要花费 30 分钟才能阅读完成。

原文：A Gentle Introduction to Prepack (Part 1) 内容更新至：2018-12-24

注意：计划在当前指南更完善后，将其引入 Prepack 文档中。目前我以 gist 方式发布，以便收集反馈。

Prepack 介绍（第一部分）
如果你在开发 JavaScript 应用，那么对如下这些将 JavaScript 代码转为等价代码的工具应该比较熟悉：

Babel 让你能够使用更新的 JavaScript 语言特性，输出兼容老的 JavaScript 引擎的等价代码。

Uglify 让你能够编写可读的 JavaScript 代码，输出完成相同功能但是字节数更少的混淆代码。

Prepack 是另一个致力于将 JavaScript 代码编译为等价代码的工具。但与 Babel 或 Uglify 不同的是，Prepack 的目标不是新特性或代码体积。
Prepack 让你编写普通的 JavaScript 代码，然后输出执行地更快的等价代码。
如果这听起来让人兴奋，那么接下来你会了解到 Prepack 是如何工作的，以及你可以怎样让它做得更好。
这个指南有什么？
就我个人而言，当我最终理解 Prepack 能做什么时，我非常兴奋。我认为在未来，Prepack 会解决目前我在开发大型 JavaScript 应用时遇到的很多问题。我很想传播这一点，让其他人也兴奋起来。
不过，向 Prepack 贡献力量在一开始会让人害怕。它的源码里有很多我不熟悉的术语，我花了很长时间才明白 Prepack 做了什么。编译器相关代码倾向于使用确定的计算机科学术语，但这些术语让它们听起来比实际情况要复杂。
我编写这个指南，就是为了那些没有计算机科学背景，但对 Prepack 的目标感兴趣，并且希望帮助它实现的 JavaScript 开发者。
本指南就 Prepack 如何工作提供了高度的概括，给你参与的起点。Prepack 中的很多概念直接对应到那些你日常使用的 JavaScript 代码工具：对象、属性、条件和循环。即使你还不能在项目中使用 Prepack，你也会发现，在 Prepack 上的工作，有助于增强你对每天编写的 JavaScript 代码的理解。
在我们深入之前 ????
注意，Prepack“还没有为主流做好准备”。你还不能把它像 Babel 或 Uglify 那样嵌入到构建系统中，并期望它能正常工作。相反，你得把 Prepack 视作你可以参与的正在进行中且有雄心壮志的试验，并且在未来它会对你有用。由于其目标很广，所以有很多机会可以参与进来。
不过，这并不意外着 Prepack 不能工作。但由于其目前只关注于特定的一些场景，而且在生产环境中很可能会有让人不能接受的过多 bug。好消息是你可以帮助 Prepack 支持更多用例，以及修复 bug。这个指南会帮助你开始。
Prepack 基础
让我们重新审视上面提到的 Prepack 的目标：
Prepack 让你编写普通的 JavaScript 代码，输出等价但执行更快的 JavaScript 代码。
为什么我们不直接编写更快的代码呢？我们可以尝试，如果可以的话也的确应该。但是，在很多应用中，撇开由性能工具识别出的瓶颈，其实并没有很多明显可以优化的地方。
通常并没有单独一处导致程序变慢；相反，程序忍受的是“千刀万剐”。那些提升关注分离的特性，例如函数调用、分配对象和各种抽象，在运行时吃掉了性能。然而，在源码中移除这些会导致难以维护，而且也并没有我们可以应用的容易的优化方式。甚至 JavaScript 引擎在多年的优化工作中也有所限制，特别是在初始化只执行一次的代码上。
最明确的提升性能的方式，是少做一些事情。Prepack 根据这个理念引出其逻辑结论：它在构建阶段执行程序以了解代码将要做什么，然后生成等价的代码，但是减少了计算量。
这听起来太奇幻，所以我们来看一些例子，了解 Prepack 的优势和限制。我们会使用 Prepack REPL 来在线对一段代码应用 Prepack。
计算 2 + 2 的两种方式
让我们先打开这个例子：
(function() {
var x = 2;
var y = 2;
global.answer = x + y;
})();
输出为：
answer = 4;
实际上，运行两个代码片段产生相同的效果：值 4 被赋值到名为 answer 的全局变量上。不过 Prepack 的版本并没有包含 2 + 2 的计算。不同的是，Prepack 在编译阶段执行 2 + 2，并将最终的赋值操作进行了“序列化（serialize）”（“写入”或“生成”的一种花哨的说法）。
这并没有特别厉害：例如，Google Closure Compiler 也能将 2 + 2 变为 4%2520%257B%250A%2520%2520var%2520x%2520%253D%25202%253B%250A%2520%2520var%2520y%2520%253D%25202%253B%250A%2520%2520global.answer%2520%253D%2520x%2520%252B%2520y%253B%250A%257D)()%253B)。这种优化被称作“常量折叠（constant folding）”。Prepack 的不同在于，它能执行任意 JavaScript 代码，不仅仅是常量折叠或类似的有限优化。Prepack 也有其自身的限制，我们一会再说。
考虑如下这种有意编写的超级绕的计算 2 + 2 的情况：
(function() {
function getNumberCalculatorFactory(injectedServices) {
return {
create() {
return {
calculate() {
return injectedServices.operatorProvider.operate(
injectedServices.xProvider.provideNumber(),
injectedServices.yProvider.provideNumber()
)
}
};
}
}
}

function getNumberProviderService(number) {
return {provideNumber() {return number;} };
}

function createPlusOperatorProviderService() {
return {operate(x, y) {return x + y;} };
}

var numberCalculatorFactory = getNumberCalculatorFactory({
xProvider: getNumberProviderService(2),
yProvider: getNumberProviderService(2),
operatorProvider: createPlusOperatorProviderService(),
});

getAnswer = _0;
})();
看起来好像 Prepack 并没有优化我们的计算！为什么会这样？
缺省情况下，Prepack 只优化“初始化路径”（立即执行的代码）。
从 Prepack 的角度来看，Prepack 执行了所有语句后程序已经结束。程序的效果以全局变量 getAnswer 对应的函数所记录。工作已经结束。
如果我们在退出程序前调用 getAnswer()，Prepack 会执行它。getAnswer() 的实现是否存在于输出，取决于函数本身对于全局对象是否“可触及”（所以忽略它会不安全）。生成到输出中的函数，被称为“残留函数”（它们是在输出中“残留的”，或者剩下的）。
缺省情况下，Prepack 不会尝试执行或优化残留函数。这通常是不安全的。在残留函数被外部代码调用的时候，JavaScript 运行时全局对象如 Object.prototype，以及由输入代码创建的对象都可能会被修改，这超出了 Prepack 的感知范围。这时 Prepack 可能要使用残留堆中的旧值，再与原始代码中的行为进行比对，或者始终假设任何东西都会修改，这都让优化变得过于困难。哪种方案都不会让人满意，所以残留函数保持原样。
不过有个试验模式，可以让你选择优化特定函数，这个后面会提到。
速度 vs. 体积开销
考虑这个例子：
(function () {
var x = 2;
var y = 2;

function getAnswer() {
return x + y;
};

global.getAnswer = getAnswer;
})();

Prepack 生成如下代码，在输出中保持 getAnswer() 为残留函数：
(function () {
var _0 = function () {
return 2 + 2;
};

getAnswer = _0;
})();
注意 getAnswer() 并没有被优化，因为它是残留函数，在初始化阶段没有被执行。运算 + 还是在那里。我们可以看到 2 和 2 替换了 x 和 y，这是由于它们在程序运行期间没有改变，所以 Prepack 将其视为常量。
如果我们动态生成一个函数，再将其添加到全局对象上呢？例如：
(function() {
function makeCar(color) {
return {
getColor() { return color;},
}
};
global.cars = [‘red’, ‘green’, ‘blue’, ‘yellow’, ‘pink’].map(makeCar);
})();
这里，我们创建了多个对象，每个对象都包含一个 getColor() 函数，返回传入 makeCar() 的不同值。Prepack 像这样输出：
(function () {
var _2 = function () {
return “red”;
};

var _5 = function () {
return “green”;
};

var _8 = function () {
return “blue”;
};

var _B = function () {
return “yellow”;
};

var _E = function () {
return “pink”;
};

cars = [{
getColor: _2
}, {
getColor: _5
}, {
getColor: _8
}, {
getColor: _B
}, {
getColor: _E
}];
})();
注意输出是怎样的，Prepack 并没有保持抽象的 makeCar()。相反，它执行了 makeCar() 调用，并将返回的函数进行了序列化。这也是为什么输出结果中有多个 getColor()，每个 Car 对象一个。
这个例子也展示了 Prepack 优化运行时性能，但可能有字节体积上的代价。JavaScript 引擎执行 Prepack 生成的代码会更快，因为它不必执行函数调用并初始化所有的内嵌闭包。但是，生成的代码可能会比输入代码更大 —— 有时候非常明显。
这种“代码爆炸”有助于发现初始化阶段哪些代码做了过多的昂贵的元编程（metaprogramming），但也让 Prepack 很难用于对打包后体积敏感的项目中（例如 web 项目）。今天，最简单的处理“代码爆炸”的方法是延迟运行这些代码将其移入残留函数中，这样就从 Prepack 的执行路径中移除了。当然，这种情况下 Prepack 也就无法优化它。在未来，Prepack 可能会有更好的启发，进而对速度和体积开销有更好的控制。
延迟闭包初始化
在上一个例子中，color 值被内联到残留函数中，因为它们是常量。但如果闭包中的 color 值会改变呢？考虑如下的例子：
(function() {
function makeCar(color) {
return {
getColor() { return color;}, // 读取 color
paint(newColor) {color = newColor;}, // 修改 color
}
};
global.cars = [‘red’, ‘green’, ‘blue’].map(makeCar);
})();
现在 Prepack 不能直接生成一系列包含类似 return “red” 语句的 getColor() 函数，因为外部代码会通过调用 paint(newColor) 改变颜色。
这是上面场景生成的代码：
(function () {
var __scope_0 = Array(3);

var __scope_1 = function (__selector) {
var __captured;
switch (__selector) {
case 0:
__captured = [“red”];
break;
case 1:
__captured = [“green”];
break;
case 2:
__captured = [“blue”];
break;
default:
throw new Error(“Unknown scope selector”);
}

__scope_0[__selector] = __captured;
return __captured;
};

var $_0 = function (__scope_2) {
var __captured__scope_2 = __scope_0[__scope_2] || __scope_1(__scope_2);
return __captured__scope_2[0];
};

var $_1 = function (__scope_2, newColor) {
var __captured__scope_2 = __scope_0[__scope_2] || __scope_1(__scope_2);
__captured__scope_2[0] = newColor;
};

var _2 = $_0.bind(null, 0);
var _4 = $_1.bind(null, 0);
var _6 = $_0.bind(null, 1);
var _8 = $_1.bind(null, 1);
var _A = $_0.bind(null, 2);
var _C = $_1.bind(null, 2);

cars = [{
getColor: _2,
paint: _4
}, {
getColor: _6,
paint: _8
}, {
getColor: _A,
paint: _C
}];
})();
这看起来非常复杂！我们来看看是怎么回事。
注意：如果你一直搞不明白这一节也是完全没关系的。我也是在开始写这一节的时候才搞明白。
可能从下往上读更容易些。首先，我们可以看到 Prepack 仍然没有保留 makeCar()，而是将零碎的对象手动拼起来以避免函数调用和闭包创建。每个函数实例是不同的：
cars = [{
getColor: _2, // redCar.getColor
paint: _4 // redCar.paint
}, {
getColor: _6, // greenCar.getColor
paint: _8 // greenCar.paint
}, {
getColor: _A, // blueCar.getColor
paint: _C // blueCar.paint
}];
这些函数从哪里来的？Prepack 在上面声明了：
var _2 = $_0.bind(null, 0); // redCar.getColor
var _4 = $_1.bind(null, 0); // redCar.paint

var _6 = $_0.bind(null, 1); // greenCar.getColor
var _8 = $_1.bind(null, 1); // greenCar.paint

var _A = $_0.bind(null, 2); // blueCar.getColor
var _C = $_1.bind(null, 2); // blueCar.paint
可以看到被绑定的函数（$_0 和 $_1）对应 car 的方法（getColor 和 paint）。Prepack 对所有实例使用复用相同的实现。
不过，这些函数得知道是三个独立修改的颜色中的哪一个。Prepack 得知道如何有效模拟 JavaScript 闭包但不创建嵌套函数。
为了解决这个问题，bind() 的参数（0、1 和 2）给了提示，表示哪个颜色在被函数“捕获”。在例子中，颜色号 0 初始为 ‘red’，颜色号 1 开始是 ‘green’，2 开始是 ‘blue’。当前颜色保存在数组中，在这个函数之后初始化：
var __scope_0 = Array(3); // index -> color 映射

var __scope_1 = function (__selector) {// __selector 为索引
var __captured;
switch (__selector) {
case 0:
__captured = [“red”];
break;
case 1:
__captured = [“green”];
break;
case 2:
__captured = [“blue”];
break;
default:
throw new Error(“Unknown scope selector”);
}

__scope_0[__selector] = __captured; // 在数组中保存初始值
return __captured;
};
在上面代码中，__scope_0 是数组，Prepack 用于记录颜色所以到颜色值的对应关系。__scope_1 是函数，向数组特定索引设置初始颜色。
最终，所有 getColor() 的实现从颜色数组中读取颜色值。如果数组不存在，则通过调用函数来初始化。
var $_0 = function (__scope_2) {
var __captured__scope_2 = __scope_0[__scope_2] || __scope_1(__scope_2);

return __captured__scope_2[0];
};
类似地，paint() 确保数组存在，然后写入。
var $_1 = function (__scope_2, newColor) {
var __captured__scope_2 = __scope_0[__scope_2] || __scope_1(__scope_2);

__captured__scope_2[0] = newColor;
};
为什么都有 [0]，为什么向数组写入 [“red”] 而不是直接存储颜色？每个闭包可能包含不只一个变量，所以 Prepack 使用额外的数组层级来引用它们。在我们的例子中，color 是闭包中唯一的变量，所以 Prepack 使用了单元素的数组来保存。
你可能注意到输出的代码有点长。这在经过压缩后会好些。目前，序列化器的这一部分，专注于正确性而非更有效率的输出。
更可能地是，输出可以逐步进行优化，所以如果你发现有更好的优化方案，不要犹豫，直接提交 issue。在一开始，Prepack 并没有生成可以延迟分配闭包的代码。相反，所有捕获的变量都被提升并初始化到输出的全局代码中。这也是一个速度与代码体积的交换，逐渐会有所变化。
环境影响
这个时候，你可能想试着复制粘贴一些现有代码到 Prepack REPL 中。不过，你很快就会发现像 window 或 document 这样的浏览器基础特性，或者 Node 的 require，并不能如你所想地工作。
例如，React DOM 包含如下的特性检查代码，这个 Prepack 不能编译：
var documentMode = null;
if (‘documentMode’ in document) {
documentMode = document.documentMode;
}
错误信息为：
PP0004 (2:23): might be an object that behaves badly for the in operator
PP0001 (3:18): This operation is not yet supported on document at documentMode
A fatal error occurred while prepacking.
多数 Prepack 的错误码对应有错误描述的 Wiki 页面。例如，这是与 PP0004 对应的页面。（另一个 PP0001 错误来自老的错误系统，你可以帮忙进行迁移）
所以为什么上面的代码不能工作？为了回答这个问题，我们需要回顾 Prepack 的工作原理。为了执行代码，Prepack 需要知道不同的值等于什么。而有的东西只在运行时才知道。
Prepack 无法知道代码在浏览器中运行时的情况，所以它不能确定是应该安全地为 document 对象应用 in 运算符，还是应该抛出异常（如果上面有 try / catch，这会是一个潜在的不同的代码路径）。
这听起来很槽糕。不过，初始化代码从环境中读取一些在构建阶段不清楚的东西是很常见的。对此有两种方法。
一种是只对不依赖外部数据的代码应用 Prepack，把任何环境检测的代码放到 Prepack 以外。对于可以比较容易分离的代码，这是合理的策略。
另一种解决方法是使用 Prepack 最强大的特性：抽象值。
在下一节中，我们会深入了解抽象值，不过当前 gist 没有这样的例子。Prepack 可以在不知道某些表达式的具体值的情况下执行代码，你可以为 Node 或浏览器 API 或其他未知的输入提供进一步的提示。
待续
我们涉及了 Prepack 工作原理的基础部分，但还没有探讨更有趣的特性：

手动优化选择的残留函数
在某些值未知情况下执行代码
Prepack 如何“连接”函数执行流
使用 Prepack 查看变量可以接收的所有值
试验性的 React 编译模式
本地检出 Prepack 并调试

我们会在下一篇文章中探索这些话题。

Prepack 介绍（译）

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）