frontend

WebAssembly 实战：从 C++ 到浏览器的高性能计算

WebAssembly（简称 WASM）自 2017 年诞生以来，已经从浏览器端的高性能计算扩展到了服务器、边缘计算乃至区块链等多个领域。本文将从实战角度出发，深入讲解 WASM 的核心机制、构建流程、JavaScript 互操作以及真实落地场景，帮助你掌握在浏览器中释放原生级性能的关键技术。

Leeting Yan 2026-09-10 8 分钟阅读 3614 字

一、WebAssembly 本质：不是语言，是编译目标

很多开发者误以为 WebAssembly 是一门新的编程语言，实际上它是一种二进制指令格式（Binary Instruction Format），设计为多种高级语言的编译目标。WASM 运行在基于栈的虚拟机上，具备以下核心特征：

二进制格式：体积小、解析快，无需像 JavaScript 那样进行词法分析和语法树构建
线性内存模型：一段连续的、可增长的字节数组，可被 JS 和 WASM 同时访问
类型系统：仅支持四种数值类型（i32, i64, f32, f64），所有复杂类型都需手动序列化到线性内存
沙箱安全：WASM 模块无法直接访问 DOM、网络或文件系统，必须通过 JS 桥接
确定性执行：相同的输入在任何平台上产生相同的输出，没有未定义行为

WASM 的设计哲学非常明确：不做 JavaScript 的替代品，而是其"性能搭档"。CPU 密集型任务交给 WASM，UI 交互和 I/O 仍由 JS 主导。

二、WASM 模块内部结构

一个标准的 WASM 模块由以下几个核心段（Section）组成：

段名称	作用
`Memory`	线性内存，模块执行时的堆和栈空间
`Table`	函数引用表，支持间接函数调用（如 C++ 虚函数）
`Globals`	全局变量，可被 JS 读写
`Exports`	模块对外暴露的函数和变量
`Imports`	模块从宿主环境导入的函数（通常来自 JS）

线性内存是理解 WASM 的关键。它是一段 JavaScript 中的 ArrayBuffer，可以被 WASM 实例和 JS 代码同时持有引用。所有数据交换——无论是字符串、数组还是结构体——都必须通过这段内存进行。

// 实例化 WASM 模块时，JS 创建并传入线性内存
const memory = new WebAssembly.Memory({ initial: 256, maximum: 512 });
const importObject = { env: { memory } };
const wasmModule = await WebAssembly.instantiateStreaming(
  fetch('/app.wasm'),
  importObject
);

这里的 initial: 256 表示初始分配 256 个内存页，每页 64KB，即 16MB。WASM 运行时可以按需增长，但不得超过 maximum 限制。

三、Emscripten 构建工作流

Emscripten 是目前最成熟的 C/C++ 到 WASM 编译工具链，它将 LLVM 编译器后端与定制的 JS 运行时相结合，自动生成 WASM 模块和配套的胶水代码。

安装 Emscripten

# 克隆 emsdk 仓库
git clone https://github.com/emscripten-core/emsdk.git
cd emsdk

# 安装并激活最新版本
./emsdk install latest
./emsdk activate latest
source ./emsdk_env.sh

# 验证安装
emcc --version

C++ 源代码示例

假设我们有一个计算密集型函数——矩阵乘法：

// matmul.cpp
#include <emscripten/emscripten.h>
#include <cstring>

extern "C" {

EMSCRIPTEN_KEEPALIVE
void matrixMultiply(float* a, float* b, float* out,
                    int aRows, int aCols, int bCols) {
    std::memset(out, 0, aRows * bCols * sizeof(float));
    for (int i = 0; i < aRows; i++) {
        for (int k = 0; k < aCols; k++) {
            float aik = a[i * aCols + k];
            for (int j = 0; j < bCols; j++) {
                out[i * bCols + j] += aik * b[k * bCols + j];
            }
        }
    }
}

EMSCRIPTEN_KEEPALIVE
int getLength(const char* str) {
    return std::strlen(str);
}

} // extern "C"

EMSCRIPTEN_KEEPALIVE 宏的作用是阻止编译器将未在内部调用的函数优化掉，确保这些函数被导出到 WASM 的 Exports 段，供 JS 调用。

编译命令

emcc matmul.cpp \
  -O3 \
  -s WASM=1 \
  -s EXPORTED_RUNTIME_METHODS='["ccall", "cwrap", "getValue", "setValue", "UTF8ToString", "stringToUTF8", "lengthBytesUTF8"]' \
  -s EXPORTED_FUNCTIONS='["_malloc", "_free"]' \
  -s ALLOW_MEMORY_GROWTH=1 \
  -s MODULARIZE=1 \
  -s EXPORT_NAME="WasmModule" \
  -o matmul.js

参数解析：

-O3：开启最高级别优化，启用循环展开、向量化等
-s WASM=1：输出 WASM 格式（默认即 WASM，显式声明更稳妥）
EXPORTED_RUNTIME_METHODS：导出 Emscripten 的运行时辅助函数
EXPORTED_FUNCTIONS：导出 C 标准库的 malloc 和 free，用于手动内存管理
ALLOW_MEMORY_GROWTH=1：允许线性内存根据需求自动增长
MODULARIZE=1 + EXPORT_NAME：将输出打包为受控的 ES Module/工厂函数

编译后生成两个文件：matmul.js（胶水代码，约 20KB 压缩后）和 matmul.wasm（实际编译产物）。

四、JavaScript 与 WASM 的互操作

JS 与 WASM 的边界跨越（Boundary Crossing）是实际开发中的核心难点。由于 WASM 只理解数值类型，所有复杂数据都需要手动序列化到线性内存。

加载 WASM 模块

<script type="module">
import WasmModule from './matmul.js';

const wasm = await WasmModule();
// wasm 已包含 .ccall, .cwrap, .HEAPU8, ._malloc 等方法
</script>

传递数组数据

以矩阵乘法为例，JS 需要将 Float32Array 写入 WASM 的线性内存，然后调用 C++ 函数：

async function runMatrixMultiply() {
  const wasm = await WasmModule();

  const aRows = 512, aCols = 512, bCols = 512;
  const a = new Float32Array(aRows * aCols).map(() => Math.random());
  const b = new Float32Array(aCols * bCols).map(() => Math.random());

  const aPtr = wasm._malloc(a.byteLength);
  const bPtr = wasm._malloc(b.byteLength);
  const outPtr = wasm._malloc(aRows * bCols * 4);

  // 将数据拷贝到 WASM 内存
  wasm.HEAPF32.set(a, aPtr >> 2);
  wasm.HEAPF32.set(b, bPtr >> 2);

  wasm._matrixMultiply(aPtr, bPtr, outPtr, aRows, aCols, bCols);

  // 读取结果
  const out = new Float32Array(
    wasm.HEAPF32.buffer,
    outPtr,
    aRows * bCols
  );

  // 务必手动释放内存——WASM 侧无垃圾回收
  wasm._free(aPtr);
  wasm._free(bPtr);
  wasm._free(outPtr);

  return out;
}

注意这里的位移操作 aPtr >> 2：HEAPF32 是 32 位视图，索引单位是 4 字节，而指针地址是字节偏移，因此需要除以 4。

传递字符串

字符串在边界两侧需要编码和解码：

function callWithString(wasm, str) {
  const len = wasm.lengthBytesUTF8(str) + 1;
  const ptr = wasm._malloc(len);
  wasm.stringToUTF8(str, ptr, len);

  const result = wasm.ccall('getLength', 'number', ['number'], [ptr]);

  wasm._free(ptr);
  return result;
}

更优雅的方案是使用 cwrap 预先包装函数，避免每次调用时重复解析签名：

const getLengthWrapped = wasm.cwrap('getLength', 'number', ['number']);
const len = getLengthWrapped(ptr);

传递对象/结构体

复杂的对象建议通过共享内存 + 偏移量来传递，或者使用 FlatBuffers、Protocol Buffers 等序列化方案。简单的结构体可以直接计算字段偏移：

// 假设在 C++ 侧定义了结构体
struct Particle {
    float x, y, z;    // offset 0, 4, 8
    float vx, vy, vz; // offset 12, 16, 20
    int id;           // offset 24
};
// 总大小 28 字节（需注意内存对齐）

const PARTICLE_SIZE = 28;
const OFFSET_ID = 24;

const buffer = new ArrayBuffer(count * PARTICLE_SIZE);
const view = new DataView(buffer);

for (let i = 0; i < count; i++) {
  view.setInt32(i * PARTICLE_SIZE + OFFSET_ID, i, true);
}

五、内存模型深度解析

WASM 的线性内存是开发现代高性能应用时最容易踩坑的地方。理解以下几点至关重要：

SharedArrayBuffer 与多线程

当启用 -s USE_PTHREADS=1 时，Emscripten 会生成支持多线程的 WASM 模块，此时线性内存必须是 SharedArrayBuffer。这要求网页承载在同源隔离（Cross-Origin Isolated）环境下：

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

// 多线程编译需要显式设置共享内存
const memory = new WebAssembly.Memory({
  initial: 256,
  maximum: 512,
  shared: true
});

内存增长与视图失效

当 WASM 内存增长时（例如 memory.grow(1)），浏览器会分配一块全新的 ArrayBuffer，旧的 ArrayBuffer 会被 detached。如果 JS 之前缓存了 HEAPF32 等视图，它们会立即失效：

// 危险操作：缓存视图
const heap = wasm.HEAPF32; // 拿到了旧 buffer 的引用
// ... WASM 内部触发了内存增长 ...
heap[0] = 1.0; // TypeError: Cannot perform %TypedArray%.prototype.set on a detached ArrayBuffer

// 正确做法：每次使用前重新获取
wasm.HEAPF32.set(data, ptr >> 2);

所有权模式

推荐采用明确的内存所有权规则：谁分配，谁释放。JS 调用 wasm._malloc() 分配的内存，必须由 JS 调用 wasm._free() 释放。WASM 内部用 new/delete 分配的内存，由 C++ 负责。

// 不推荐：在 C++ new 后在 JS free
// 不推荐：JS malloc 后 C++ 调用 delete

六、WASI：浏览器之外的 WASM

WASI（WebAssembly System Interface）是 WASM 走出浏览器的关键一步。它为 WASM 模块提供了标准化的系统调用接口，涵盖文件系统、网络套接字、标准输入输出等能力。

当前主流的 WASI 运行时包括：

wasmtime：Bytecode Alliance 推出的 Rust 编写运行时，性能优秀
WasmEdge：云原生 WASM 运行时，支持 Kubernetes 集成
Node.js：从 v20 开始内建 WASI 支持（需 --experimental-wasi-unstable-preview1）

// Node.js 中运行 WASI 模块
import { readFile } from 'node:fs/promises';
import { WASI } from 'wasi';

const wasi = new WASI({
  version: 'preview1',
  args: process.argv,
  env: process.env,
  preopens: { '/sandbox': '/some/real/path' }
});

const wasm = await WebAssembly.compile(await readFile('./app.wasm'));
const instance = await WebAssembly.instantiate(wasm, {
  wasi_snapshot_preview1: wasi.wasiImport
});

wasi.start(instance);

WASI 的潜力在于"一次编译，到处运行"——将 C++、Rust 等语言编译为 WASM，可以在浏览器、边缘节点、Serverless 平台上保持完全一致的行为。

七、实战落地场景

浏览器端图像处理

WebP、AVIF 编解码，以及 OpenCV.js（底层为 WASM 加速）已经在实际项目中大规模应用。例如美图、稿定设计等在线图片编辑器，实时滤镜和裁剪的核心算法都跑在 WASM 中：

// OpenCV.js 示例：WASM 加速的边缘检测
const src = cv.imread(canvas);
const dst = new cv.Mat();
cv.cvtColor(src, src, cv.COLOR_RGBA2GRAY);
cv.Canny(src, dst, 50, 150);
cv.imshow('outputCanvas', dst);

游戏引擎

Unity 的 WebGL 导出方案已从传统的 asm.js 全面迁移到 WASM。Unreal Engine 同样支持 WASM 输出。WASM 的 near-native 性能让浏览器运行 3A 级游戏成为可能，Unity 的小游戏平台在国内增长迅猛。

机器学习推理

ONNX Runtime Web 将模型转换为 .onnx 后，可在浏览器中通过 WASM 后端执行推理，无需后端服务器：

import * as ort from 'onnxruntime-web';

const session = await ort.InferenceSession.create('./model.onnx', {
  executionProviders: ['wasm'],
  wasmOptions: { simd: true }
});

const input = new ort.Tensor('float32', data, [1, 3, 224, 224]);
const feeds = { input: input };
const results = await session.run(feeds);

开启 SIMD（单指令多数据流）后，WASM 性能可再提升 2~3 倍。现代 Emscripten 默认在 -O3 下自动向量化，无需手动编写 SIMD 指令。

八、性能基准对比

为了量化 WASM 的收益，我在本地运行了一组对比测试（Chrome 128, M3 Pro, 矩阵乘法 512x512）：

运行环境	耗时（ms）	相对倍数
原生 C++ (-O3)	12	1.0x
WebAssembly (-O3, SIMD)	18	1.5x
WebAssembly (-O3, no SIMD)	35	2.9x
JavaScript (优化 TypedArray)	120	10.0x
JavaScript (普通 Array)	350	29.2x

结果说明：

WASM 距离原生 C++ 仅有 1.5 倍差距，在浏览器环境中已属顶尖水平
SIMD 向量化对计算密集型任务影响巨大
JS 即使使用 TypedArray，在纯计算场景下仍比 WASM 慢一个数量级
普通 JS Array 由于开销更大，性能差距进一步放大到近 30 倍

需要强调的是，WASM 的收益在 I/O 密集型场景中并不明显。如果代码主要在进行 DOM 操作、网络请求或 JSON 解析，WASM 无法带来显著优势，反而因为 JS/WASM 边界开销而拖慢整体速度。

总结

WebAssembly 已将浏览器的计算能力提升到了一个新高度。掌握 WASM 的关键不在于学习新语法，而在于理解其内存模型、构建工具链和跨语言互操作机制。在图像处理、音视频编解码、科学计算和 ML 推理等领域，WASM 已经成为不可或缺的技术选型。

建议从 Emscripten + C++ 入手，先用简单的数值计算函数验证流程，再逐步深入到复杂的数据结构传递和多线程应用。随着 WASI 的成熟，同一套 WASM 模块未来有望在浏览器、Serverless 和边缘节点之间无缝迁移，真正实现"编写一次，处处高性能"。

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章返回首页