WebAssembly 概念：二进制格式与运行时

从 asm.js 到 WebAssembly

JavaScript 的性能瓶颈

JavaScript 诞生于 1995 年，最初只是用于网页表单验证的简单脚本语言。随着 Web 应用越来越复杂，工程师们开始挑战 JS 的性能极限：游戏、3D 渲染、音视频编解码、密码学计算……这些计算密集型任务在 JS 中表现糟糕。

即使经过 V8 引擎的 JIT（即时编译）优化，JavaScript 由于其动态类型特性，引擎在运行时需要频繁检查变量类型、可能触发垃圾回收暂停，在纯数值计算上的性能往往只有原生 C 代码的 1/3 到 1/5。

asm.js：WebAssembly 的前身

asm.js 是 Mozilla 于 2013 年发布的技术，这是 WebAssembly 的直接前身。它的思路是：用 JavaScript 的一个严格子集来写代码，这个子集全部使用静态类型（通过位运算等技巧提示类型），让 JS 引擎可以直接编译为机器码，跳过动态类型检查。

// asm.js 风格的代码（由 Emscripten 生成，人类通常不手写）
function AsmModule(stdlib, foreign, heap) {
  "use asm";  // 声明这是 asm.js 模块
  var imul = stdlib.Math.imul;

  // 所有变量都有明确的类型注解（通过 |0 表示 int，+x 表示 double）
  function add(x, y) {
    x = x | 0;    // 强制转为 32位整数
    y = y | 0;
    return (x + y) | 0;
  }

  return { add: add };
}

asm.js 的主要限制：

• 仍然是文本格式：需要 JS 引擎解析，传输体积大（是同等 C 代码编译二进制的 3-5 倍）
• 解析慢：即使是已知的 asm.js 代码，引擎仍需词法解析，启动时间长
• 非标准：只有 Firefox 对 asm.js 有完整优化，Chrome/Safari 支持有限
• 不够安全：没有严格的内存隔离机制

WebAssembly 的诞生（2015-2019）

2015 年，Mozilla、Google、Microsoft、Apple 四家主要浏览器厂商史无前例地联合宣布合作开发 WebAssembly。2017 年各大浏览器同步发布了初版支持，2019 年 W3C 正式将 WebAssembly 发布为 Web 标准——这是继 HTML、CSS、JavaScript 之后第四个 W3C Web 标准语言格式。

WebAssembly 的二进制格式

.wasm 文件结构

WebAssembly 有两种等价的表示格式：二进制格式（.wasm 文件）和文本格式（.wat 文件，WebAssembly Text）。就像机器码和汇编语言的关系，两者可以无损互转，但浏览器执行的是二进制格式。

二进制 vs 文本格式对比

;; .wat 文本格式 — 一个简单的加法函数
(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add
  )
  (export "add" (func $add))
)

;; 对应的二进制格式（十六进制表示）
00 61 73 6d  ; 魔数 "\0asm"
01 00 00 00  ; 版本 1
01 07        ; Type section（长度 7 字节）
01 60 02 7f  ; 1 个函数类型: (i32, i32)
7f 01 7f     ; -> i32
03 02 01 00  ; Function section: 函数 0 使用类型 0
07 07 01 03  ; Export section: 导出 "add"
61 64 64 00  ; "add" 对应函数 0
0a 09 01 07  ; Code section
00 20 00 20  ; local.get 0, local.get 1
01 6a 0b     ; i32.add, end

WebAssembly 的安全模型

线性内存沙箱

WebAssembly 最重要的安全保证来自其线性内存模型。每个 Wasm 模块只能访问一块连续的字节数组（线性内存），这块内存与 JS 的堆内存完全隔离，也与宿主系统的内存隔离。Wasm 代码无法越界访问这块内存之外的任何数据。

安全特性总结

Wasm 与 JavaScript 的关系

互补，而非替代

一个常见的误解是：WebAssembly 会取代 JavaScript。这个观点是错误的。Wasm 和 JS 是互补关系，各有其擅长领域：

典型的 Wasm + JS 协作模式

// 典型架构：JS 负责 UI 和胶水代码，Wasm 负责计算
async function processImage(imageData) {
  // 1. 加载 Wasm 模块
  const { instance } = await WebAssembly.instantiateStreaming(
    fetch('image_processor.wasm')
  );

  // 2. 将图像数据写入 Wasm 线性内存
  const wasmMemory = new Uint8Array(instance.exports.memory.buffer);
  wasmMemory.set(imageData, 0);

  // 3. 调用 Wasm 函数执行计算（CPU 密集型）
  const resultOffset = instance.exports.apply_gaussian_blur(
    0,              // 输入数据偏移
    imageData.length, // 数据长度
    5               // 模糊半径
  );

  // 4. 从 Wasm 内存读取结果，交回 JS 处理
  return new Uint8Array(
    instance.exports.memory.buffer,
    resultOffset,
    imageData.length
  );
}

浏览器运行时支持

V8（Chrome/Node.js/Deno）

Google V8 引擎对 Wasm 的支持最为领先，它实现了 Liftoff（快速基线编译器，减少启动延迟）和 Turbofan（优化编译器，提升执行性能）两级 JIT 编译：

• Liftoff 在 Wasm 模块下载时立即开始基线编译，模块下载完成后即可运行
• Turbofan 在后台对热点函数进行深度优化，逐步替换 Liftoff 生成的代码
• 支持 SIMD、多线程（SharedArrayBuffer + Atomics）、WasmGC 等新提案

SpiderMonkey（Firefox）

Mozilla Firefox 的 SpiderMonkey 是 Wasm 最早的原型验证平台，对 Wasm 规范贡献最多。它同样实现了两级编译（Cranelift 基线 + Ion 优化），对 WASI 和安全沙箱的支持尤为严格。

JavaScriptCore（Safari/WebKit）

苹果的 JSC 对 Wasm 的支持相对保守，新提案（如 SIMD、线程）的实现时间线通常落后于 V8 和 SpiderMonkey 6-12 个月。开发 iOS/macOS Web 应用时需特别注意兼容性。

常见误区与注意事项

const { instance } = await WebAssembly.instantiate(wasmBytes);
let mem = new Uint8Array(instance.exports.memory.buffer);

instance.exports.grow_memory();  // Wasm 内部调用 memory.grow()

// ❌ 错误：mem 现在指向旧的 ArrayBuffer，已失效
// mem[0] = 42; // 不会写入当前内存！

// ✅ 正确：内存增长后重新获取视图
mem = new Uint8Array(instance.exports.memory.buffer);
mem[0] = 42;  // 现在正确写入

WebAssembly 的现实应用案例

已在生产中使用 Wasm 的知名项目

本章小结