Rust 编译 WebAssembly 指南

下面是我所知道的关于将 Rust 编译为 WebAssembly 的所有知识。

前一段时间，我写了一篇如何在没有 Emscripten 的情况下将 C 编译为 WebAssembly 的博客文章，即不默认工具来简化这个过程。 在 Rust 中，使 WebAssembly 变得简单的工具称为 wasm-bindgen，我们正在放弃它！ 同时，Rust 有点不同，因为 WebAssembly 长期以来一直是一流的目标，并且开箱即用地提供了标准库布局。

Rust 编译 WebAssembly 入门

让我们看看如何让 Rust 以尽可能少的偏离标准 Rust 工作流程的方式编译成 WebAssembly。 如果你浏览互联网，许多文章和指南都会告诉你使用 cargo init --lib 创建一个 Rust 库项目，然后将 crate-type = ["cdylib"] 添加到你的 cargo.toml，如下所示：

[package]
name = "my_project"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]
   
[dependencies]

如果你不将 crate 类型设置为 cdylib，Rust 编译器将生成一个 .rlib 文件，这是 Rust 自己的库格式。 虽然 cdylib 这个名字暗示了一个与 C 兼容的动态库，但我怀疑它真的只是代表“使用可互操作的格式”或类似的东西。

现在，我们将使用 Cargo 在创建新库时生成的默认/示例函数：

pub fn add(left: usize, right: usize) -> usize {
    left + right
}

一切就绪后，我们现在可以将这个库编译为 WebAssembly：

cargo build --target=wasm32-unknown-unknown --release

你会在 target/wasm32-unknown-unknown/release/my_project.wasm 找到它。 在整篇文章中，我将继续使用 --release 进行构建，因为它使 WebAssembly 模块在我们反汇编时更具可读性。

可执行文件与库

你可以创建一个 Rust 可执行文件（通过 cargo init --bin），而不是创建一个库。 但是请注意，你要么必须让 main() 函数具有完善的签名，要么使用 #![no_main] 关闭编译器以让它知道缺少 main() 是故意的。

那个更好吗？ 这对我来说似乎是一个品味问题，因为这两种方法在功能上似乎是等同的并且生成相同的 WebAssembly 代码。 大多数时候，WebAssembly 模块似乎扮演了一个库的角色，而不是一个可执行文件（除了在 WASI 的上下文中，稍后会详细介绍！），所以在我看来，库方法在语义上似乎更可取。 除非另有说明，否则我将在本文的其余部分使用库设置。

导出

继续库样式的设置，让我们看看编译器生成的 WebAssembly 代码。 为此，我推荐 WebAssembly Binary Toolkit（简称“wabt”），它提供了有用的工具，如 wasm2wat。 另外，请确保安装了 Binarygen，因为本文后面我们将需要 wasm-opt。 Binaryen 还提供了 wasm-dis，其工作方式与 wasm2wat 类似，但不产生 WebAssembly 文本格式 (WAT)。 它生成标准化程度较低的 WebAssembly S-Expression 文本格式 (WAST)。 最后，ByteCodeAlliance 的 wasm-tools 提供了 wasm-tools print。

wasm2wat ./target/wasm32-unknown-unknown/release/my_project.wasm

此命令会将 WebAssembly 二进制文件转换为 WAT：

(module
  (table (;0;) 1 1 funcref)
  (memory (;0;) 16)
  (global $__stack_pointer (mut i32) (i32.const 1048576))
  (global (;1;) i32 (i32.const 1048576))
  (global (;2;) i32 (i32.const 1048576))
  (export "memory" (memory 0))
  (export "__data_end" (global 1))
  (export "__heap_base" (global 2)))

令人发指的是，我们发现我们的 add 函数已从二进制文件中完全删除。 我们只剩下一个堆栈指针和两个全局变量，它们指定数据部分的结束位置和堆的开始位置。 事实证明，将函数声明为 pub 不足以让它出现在我们最终的 WebAssembly 模块中。 我其实希望这就足够了，但我怀疑 Rust 模块可见性是唯一的，而不是链接器级别的符号可见性。

确保编译器不会删除我们关心的函数的最快方法是添加属性 #[no_mangle]，尽管我不喜欢这个命名。

#[no_mangle]
pub fn add(left: usize, right: usize) -> usize {
    left + right
}

很少需要，但是你可以通过使用 #[export_name = "..."] 导出一个名称与其 Rust 内部名称不同的函数。

将我们的 add 函数标记为导出后，我们可以再次编译项目并检查生成的 WebAssembly 文件：

(module
  (type (;0;) (func (param i32 i32) (result i32)))
  (func $add (type 0) (param i32 i32) (result i32)
    local.get 1
    local.get 0
    i32.add)
  (table (;0;) 1 1 funcref)
  (memory (;0;) 16)
  (global $__stack_pointer (mut i32) (i32.const 1048576))
  (global (;1;) i32 (i32.const 1048576))
  (global (;2;) i32 (i32.const 1048576))
  (export "memory" (memory 0))
  (export "add" (func $add))
  (export "__data_end" (global 1))
  (export "__heap_base" (global 2)))

这个模块可以用普通的 WebAssembly API 实例化：

const importObj = {};

// Node
const data = require("fs").readFileSync("./my_project.wasm");
const {instance} = await WebAssembly.instantiate(data, importObj);

// Deno
const data = await Deno.readFile("./my_project.wasm");
const {instance} = await WebAssembly.instantiate(data, importObj);

// For Web, it’s advisable to use `instantiateStreaming` whenever possible:
const response = await fetch("./my_project.wasm");
const {instance} = 
  await WebAssembly.instantiateStreaming(response, importObj);

instance.exports.add(40, 2) // returns 42

突然之间，我们几乎可以使用 Rust 的所有功能来编写 WebAssembly。

需要特别注意模块边界处的函数（即你从 JavaScript 调用的函数）。至少就目前而言，最好坚持使用能够清晰映射到 WebAssembly 的类型（如i32或f64）。如果你使用更高级别的类型，如数组、切片，甚至 String，该函数最终可能会使用比它们在 Rust 中更多的参数，并且通常需要对内存布局和类似原则有更深入的了解。

ABI

请注意：是的，我们正在成功地将 Rust 编译为 WebAssembly。然而，在 Rust 版本中，可能会生成一个具有完全不同函数签名的 WebAssembly 模块。函数参数从调用者传递到被调用者的方式（例如作为指向内存的指针或作为立即值）是应用程序二进制接口定义或简称“ABI”的一部分。rustc 默认使用 Rust 的 ABI，它不稳定，主要考虑 Rust 内部。

rustc 为了稳定这种情况，我们可以显式定义要为函数使用哪个 ABI 。这是通过使用 extern 关键字来完成的。跨语言函数调用的一个长期选择是 C ABI，我们将在此处使用它。C ABI 不会改变，所以我们可以确定我们的 WebAssembly 模块接口也不会改变。

#[no_mangle]
pub fn add(left: usize, right: usize) -> usize {
pub extern "C" fn add(left: usize, right: usize) -> usize {
    left + right
}

我们甚至可以省略 "C" 而只使用 extern，因为 C ABI 是默认的替代 ABI。

导入

WebAssembly 的一个重要部分是它的沙箱。它确保在 WebAssembly VM 中运行的代码无法访问主机环境中的任何内容，除了通过 imports 对象显式传递到沙箱中的函数。

假设我们想在我们的 Rust 代码中生成随机数。我们可以引入 rand Rust 沙箱，但如果主机环境中已经有东西，为什么还要发布代码。作为第一步，我们需要声明我们的 WebAssembly 模块需要导入：

#[link(wasm_import_module = "Math")]
extern "C" {
    fn random() -> f64;
}

#[export_name = "add"]
pub fn add(left: f64, right: f64) -> f64 {
    left + right  
    left + right + unsafe { random() }
}

extern "C" 块（不要与上面的 extern "C" 函数混淆）声明编译器希望在链接时由“其他人”提供的函数。这通常是你在 Rust 中链接 C 库的方式，但该机制也适用于 WebAssembly。但是，外部函数总是隐式不安全的，因为编译器无法为非 Rust 函数提供任何安全保证。因此，除非我们将调用包装在 unsafe { ... } 块中，否则我们无法调用它们。

上面的代码可以编译，但不会运行。我们的 JavaScript 代码抛出错误，需要更新以满足我们指定的导入。导入对象是导入模块的字典，每个模块都是导入项的字典。在我们的 Rust 代码中，我们声明了一个导入模块"Math"，并期望一个被调用的函数"random"出现在该模块中。这些值当然是经过仔细选择的，这样我们就可以传入整个 Math 对象。

  const importObj = {
    Math: {
      random: () => Math.random(),
    }
  };

  // or
  
  const importObj = { Math };

为了避免到处注入 unsafe { ... }，通常需要编写包装函数来恢复 Rust 的安全不变量。这是 Rust 内联模块的一个很好的用例：

mod math {
    mod math_js {
        #[link(wasm_import_module = "Math")]
        extern "C" {
            pub fn random() -> f64;
        }
    }

    pub fn random() -> f64 {
        unsafe { math_js::random() }
    }
}

#[export_name = "add"]
pub extern "C" fn add(left: f64, right: f64) -> f64 {
    left + right + math::random()
}

顺便说一句，如果我们没有指定 #[link(wasm_import_module = ...)]属性，则函数将在默认 env 模块上运行。此外，就像你可以使用 #[export_name = "..."] 更改导出的函数的名称一样，你可以使用 #[link_name = "..."] 更改导入的函数的名称。

高级类型

我之前说过，在模块边界处理函数的最有效方法是使用透明映射到 WebAssembly 支持的数据类型的值类型。 当然，编译器允许你使用更复杂的类型作为函数的参数和值。 在这些情况下，编译器生成 C ABI 中指定的代码（除了 rustc 目前不完全符合 C ABI 的不足）。

无需赘述，类型大小（例如，struct、enum 等）就变成了一个简单的指针。 数组和元组是有大小的类型，如果它们使用少于 32 位，它们将被转换为立即值。 更复杂的情况是函数返回大于 32 位的数组类型的值：如果是这种情况，函数将不会收到返回值，而是会收到一个附加类型的参数 i32，该函数将利用指向此参数的指针来存储结果。 如果一个函数返回一个元组，无论元组的大小如何，它总是被认为是函数的参数。

(?Sized) 具有未指定类型的函数参数，例如 str、[u8] 或 dyn MyTrait，由两部分组成：第一部分是指向数据的指针，第二部分是指向元数据的指针。 如果是 str 的一个或一部分，则元数据是数据的长度。 在特征对象的实例中，它是一个虚拟表（或 vtable），它是指向各个特征函数实现的函数指针列表。 如果你想了解更多有关 Rust 中的 VTable 的信息，我可以推荐 Thomas Bächler 的这篇文章。

我在这里省略了重要的细节，因为建议你不要编写下一个 wasm-bindgen，除非你非要这样做。 我建议依靠现有工具而不是创建新工具。

模块大小

当 WebAssembly 部署在 web 上时，它的二进制文件的大小非常重要。 每一点都必须通过网络传输并通过浏览器的 WebAssembly 编译器，因此，较小的二进制大小意味着在 WebAssembly 开始运行之前用户等待的时间更少。 如果我们将默认项目构造为发布版本，我们将生成 1.7MB 的 WebAssembly。 这对于两个数字相加的功能似乎太大了。

数据部分：WebAssembly 模块的大部分由数据组成。 即数据在特定点保存在内存中，然后复制到线性内存。 这些部分的编译成本很低，因为编译器会跳过它们，在分析和减少模块的启动时间时请记住这一点。

检查 WebAssembly 模块内部结构的一种简单方法是 llvm-objdump，这应该可以在你的系统上访问。 或者，你可以使用 wasm-objdump，它是 wabt 的一部分，通常提供相同的接口。

$ llvm-objdump -h target/wasm32-unknown-unknown/release/my_project.wasm

target/wasm32-unknown-unknown/release/my_project.wasm: file format wasm

Sections:
Idx Name            Size     VMA      Type
  0 TYPE            00000007 00000000
  1 FUNCTION        00000002 00000000
  2 TABLE           00000005 00000000
  3 MEMORY          00000003 00000000
  4 GLOBAL          00000019 00000000
  5 EXPORT          0000002b 00000000
  6 CODE            00000009 00000000 TEXT
  7 .debug_info     00062c72 00000000
  8 .debug_pubtypes 00000144 00000000
  9 .debug_ranges   0002af80 00000000
 10 .debug_abbrev   00001055 00000000
 11 .debug_line     00045d24 00000000
 12 .debug_str      0009f40c 00000000
 13 .debug_pubnames 0003e3f2 00000000
 14 name            0000001c 00000000
 15 producers       00000043 00000000

llvm-objdump 过于笼统，为那些有使用其他语言汇编经验的人提供熟悉的命令行。 然而，专门用于调试二进制字符串的大小，它缺少简单的工具，如按大小排序部分或按功能分解部分。 幸运的是，有专门为此设计的 WebAssembly 专用工具 Twiggy：

$ twiggy top target/wasm32-unknown-unknown/release/my_project.wasm
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼─────────────────────────────────────────
        652300 ┊    36.67% ┊ custom section '.debug_str'
        404594 ┊    22.75% ┊ custom section '.debug_info'
        285988 ┊    16.08% ┊ custom section '.debug_line'
        254962 ┊    14.33% ┊ custom section '.debug_pubnames'
        176000 ┊     9.89% ┊ custom section '.debug_ranges'
          4181 ┊     0.24% ┊ custom section '.debug_abbrev'
           324 ┊     0.02% ┊ custom section '.debug_pubtypes'
            67 ┊     0.00% ┊ custom section 'producers'
            25 ┊     0.00% ┊ custom section 'name' headers
            20 ┊     0.00% ┊ custom section '.debug_pubnames' headers
            19 ┊     0.00% ┊ custom section '.debug_pubtypes' headers
            18 ┊     0.00% ┊ custom section '.debug_ranges' headers
            17 ┊     0.00% ┊ custom section '.debug_abbrev' headers
            16 ┊     0.00% ┊ custom section '.debug_info' headers
            16 ┊     0.00% ┊ custom section '.debug_line' headers
            15 ┊     0.00% ┊ custom section '.debug_str' headers
            14 ┊     0.00% ┊ export "__heap_base"
            13 ┊     0.00% ┊ export "__data_end"
            12 ┊     0.00% ┊ custom section 'producers' headers
             9 ┊     0.00% ┊ export "memory"
             9 ┊     0.00% ┊ add
...

现在很明显，模块大小的所有主要贡献者都是与模块用途无关的自定义组件。 它们的标题暗示它们包含用于故障排除的信息，因此这些部分是为构建和发布而发出的这一事实有些不合常规。 这似乎与我们代码的一个长期存在的问题有关，该问题导致它在编译时没有调试符号，但在我们的机器上预编译的标准库仍然有调试符号。

为了解决这个问题，我们在 Cargo.toml 中添加了：

[profile.release]
strip = true

这将导致 rustc 删除所有自定义部分，包括为函数分配名称的部分。 这可能不是我们想要的，因为 twiggy 的输出将只包含 saycode[0] 或类似的函数。 如果你想维护函数名称，我们可以使用特定的模式来删除信息：

[profile.release]
strip = true
strip = "debuginfo"

如果你想完全细粒度控制，你可以恢复并完全禁用 rustc 的 strip 方法，而是使用 llvm-strip 或 wasm-strip。 这使你能够决定应保留哪些自定义部件。

llvm-strip --keep-section=name target/wasm32-unknown-unknown/release/my_project.wasm

移除外层后，我们剩下一个与 116B 一样大或大于 116B 的块。 拆解它会发现该模块的唯一目的是调用 add 并执行 (f64.add (local.get 0) (local.get 1))，这意味着 Rust 编译器能够生成最佳代码。 当然，代码库的大小增加了，这使得掌握二进制大小变得更加困难。

自定义部分

有趣的事实：我们可以使用 Rust 将我们的自定义部分添加到 WebAssembly 模块中。 如果我们声明一个字节数组（不是切片！），我们可以添加一个 #[link_section=...] 属性来将这些字节打包到它自己的部分中。

const _: () = {
    #[link_section = "surmsection"]
    static SECTION_CONTENT: [u8; 11] = *b"hello world";
};

我们可以使用 WebAssembly.Module.customSection() API 或使用 llvm-objdump 提取这些数据：

$ llvm-objdump -s -j surmsection target/wasm32-unknown-unknown/release/my_project.wasm

target/wasm32-unknown-unknown/release/my_project.wasm: file format wasm
Contents of section surmsection:
 0000 68656c6c 6f20776f 726c64             hello world

偷偷摸摸的膨胀

我在网上看到一些关于 Rust 为看似很小的工作创建 WebAssembly 模块的抱怨。 根据我的经验，Rust 创建的 WebAssembly 二进制文件可能很大的原因有以下三个：

• 调试构建（即忘记将 --release 传递给 Cargo）
• 调试符号（即忘记运行 llvm-strip）
• 意外的字符串格式和恐慌

我们已经看到了前两个。 让我们仔细看看最后一个。 这个无害的程序编译成 18KB 的 WebAssembly：

static PRIMES: &[i32] = &[2, 3, 5, 7, 11, 13, 17, 19, 23];

#[no_mangle]
extern "C" fn nth_prime(n: usize) -> i32 {
    PRIMES[n]
}

好吧，也许它毕竟不是那么无害。 你可能已经知道我要干嘛了。

恐慌

快速浏览一下 twiggy 就会发现，影响 Wasm 模块大小的主要因素是与字符串格式化、恐慌和内存分配相关的函数。 这说得通！ 参数 n 未清理并用于索引数组。 Rust 别无选择，只能注入边界检查。 如果边界检查失败，Rust 会崩溃，这是创建格式正确的错误消息和堆栈跟踪所必需的。

解决这个问题的一种方法是自己进行边界检查。 Rust 的编译器非常擅长仅在需要时注入检查。

fn nth_prime(n: usize) -> i32 {
    if n < 0 || n >= PRIMES.len() { return -1; }
    PRIMES[n]
}

可以说更惯用的方法是依靠Option<T>API 来控制错误情况的处理方式：

fn nth_prime(n: usize) -> i32 {
    PRIMES[n]
    PRIMES.get(n).copied().unwrap_or(-1)
}

第三种方法是使用 unchecked Rust 明确提供的一些方法。 这些为未定义的行为打开了大门，因此是 unsafe，但如果你能够承担起安全的重担，性能（或文件大小）的提高将是显着的！

fn nth_prime(n: usize) -> i32 {
    PRIMES[n]
    unsafe { *PRIMES.get_unchecked(n) }
}

我们可以尝试处理恐慌可能发生的位置，并尝试手动处理这些路径。 然而，一旦我们开始依赖第三方 crate，成功的机会就会减少，因为我们无法轻易改变库内部处理错误的方式。

LTO

我们可能不得不接受这样一个事实，即我们无法避免代码库中出现 panic 的代码路径。 虽然我们可以尝试减轻恐慌的影响（我们会的！），但有一个相当强大的优化通常可以节省一些重要的代码。 这个优化过程由 LLVM 提供，称为 LTO（Link Time Optimization，链接时优化）。 rustc 在将所有内容链接到最终二进制文件之前编译和优化每个 crate。 然而，一些优化只有在链接后才会变得明显。 例如，许多函数根据输入有不同的分支。 在编译期间，你只会看到来自同一个 crate 的函数调用。 在链接时，你知道对任何给定函数的所有可能调用，这意味着现在可以消除其中一些代码分支。

LTO 默认处于关闭状态，因为它是一项代价高昂的优化，会显着减慢编译时间，尤其是在较大的 crate 中。 你可以通过在 Cargo.toml 中配置 rustc 的许多代码生成选项启用。 具体来说，我们需要将这一行添加到我们的 Cargo.toml 中以在发布版本中启用 LTO：

[package]
name = "my_project"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[profile.release]
lto = true

启用 LTO 后，剥离的二进制文件减少到 2.3K，这令人印象深刻。 LTO 的唯一成本是更长的链接时间，但如果二进制大小是一个问题，LTO 将成为一项利器，因为它“仅”花费构建时间并且不需要更改代码。

wasm-opt

另一个几乎应该成为构建管道一部分的工具是来自 binaryen 的 wasm-opt。 它是另一个优化过程的集合，完全在 WebAssembly VM 指令上工作，独立于生成它们的源语言。 像 Rust 这样的高级语言有更多的信息可以用来应用更复杂的优化，所以 wasm-opt 不能替代你的语言编译器的优化。 但是，它通常设法将模块大小减少几个额外的字节。

wasm-opt -O3 -o output.wasm target/wasm32-unknown-unknown/my_project.wasm

在我们的例子中，wasm-opt 进一步缩小了 Rust 的 2.3K WebAssembly 二进制文件，最后是 2.0K。 好的！ 但别担心，我不会就此打住。 这对于数组中的查找来说仍然太大了。

非标准

Rust 有一个标准库，其中包含你每天进行系统编程时所需的许多抽象和实用程序：访问文件、获取当前时间或打开网络套接字。 一切都在那里供你使用，无需去 crates.io 或类似网站上搜索。 然而，许多数据结构和函数对它们的使用环境做出了假设：它们假设硬件的细节被抽象成一个统一的 API，并且它们假设它们可以以某种方式分配（和释放）任意大小的内存块。 通常，这两项工作都是由操作系统完成的，我们大多数人每天都在操作系统上工作。

但是，当你通过原始 API 实例化 WebAssembly 模块时，情况就不同了：沙箱（WebAssembly 的定义安全功能之一）将 WebAssembly 代码与主机隔离开来，从而与操作系统隔离开来。 你的代码只能访问一大块线性内存，它甚至无法弄清楚哪些部分正在使用，哪些部分可以使用。

WASI：这不是本文的一部分，但就像 WebAssembly 是对运行代码的处理器的抽象一样，WASI（WebAssembly 系统接口）旨在成为对运行代码的操作系统的抽象，并为你提供可以使用单一、统一的 API。 Rust 支持 WASI，尽管 WASI 本身仍在发展中。

这意味着 Rust 给了我们一种虚假的安全感！ 它为我们提供了一个没有操作系统支持的完整标准库。 事实上，许多 stdlib 模块只是别名或者失败了。 也就是说，它们在没有操作系统支持的情况下不能正常工作。在没有操作系统支持的情况下，许多返回 Result <T> 类型的函数可能会因为无法正常工作而始终返回 Err，这意味着无法得到正确的操作结果。同样，其他一些函数可能会因为无法正常工作而导致程序崩溃。

向无操作系统设备学习

只是一个线性内存块。 没有管理内存或外围设备的中央实体。 只是算术。 如果你曾经使用过嵌入式系统，这听起来可能很熟悉。 虽然现代嵌入式系统运行 Linux，但较小的微处理器没有资源来这样做。 Rust 还针对那些超受限环境，Embedded Rust Book 和 Embedomicon 解释了如何为这些环境正确编写 Rust。

要进入裸机世界🤘，我们必须在代码中添加一行：#![no_std]。 这个 crate 宏告诉 Rust 不要链接到标准库。 相反，它只链接到 core。 Embedonomicon 非常简洁地解释了这意味着什么：

core crate 是 std crate 的子集，它对程序将在其上运行的系统做出零假设。 因此，它为语言原语（如浮点数、字符串和切片）提供 API，以及公开处理器功能（如原子操作和 SIMD 指令）的 API。 但是，它缺少任何处理堆内存分配和 I/O 的 API。

对于应用程序，std 不仅仅是提供一种访问操作系统抽象的方法。 std 还负责设置堆栈溢出保护、处理命令行参数以及在调用程序的主函数之前生成主线程。 #![no_std] 应用程序缺少所有标准运行时，因此如果需要它必须初始化自己的运行时。

这听起来有点可怕，但让我们一步一步来。 我们首先将上面的 panic-y 素数程序声明为 no_std：

#![no_std]
static PRIMES: &[i32] = &[2, 3, 5, 7, 11, 13, 17, 19, 23];

#[no_mangle]
extern "C" fn nth_prime(n: usize) -> i32 {
    PRIMES[n]
}

很遗憾，Embedonomicon 段落预示了这一点。因为我们没有提供核心依赖项的一些基础知识。 在列表的最顶部，我们需要定义在这种环境中发生恐慌时应该发生什么。 这是由恰当命名的恐慌处理程序完成的，Embedonomicon 给出了一个例子：

#[panic_handler]
fn panic(_panic: &core::panic::PanicInfo<'_>) -> ! {
    loop {}
}

这对于嵌入式系统来说是非常典型的，有效地阻止了处理器在崩溃发生后进行任何进一步的处理。 然而，这在 web 上不是好的行为，所以对于 WebAssembly，我通常选择手动发出无法访问的指令来阻止任何 Wasm VM 运行：

#[panic_handler]
fn panic(_panic: &core::panic::PanicInfo<'_>) -> ! {
    loop {}
    core::arch::wasm32::unreachable()
}

有了这个，我们的程序再次编译。 剥离和 wasm-opt 后，二进制文件大小为 168B。 极简主义再次获胜！

内存管理

当然，我们因非标准而放弃了很多。 没有堆分配，就没有 Box，没有 Vec，没有 String 和许多其他有用的东西。 幸运的是，我们可以在不放弃整个操作系统的情况下取回这些东西。

std 提供的很多东西实际上只是来自 core 的另一个称为 alloc 的东西。 alloc 包含有关内存分配和依赖于它的数据结构的所有内容。 通过导入它，我们可以重新获得我们信任的 Vec。

#![no_std]
// One of the few occastions where we have to use `extern crate`
// even in Rust Edition 2021.
extern crate alloc;
use alloc::vec::Vec;

#[no_mangle]
extern "C" fn nth_prime(n: usize) -> usize {
    // Please enjoy this horrible implementation of
    // The Sieve of Eratosthenes.
    let mut primes: Vec<usize> = Vec::new();
    let mut current = 2;
    while primes.len() < n {
        if !primes.iter().any(|prime| current % prime == 0) {
            primes.push(current);
        }
        current += 1;
    }
    primes.into_iter().last().unwrap_or(0)
}

#[panic_handler]
fn panic(_panic: &core::panic::PanicInfo<'_>) -> ! {
    core::arch::wasm32::unreachable()
}

当然，尝试编译它会失败——我们实际上并没有告诉 Rust 我们的内存管理是什么样的，Vec 需要知道它才能运行。

$ cargo build --target=wasm32-unknown-unknown --release
error: no global memory allocator found but one is required; 
  link to std or add `#[global_allocator]` to a static item that implements 
  the GlobalAlloc trait

error: `#[alloc_error_handler]` function required, but not found

note: use `#![feature(default_alloc_error_handler)]` for a default error handler

在撰写本文时，在 Rust 1.67 中，你需要提供一个在分配失败时调用的错误处理程序。 在下一个版本中，Rust 1.68 default_alloc_error_handler 已经稳定下来，这意味着每个非标准的 Rust 程序都将带有这个错误处理程序的默认实现。 如果你仍想提供自己的错误处理程序，你可以：

#[alloc_error_handler]
fn alloc_error(_: core::alloc::Layout) -> ! {
    core::arch::wasm32::unreachable()
}

有了这个复杂的错误处理程序，我们最终应该提供一种方法来进行实际的内存分配。 就像我在 C 到 WebAssembly 的文章中一样，我的自定义分配器将是一个最小的 bump 分配器，它往往又快又小，但不会释放内存。 我们静态分配一个 arena 作为我们的堆，并跟踪“空闲区域”的开始位置。 由于我们不使用 Wasm 线程，因此我也会忽略线程安全。

use core::cell::UnsafeCell;

const ARENA_SIZE: usize = 128 * 1024;
#[repr(C, align(32))]
struct SimpleAllocator {
    arena: UnsafeCell<[u8; ARENA_SIZE]>,
    head: UnsafeCell<usize>,
}

impl SimpleAllocator {
    const fn new() -> Self {
        SimpleAllocator {
            arena: UnsafeCell::new([0; ARENA_SIZE]),
            head: UnsafeCell::new(0),
        }
    }
}

unsafe impl Sync for SimpleAllocator {}

#[global_allocator]
static ALLOCATOR: SimpleAllocator = SimpleAllocator::new();

将 #[global_allocator] 全局变量标记为管理堆的实体。 此变量的类型必须实现 GlobalAlloc 特性。 特性上的 GlobalAlloc 方法都使用 &self，所以如果你想修改数据类型中的任何值，你必须使用内部可变性。 我这里选择了UnsafeCell。 使用 UnsafeCell 使我们的结构隐式 !Sync，Rust 不允许全局静态变量。 这就是为什么我们还必须手动实现 Synctrait 来告诉 Rust 我们知道我们有责任使这种数据类型成为线程安全的（而我们完全忽略了这一点）。

该结构被标记为 #[repr(C)] 的原因很简单，以便我们可以手动指定对齐方式。 这样我们就可以确保即使是 arena 中的第一个字节（以及我们返回的第一个指针的扩展）也具有 32 位对齐，这应该可以满足大多数数据结构。

现在为特征的 GlobalAlloc 的实际实现：

unsafe impl GlobalAlloc for SimpleAllocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let size = layout.size();
        let align = layout.align();

        // Find the next address that has the right alignment.
        let idx = (*self.head.get()).next_multiple_of(align);
        // Bump the head to the next free byte
        *self.head.get() = idx + size;
        let arena: &mut [u8; ARENA_SIZE] = &mut (*self.arena.get());
        // If we ran out of arena space, we return a null pointer, which
        // signals a failed allocation.
        match arena.get_mut(idx) {
            Some(item) => item as *mut u8,
            _ => core::ptr::null_mut(),
        }
    }

    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {
        /* lol */
    }
}

#[global_allocator] 不仅仅是 #[no_std]！你还可以使用它来覆盖 Rust 的默认分配器并将其替换为你自己的分配器，因为 Rust 的默认分配器消耗大约 10K Wasm 空间。

wee_alloc

当然，你不必自己实现分配器。 事实上，依靠经过良好测试的实施可能是明智的。 处理分配器中的错误和微妙的内存损坏并不好玩。

许多指南推荐 wee_alloc，这是一个非常小的 (<1KB) 分配器，由 Rust WebAssembly 团队编写，也可以释放内存。 可悲的是，它似乎没有得到维护，并且有一个关于内存损坏和内存泄漏的未解决问题。

在任何相当复杂的 WebAssembly 模块中，Rust 的默认分配器消耗的 10KB 只是整个模块大小的一小部分，所以我建议坚持使用它并知道分配器经过良好测试和性能。

wasm-bindgen

现在我们已经完成了几乎所有困难的事情，我们已经看到了使用 wasm-bindgen 为 WebAssembly 编写 Rust 的便捷方法。

wasm-bindgen 的关键特性是 #[wasm_bindgen] 宏，我们可以将它放在我们想要导出的每个函数上。 这个宏添加了我们在本文前面手动添加的相同编译器指令，但它还做了一些更有用的事情。

例如，如果我们将上面的宏添加到我们的 add 函数中，它会发出另一个以数字格式返回我们的函数 __wbindgen_describe_add 的描述。 具体来说，我们函数的描述符如下所示：

Function(
    Function {
        arguments: [
            U32,
            U32,
        ],
        shim_idx: 0,
        ret: U32,
        inner_ret: Some(
            U32,
        ),
    },
)

这是一个非常简单的函数，但是 wasm-bindgen 中的描述符能够表示非常复杂的函数签名。

展开: 如果你想查看宏发出的代码 #[wasm_bindgen]，请使用 rust-analyzer 的“递归扩展宏”功能。 你可以通过命令面板在 VS Code 运行它。

这些描述符有什么用？ wasm-bindgen 不仅提供了一个宏，它还附带了一个 CLI，我们可以使用它来对我们的 Wasm 二进制文件进行后处理。 CLI 提取这些描述符并使用此信息生成自定义 JavaScript 绑定（然后删除所有不再需要的描述符函数）。 生成的 JavaScript 具有处理更高级别类型的所有例程，允许你无缝传递类型，例如字符串、ArrayBuffer 甚至闭包。

如果你想为 WebAssembly 编写 Rust，我推荐 wasm-bindgen。wasm-bindgen 不适用于 #![no_std]，但实际上这很少成为问题。

wasm-pack

我还想提一下 wasm-pack，这是另一个用于 WebAssembly 的 Rust 工具。我们使用全套工具来编译和处理我们的 WebAssembly 以优化最终结果。wasm-pack 是一种对大多数这些过程进行编码的工具。它可以使用针对 WebAssembly 优化的所有设置引导一个新的 Rust 项目。它构建项目并使用所有正确的标志调用 cargo，然后它调用 wasm-bindgen CLI 来生成绑定，最后它运行 wasm-opt 以确保我们不会留下任何性能问题。wasm-pack 还能够准备你的 WebAssembly 模块以发布到 npm，但我个人从未使用过该功能。

总结

Rust 是一种用于 WebAssembly 的优秀语言。启用 LTO 后，你将获得非常小的模块。Rust 的 WebAssembly 工具非常出色，自从我第一次在 Squoosh 中使用它以来，它变得更好了。发出的胶水代码 wasm-bindgen 既现代又 tree-shaken。看到它在幕后是如何工作的，我从中获得了很多乐趣，它帮助我理解和欣赏所有工具为我所做的事情。我希望你也有同感。非常感谢 Ingrid、Ingvar 和 Saul 审阅这篇文章。