大家好，很高兴又见面了，我是"高级前端进阶"，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发，您的支持是我不断创作的动力。

本文大部分内容来自于 Ingvar Stepanyan 在 2023 年 8 月 3 日发布的一篇文章《Bringing Sharp to WebAssembly and WebContainers》，但是经过了部分修改。因为我本身对于 WebAssembly 的最新动态比较关注，所以特地将它翻译过来，希望对大家有帮助。

为什么 Sharp 开始支持 WebAssembly

WebContainers 是一个允许开发者直接在浏览器中运行 Node.js 的环境。 它可以轻松处理任何 JavaScript，包括 npm 模块。 然而，在图像处理和优化方面，Gatsby、Astro、Next.js 等工具链的用户都面临着诸多困难。

用于图片任务的最流行的库是源自 Squoosh.app 的 @squoosh/lib（遗憾的是，不再作为库进行维护）和 Sharp。

• libSquoosh 是一种实验性方法，可直接在 JavaScript 程序中运行 Squoosh Web 应用程序中的所有编解码器。libSquoosh 使用工作池（worker pool）来并行处理图像， 从而可以同时将相同的编解码器应用于许多图像。libSquoosh 的速度足够快，可以一次压缩许多图像。目前在 Github 上有 19.4k 的 star、妥妥的前端优质开源项目，但是目前已经放弃维护。
• Sharp：高速 Node.js 模块的典型用例是将常见格式的大图像转换为较小的、网络友好的不同尺寸的 JPEG、PNG、WebP、GIF 和 AVIF 图像。由于使用了 libvips，调整图像大小通常比使用最快的 ImageMagick 和 GraphicsMagick 设置快 4 倍到 5 倍。色彩空间、嵌入式 ICC 配置文件和 Alpha 透明度通道均已正确处理。 Lanczos 重采样确保不会为了速度而牺牲质量。除了图像大小调整之外，还可以进行旋转、提取、合成和伽玛校正等操作。

Sharp 支持运行在大多数 Node.js >= 14.15.0 的现代 macOS、Windows 和 Linux 系统上，不需要任何额外的安装或运行时依赖项。本文将重点探讨将 Sharp 移植到 WebAssembly 时遇到的诸多问题。

将 Node-API 移植到 WebAssembly

libvips 支持 WebAssembly

什么是 libvips

libvips 是一个需求驱动的水平线程图像处理库。 与类似的库相比，libvips 运行速度快并且占用内存很少， libvips 根据 LGPL 2.1+ 获得许可。

libvips 有大约 300 个运算，涵盖：算术、直方图、卷积、形态运算、频率过滤、颜色、重采样、统计等。 它支持多种数值类型，从 8 位 int 到 128 位复数。 图像可以有任意数量的波段。 它支持多种图像格式，包括 JPEG、JPEG2000、JPEG-XL、TIFF、PNG、WebP、HEIC、AVIF、FITS、Matlab、OpenEXR、PDF、SVG、HDR、PPM / PGM / PFM、CSV、GIF、 分析、NIfTI、DeepZoom 和 OpenSlide。 它还可以通过 ImageMagick 或 GraphicsMagick 加载图像，使其能够使用 DICOM 等格式。

目前 libvips 在 Github 上开源，有超过 8.3k 的 star、妥妥的前端优质开源项目。

Sharp 使用 libvips

在图像处理上，Sharp 在底层使用了 libvips 。 本质上，Sharp 是 libvips 的高级包装器，具有 Node.js 友好的 API。

反过来，libvips 使用 GLib、libjpeg、cgif、libimagequant 和许多其他库来支持不同的格式和处理操作。 确保所有这些依赖项都编译为 WebAssembly、选择兼容标志并在必要时 patch 源代码是一项艰巨的工作，在将 Sharp / libvips 移植到 Wasm 时引入了更大的复杂性。

幸运的是， Kleis Auke Wolthuizen 创建了 wasm-vips（用于浏览器和 Node.js 的 libvips，使用 Emscripten 编译为 WebAssembly，目前在 Github 通过 MIT 协议开源，有接近 0.5k 的 star），这是一个能够在浏览器中运行的 libvips 的 JavaScript / WebAssembly 包装器，其 patched 了所有依赖项并编写了一个构建脚本，该脚本在构建 wasm-vips 本身之前下载并应用 patch 并使用正确的标志构建 libvips。

在将 Sharp 迁移到 WebAssembly 的过程中充分利用了该脚本，添加仅构建 libvips 本身的功能，并包含 Sharp 所需的 C++ 绑定。 然后，成功地将绑定与 Sharp 自己的 C++ 代码一起编译成单个 WebAssembly 模块。 在整个工作过程中还添加了对以前缺失的格式（如 AVIF 和 SVG）的支持以及一些构建优化。

SVG 和文本支持

在将 Sharp 迁移到 WebAssembly 的过程中， libvips 通常使用的 librsvg（一个用于渲染可扩展矢量图形 SVG 的小型库，与 GNOME 项目相关） 被替换为 resvg（可以用作 Rust 库、C 库以及 CLI 应用程序来渲染静态 SVG 文件）。

主要原因是 librsvg 有很多依赖项，尚未移植到 WebAssembly。 同时，resvg 是一个 Rust 库，Rust 有更好的交叉编译能力，包括编译到 WebAssembly。 除了更容易的 WebAssembly 支持之外，resvg 也值得一试，因为它具有更好的 SVG 兼容性和速度。

在本地，resvg 从系统字体目录中读取所有字体，收集解析的元数据，然后可以使用它按请求的名称、粗细和其他参数查找字体。 在 WebAssembly 中，事情就没那么容易了。

在 Node.js 或 WASI 中，开发者可以将系统字体目录暴露给模块，但是在浏览器中又该如何做？

开发者可以通过 DOM 或 Canvas 渲染文本，但这无法访问库所需的原始字体文件。 有像 Google Fonts 这样的 CDN，但是在渲染 SVG 时下载字体文件非常昂贵，尤其是当想提前阅读大量字体时。 WICG 本地字体访问 API 可能是该领域最有前途的解决方案，因为它提供对原始系统字体文件的访问，但目前仅适用于 Chrome。

为了解决问题，resvg 维护者添加了对在渲染之前枚举给定 SVG 文件所需的字体的支持， 从而解决必须提前下载所有现有字体才能读取其元数据的问题，而在使用 CDN 时，由于要下载的数据量巨大，这不是一个最好的选择。

Sharp 支持 WebAssembly 后会更仔细地考虑支持文本和 SVG，但就目前而言，有太多未解决的问题，完全禁用这些功能似乎比渲染可能损坏的内容（文本等元素在结果图像中丢失）要好。

同步启动

该项目的一个有趣的限制是，对于 StackBlitz 来说，兼容性至关重要，这样用户就不必更改已经使用 Sharp 的 Node.js 代码来使其在 WebContainers 中工作。 这意味着，当 Sharp 通过简单的 require 同步加载和实例化本机模块时，WebAssembly 也需要同步初始化。

事实上，Chrome 完全拒绝在主线程上编译大于 4KB 的模块，尽管这个尺寸目前已经相应改变。 幸运的是，WebContainers 在 Workers 中运行用户代码，以允许长时间阻塞操作而不阻塞 UI。 因此，需要做的就是通过 -s WASM_ASYNC_COMPILATION=0 标志用同步行为覆盖 Emscripten 的默认行为。

接下来，Sharp 本身（或 libvips）使用 GLib 线程池来分割和管理图像处理任务。 WebAssembly 支持在底层使用 Web Workers + 共享内存 + 原子操作的线程。

Web Worker 不会同步生成，而是安排一个任务在下一个事件循环标记上生成一个新的 Worker。 这种行为对于大多数 JavaScript 用户来说是不可见的，但使得 Workers 很难从 WebAssembly 中使用。

pthread_create(&thread_id, NULL, thread_callback, &arg);
pthread_join(thread_id, NULL);

下面将 C 代码翻译成 JS 伪代码：

let isReady = false;
let worker = new Worker(...);

// worker sends a message once it’s initialised
worker.onmessage = msg => {
  if (msg.type  === 'ready') {
    isReady = true;
  }
};

while (!isReady) {}

new Worker(...) 只会为 Worker 创建绑定，但会等到当前浏览器循环周期结束才实际生成它，那时 worker 才能发布“ready”消息。 但是，上面代码使用 while (!isReady) {} 循环阻止了浏览器事件循环，该循环等待工作线程的响应，是一个典型的死锁例子。

为了解决这个限制，Emscripten 有一个设置来预初始化自己的线程池 (-s PTHREAD_POOL_SIZE=...)。 使用时，Emscripten 将在启动时创建并异步等待所有 Worker，并且所有后续的 pthread_create 操作都不必等待事件循环。 相反，可以通过 WebAssembly 共享内存共享数据。

在上面的例子中，启动是完全同步的，所以也不能使用这个选项，必须找到一种方法来完全避免使用线程池。

事实证明，浏览器中的 Web Worker API 和 Node.js 中的 worker_threads Worker API 之间鲜为人知但显著的区别之一是后者完全按照要求行事： new worker_threads.Worker(...) 立即生成一个工作线程 ，这允许阻止当前线程的事件循环。 WebContainer 也以 Node.js 兼容的方式实现了如此模糊的差异！

Emscripten 无法利用它的原因是流程如下：

• 主线程通过 new Worker 创建一个 Worker 并订阅其消息。
• 主线程向 Worker 发送包含 Wasm 模块和其他一些其他消息“load”。
• Worker 通过 Wasm 模块接收“load”消息，加载相关 JS 文件，并异步初始化运行时。
• Worker 初始化完成， 然后它向主线程发送一条“loaded”消息。
• 主线程收到“loaded”消息。
• 主线程向 Worker 发送一条消息“run”，其中包含指向 pthread 回调的指针和其他相关信息。
• 工作线程收到“run”消息并执行 pthread

Node.js 可以同步执行步骤 1-4，但在步骤 5 上接收消息需要异步等待事件循环，因为消息是作为常规事件接收的。 而且，正如之前提到的，我们无法承受任何异步操作，因为启动必须完全同步。

但是如果根本没有等待工作进程初始化怎么办？ worker.postMessage 不会立即发送消息，而是将它们添加到内部队列中。 它的设计方式是为了确保不会丢失消息，并且如果用户在 Worker 准备好接受消息之前发送消息，也不会收到错误消息。

在 Node.js 中，这意味着我们可以生成一个新的 Worker，发送“load”和“run”命令，并阻止（例如通过 pthread_join）等待 WebAssembly 共享内存中的条件，所有这些都在同一个事件循环 tick 中 ，不会死锁或等待任何异步事件。

新流程如下所示：

• 主线程通过 new Worker 创建一个 Worker 并订阅其消息。
• 主线程向 Worker 发送包含 Wasm 模块和其他一些消息“load”。
• 主线程向 Worker 发送一条消息“run”，其中包含指向 pthread 回调的指针和其他相关信息。
• Worker 通过 Wasm 模块接收“load”消息，加载相关 JS 文件，并异步初始化运行时。
• Worker 将所有其他传入消息存储到队列中（在本例中，它只是一条消息“run”）。
• Worker 初始化完成。 它向主线程发送一条“loaded”消息。
• Worker 执行所有排队的消息（在本例中，消息“run”，因此它执行 pthread）。

作者在上面的 Emscripten PR 中实现了这一点，因此从版本 3.1.29 开始，开发者可以在 Node.js 中使用 PThreads，而无需完全使用 Worker 池，或者生成比池中可用线程更多的线程，而不会出现死锁。 与 -s WASM_ASYNC_COMPILATION=0 结合使用，启动支持完全同步。

I/O

Node.js 有各种 I/O 句柄对象 ，包括 Workers。 所有此类句柄都有用于显式引用控制的方法：.ref() 将其标记为强引用，.unref() 将其标记为弱引用。 仅当所有强引用句柄都未被引用或被垃圾回收时，Node.js 才会退出。 这就是 Node.js 服务器如何无限期地保持活动状态，或者 CLI 在等待用户输入或 fetch 调用响应时不会意外退出的原因。

由于 Worker 只是另一个强引用句柄，因此 Node.js 过于谨慎，在 Worker 仍在执行时需要保持主进程处于活动状态。 例如，创建一个具有无限 while（true）的 worker； 即使阻塞代码在后台线程中运行，循环也会使主进程永远保持活动状态。 阻止它的唯一方法是强制 .terminate() Worker 或至少 .unref() 将其标记为弱引用。

两者之间，.unref() 是更优雅的解决方案。 但是，开发者需要知道何时调用它：如果太晚取消引用 Worker，应用程序会出现阻塞并且不会退出，如果太早取消引用，将不会从 Worker 获得重要的 onmessage 事件，因为应用程序已经退出并且异步流程将被破坏：

const { Worker } = require('worker_threads');

let worker = new Worker('postMessage("ready");', { eval: true });

worker.onmessage = (event) => {
  // never reached
  console.log("Worker initialised, now let's do some actual work");
};

worker.unref();

多线程 Emscripten 应用程序通常通过使用 -s EXIT_RUNTIME 设置来解决此问题，该设置会在主 C 函数完成执行时强制退出应用程序。 也就是说，它调用 process.exit(0) 来终止 Node.js 应用程序以及任何生成的工作线程。 这适用于可执行文件，但不适用于库，因为它们没有主入口点，而是一个单独导出的列表，即使有，也不想在任意库之后杀死整个应用程序。

Dominic Elm 提出了一个解决方案，即 ref / .unref “dance”，以便每次发送一些实际工作（PThread 函数） ）到 Worker 时，它会被强引用，一旦知道它完成执行并作为空闲 Worker 位于 Emscripten 池中，就会再次将其标记为弱引用。 代码最终比查找相关测试并编写随附的 PR 解释简单得多，并且它非常适合常见场景！

加上这些调整，启动现在完全同步，并且测试在图像处理完成后退出，而不是更早，这使得该模块与本机插件 API 完全兼容。

Sharp 顺利支持 WebAssembly

WebAssembly 版本的 Sharp 基准测试结果看起来非常有希望（所有执行都将并发设置为 2，因为这是在 WebContainers 环境中设置的，并且使用 Turbofan 减少启动开销）：

最显著的区别在于依赖 SIMD 的编解码器和操作。 虽然 WebAssembly 具有 SIMD 支持，但必须使用内在函数来利用 Emscripten 的可移植层，或者在单独的汇编文件中手动编写 WebAssembly 指令，就像其他架构一样。 虽然正在为使用 SIMD 内在函数的库交叉编译 SIMD 支持，但不幸的是，其他一些库依赖于原始汇编，目前必须使用较慢的实现进行编译。

总而言之，这是一个非常令人兴奋的项目。 虽然仍然缺少一些功能，但它将解锁新的用例，对 StackBlitz.com 上的许多用户以及其他依赖于图像处理或优化的用户非常有利。

参考资料

https://github.com/GoogleChromeLabs/squoosh

https://www.npmjs.com/package/@squoosh/lib

https://github.com/lovell/sharp

https://blog.stackblitz.com/posts/bringing-sharp-to-wasm-and-webcontainers/

https://github.com/libvips/libvips

https://github.com/kleisauke/wasm-vips

https://github.com/GNOME/librsvg

https://github.com/RazrFalcon/resvg

https://platform.uno/blog/using-webassembly-modules-in-c/

https://www.libvips.org/2019/11/29/True-streaming-for-libvips.html