认识 WebAssembly

起源

WebAssembly 起源于 Mozilla 员工的一个业余项目。2010年，在 Mozilla 从事 Android Firefox 开发的 Alon Zakai，为了把他以前开发的游戏引擎移植到浏览器上运行，利用业余时间开发了一款名叫 Emscripten 的编译器，可以把 C++ 代码通过 LLVM IR 编译成 JavaScript 代码。

到了 2011 年底，Emscripten 甚至能够成功编译 Python 和 Doom 等大型 C++ 项目，Mozilla 此时觉得这个项目很有前途，于是成立团队并邀请 Alon 全职开发这个项目。2013 年 Alon 和其他成员一起提出了 asm.js 规范，asm.js 是 JavaScript 语言的一个严格子集，试图通过“减少动态特性”和”添加类型提示“的方式帮助浏览器提升 JavaScript 优化空间。相较于完整的 JavaScript 语言，裁剪后的 asm.js 更靠近底层，更适合作为编译器目标语言。

asm.js 只提供两种数据类型：32位带符号整数，64位带符号浮点数，其他数据类型比如字符串、布尔值或者对象，asm.js 一概不提供，它们都是以数值的形式存在，保存在内存中，通过 TypedArray 调用。类型的声明也有固定写法：变量 | 0 表示整数，+变量 表示浮点数。例如下面一段代码：

function MyAsmModule() {
   
    "use asm";  // 告诉浏览器这是个 asm.js 模块
    function add(x, y) {
   
        x = x | 0;  // 变量 | 0 表示整数
        y = y | 0;
        return (x + y) | 0;
    }
    return {
    add: add };
}

支持 asm.js 的引擎提前识别出了类型，可以进行激进的 JIT（即时编译）优化，甚至是 AOT（事先编译）编译，大幅提升性能。不支持 asm.js 按普通 JavaScript 代码执行也不会影响运行结果。

但是 asm.js 的缺点也很明显，那就是“底层”得不够彻底，例如代码仍然是文本格式；代码编写仍然受 JavaScript 语法限制；浏览器仍然需要完成解析脚本、解释执行、收集性能指标、JIT 编译等一系列步骤。如果采用像 Java 类文件那样的二进制格式，不仅能缩小文件体积，减少网络传输时间和解析时间，还能选用更接近机器的字节码，这样 AOT/JIT 编译器实现起来会更轻松，效果也更好。

与此同时，Google 的 Chrome 团队也在试图解决 JavaScript 性能问题，但方向有所不同。Chrome 给出的解决方案是 NaCl（Google Native Client）和 PNaCl（Portable NaCl）。通过 NaCl/PNaC1，Chrome 浏览器可以在沙箱环境中直接执行本地代码。

asm.js 和 NaCl/PNaC1 技术各有优缺点，二者可以取长补短。Mozilla 和 Google也看到了这一点，所以从 2013 年开始，两个团队就经常交流和合作。后来他们决定结合两个项目的长处，合作开发一种基于字节码的技术。到了 2015 年，“WebAssembly” 确定为正式名称并对外公开，W3C 成立了 WASM 社区小组（成员包括Chrome、Edge、Firefox 和 WebKit），致力于推动 WASM 技术的发展。

2016 年 Rust 1.14发布，开始支持 W