Emscripten 帮助将 C 和 C++ 代码移植到 Web 上运行。在进行此类移植时，我们必须绕过 Web 平台的限制，其中之一是代码必须是**异步**的：您不能在 Web 上运行长时间运行的代码，它必须拆分为事件，因为其他重要的事情——渲染、输入等——在您的代码运行时无法发生。但是，C 和 C++ 代码通常是**同步**的！这篇文章将回顾 Emscripten 如何使用各种方法来处理此问题。我们将了解预加载虚拟文件系统以及最近添加的一个选项，该选项可以在特殊的解释器中执行编译后的代码。我们还将有机会玩一些 Doom！

首先，让我们更具体地了解一下问题。例如，考虑一下

FILE *f = fopen("data.txt", "rb");
fread(buffer, 100, 1, f);
fclose(f);

此 C 代码同步打开文件并从中读取。现在，在浏览器中，我们没有本地文件系统访问权限（内容出于安全原因而被沙盒化），因此在读取文件时，我们可能会向服务器发出远程请求，或从 IndexedDB 加载——这两者都是异步的！那么，任何东西是如何被移植的呢？让我们回顾三种解决此问题的方法。

1. 预加载到 Emscripten 的虚拟文件系统

Emscripten 的第一个工具是**虚拟内存文件系统**，它在 JavaScript 中实现（大部分代码归功于 inolen），可以在程序运行之前预先填充。如果您知道将访问哪些文件，则可以预加载它们（使用 emcc 的–preload-file 选项），当代码执行时，文件的副本已在内存中，随时可以进行同步访问。

在少量到中等数量的数据上，这是一种简单且有用的技术。编译后的代码不知道它正在使用虚拟文件系统，对它来说一切看起来都很正常且同步。一切正常。但是，对于大量数据，将所有数据预加载到内存中可能代价过高。您可能只需要每个文件一小段时间——例如，如果您将其加载到 WebGL 着色器中，然后忘记 CPU 端的内容——但如果全部预加载，则必须一次将所有内容都保留在内存中。此外，Emscripten 虚拟文件系统努力尽可能地兼容 POSIX，支持权限、mmap 等，这些会增加某些应用程序中可能不需要的开销。

这有多大问题不仅取决于您加载的数据量，还取决于浏览器和操作系统。例如，在 32 位浏览器上，您通常限于 4GB 的虚拟地址空间，并且碎片可能会成为问题。出于这些原因，64 位浏览器有时可以成功运行需要大量内存的应用程序，而 32 位浏览器则失败（或偶尔失败）。在某种程度上，您可以尝试通过将数据拆分为单独的资产包来解决内存碎片问题，通过分别多次运行 Emscripten 的 文件打包器，而不是使用–preload-file 一次加载所有内容。每个包都是您在页面上加载的 JavaScript 的组合，以及包含您在该资产包中打包的所有文件的数据的二进制文件，因此，通过这种方式，您获得了多个较小的文件而不是一个大的文件。您还可以使用–no-heap-copy 运行文件打包器，这将使下载的资产包数据保留在单独的类型化数组中，而不是将它们复制到程序的内存中。但是，即使在最佳情况下，这些也只会在某些情况下以不可预测的方式帮助解决内存碎片问题。

因此，预加载所有数据并非总是可行的解决方案：对于大量数据，我们可能没有足够的内存，或者碎片可能是问题。此外，我们可能事先不知道我们需要哪些文件。总的来说，即使预加载对某个项目有效，我们仍然希望避免它，以便尽可能少地使用内存，因为这样通常运行速度更快。这就是我们需要另外两种方法来处理同步代码问题的原因，我们现在将讨论这些方法。

2. 重构代码以使其异步

第二种方法是重构代码以将同步代码转换为异步代码。Emscripten 提供了可用于此目的的异步 API，例如，上面示例中的**fread()** 可以替换为异步网络下载（emscripten_async_wget, emscripten_async_wget_data），或本地缓存数据在 IndexedDB 中的异步访问（emscripten_idb_async_load, emscripten_idb_async_store 等）。

如果您有执行文件系统访问之外的其他操作的同步代码，例如渲染，Emscripten 提供了一个通用的 API 来执行异步回调（emscripten_async_call）。对于应从浏览器的事件循环中每帧调用一次的主循环的常见情况，Emscripten 有一个主循环 API（emscripten_set_main_loop 等）。

具体来说，**fread()** 将被类似以下内容替换：

emscripten_async_wget_data("filename.txt", 0, onLoad, onError);

其中第一个参数是远程服务器上的文件名，然后是一个可选的 void* 参数（将传递给回调），然后是加载和错误时的回调。棘手的是，应该在 fread() 之后执行的代码需要放在 onLoad 回调中——这就是重构的来源。有时这很容易做到，但可能并非如此。

将代码重构为异步通常是**最佳**做法。它使您的应用程序以其预期的方式使用 Web 上可用的 API。但是，它确实需要更改您的项目，并且可能需要以事件友好的方式设计整个项目，如果项目尚未以这种方式构建，这可能会很困难。出于这些原因，Emscripten 还有另一种方法可以帮助您解决此问题。

3. Emterpreter：自动将同步代码异步化

**Emterpreter** 是 Emscripten 中一个相当新的选项，最初是出于启动时间原因 而开发的。它将您的代码编译成**二进制字节码**，并将其与一个小型**解释器**(当然是用 JavaScript 编写的)一起提供，代码可以在其中执行。在解释器中运行的代码由我们“手动执行”，因此我们可以比普通 JavaScript 更轻松地控制它，并且可以添加暂停和恢复的功能，这正是我们将同步代码转换为异步代码所需的。因此，**Emterpreter-Async**（Emterpreter 加上对异步运行同步代码的支持）在现有的 Emterpreter 选项之上添加起来相当容易。

自动将同步代码转换为异步代码的想法在 2014 年夏天 Lu Wang 实习期间进行了试验：Asyncify 选项。Asyncify 在 LLVM 级别重写代码以支持暂停和恢复执行：您编写同步代码，编译器将其重写为异步运行。回到之前 fread() 的示例，Asyncify 将自动在该调用周围拆分函数，并将调用后的代码放入回调函数中——基本上，它做了我们在上面“重构代码以使其异步”部分中建议您手动执行的操作。这可以非常有效：例如，Lu 移植了 vim，这是一个包含大量同步代码的大型应用程序，到 Web 上。并且它可以工作！但是，由于 Asyncify 如何重组您的代码，我们在代码大小方面遇到了重大限制。

Emterpreter 的异步支持避免了 Asyncify 遇到的代码大小问题，因为它是一个运行字节码的解释器：字节码的大小始终相同（实际上，比 asm.js 小），我们可以在解释器中手动操作其控制流，而无需检测代码。

当然，在解释器中运行可能会非常慢，这个也不例外——速度可能比平时慢得多。因此，这不是您希望在其中运行大部分代码的模式。但是，Emterpreter 使您可以选择决定代码库的哪些部分是解释的，哪些部分不是解释的，这对有效使用此选项至关重要，我们现在将看到这一点。

让我们通过在 Doom 代码库上实践中展示此选项来具体说明。这是一个Doom 的普通移植（特别是 Boon：带有 Freedoom 开放艺术资产的 Doom 代码）。该链接只是使用 Emscripten 编译的 Doom，尚未使用同步代码或 Emterpreter。在该链接中，游戏看起来可以工作——我们还需要其他东西吗？事实证明，我们在 Doom 中需要在两个地方进行同步执行：首先，用于文件系统访问。由于 Doom 来自 1993 年，因此与今天的硬件相比，游戏的大小非常小。我们可以预加载所有数据文件，一切正常（这就是该链接中发生的事情）。到目前为止，一切顺利！

但是，第二个问题比较棘手：在大多数情况下，Doom 在主循环的每次迭代中渲染整个帧（我们可以从浏览器的事件循环中一次调用一个），但是它还使用同步代码执行一些视觉效果。这些效果在第一个链接中没有显示——Doom 粉丝可能已经注意到缺少了一些东西！:)

这是启用了 Emterpreter-Async 选项的构建。这会将整个应用程序作为字节码在解释器中运行，正如预期的那样，它非常慢。暂时忽略速度，您可能会注意到，当您启动游戏时，在您开始玩之前有一个“擦除**”效果，这在之前的版本中不存在。它看起来有点像下降的波浪。这是一个截图

main() => D_DoomMain() => D_Display() => D_Wipe() => I_uSleep()

main() => MainLoop() => RunTasks() => PhysicsTask() => HardWork()

main() => MainLoop() => RunTasks() => IOTask() => LoadFile()