模块化编程（modular programming）是一种软件设计模式，它将软件分解为若干独立的、可替换的、具有预定功能的模块，每个模块实现一个功能，各模块通过接口（输入输出部分）组合在一起形成最终程序。当下流行的JavaScript、Python、Rust、Java 等语言都有具有模块(包)管理，甚至 C++20 开始都引入了模块化系统。

在本文中，我们将讨论驱动 WebAssembly 程序运行的核心组件——引擎。首先，本文将简要介绍一个语言的引擎包括哪些主要组成部分，它们如何配合完成工作，尝试构建一个概念模型。之后，就几款社区流行的开源引擎，分别介绍各自的特点。

专注于 WebAssembly 技术推广的“字节码联盟”（Bytecode Alliance），刚刚宣布其已注册成为一家 502(c)(6) 类性质的非盈利组织。除了 Fastly、英特尔、Mozilla、微软等元老，该组织还迎来了包括 ARM、DFINITY 基金会、Embark 工作室、谷歌、Shopify、加州大学圣迭戈分校（UCSD）等企业和高效的加盟。

在上周发布了 Chrome 90 之后，谷歌周四又推出了定于下月到来的 Chrome 91 的新 Beta 测试版本。Phoronix 指出，Chrome 91 Beta 将默认启用 WebTransport 和 WebAssembly SIMD 这两项实验性功能。前者是一套全新的协议框架 / 标准，适合与远程服务器展开安全的多路传输通信。后者则是 WebSockets 的一个替代方案，并提供了类似 UDP 的数据报双向通信 API 。

开源游戏引擎Godot 3.2已按计划在今年1月发布了稳定版本，Godot 3.2基于此前的3.1版本进行了重大改进，带来了数十个新的重要功能以及数百个错误修复和功能增强。Godot团队也希望通过这个拥有更高可用性的版本帮助游戏开发者不断改进他们的作品。团队还表示可以将Godot 3.2视作LTS版本，到时将会有定期的维护版本（3.2.x）带来重要的错误修复、可用性增强和一些新功能，直至大家过渡到Godot 4（4.0版本计划于今年中旬发布）。下载地址Godot 3.2下载地址：https://godotengine.org/download 新功能概要文档：提供了更丰富的内容，并为在线版本应用了更好的主题值得一提的是，这也是Godot首次提供多语言版本的文档。Mono/C#：支持Android和WebAssemblyGodot 3.0 通过使用 Mono框架实现了对C#的初始支持，Godot 3.1则增加了对将项目导出到桌面平台（Linux, macOS和 Windows）的支持。到了Godot 3.2，团队的C#维护者 Ignacio先后实现了对 Android 和 WebAssembly 的支持。另外，对AOT编译的初始支持也已合并到代码中，但是在Godot 3.2中尚未启用它，因为团队需要为其进行其他测试和打包更改。AOT将为WebAssembly端口提供更好的性能，这也是即将到来的支持iOS平台的先决条件，后者将在更高的3.2.x版本中提供。▲WASM项目展示：小游戏Dodge the Creeps demo 的 C#版本运行于Firefox浏览器中AR/VR：支持Oculus Quest和ARKit对视觉着色器系统（Visual Shaders）的重大改进改进图形/渲染功能MSAA对OpenGL ES 2渲染器的消除混叠支持，以及对GLES 2代码路径的其他改进。此外，默认渲染设置已经过调整和优化，开发者可在默认情况下获得更好的图像质量和性能。3D资源管理：glTF 2.0和FBX网络：支持WebRTC和WebSocket此版本提供了对WebRTC的支持，这是一种可用于多人游戏的实时通信协议。另外在调试方面还增加了一个用于分析网络拥塞问题的网络分析器，可帮助开发者实时监控游戏的带宽使用情况。开发者能够通过该功能确定游戏中哪些节点正在执行最多的网络函数调用。对Android构建系统和插件系统的重构新的编辑器功能新版编辑器提供了对集成版本控制系统（VCS）的初始支持，以及更好的可视化脚本支持。编码工具2D：提供伪3D、纹理图集以及AStar2D等功能GUI：Anchor/margins workflow, RichTextLabel effects新增音频生成器和频谱分析仪改进凸分解算法支持计划Godot团队表示他们已尽可能保持3.1和3.2项目之间的兼容性，但仍会存在小部分影响兼容性的破坏性变更。对于选择停留在3.1分支上的用户，团队将在未来几个月内通过相关的错误修复和特定于平台的更改（尤其是3.1.3版本）继续对其进行维护。不过未来的主要更新将重点放在3.2分支上。关于Godot引擎游戏引擎是一个复杂的工具，因此很难用三言两语来概括Godot。这是一个快速概要，如果需要快速撰写关于Godot引擎的文章，可以自由复用该概要。Godot引擎是一款功能丰富的跨平台游戏引擎，可通过统一界面创建2D和3D游戏。它提供了一套全面的通用工具，因此用户可以专注于制作游戏，而无需重新发明轮子。游戏可以一键导出到多个平台，包括主要的桌面平台(Linux、macOS、Windows)以及移动平台(Android、iOS)和基于Web的(HTML5)平台。Godot在宽松的MIT许可证下完全自由且开源。没有附加条文，没有特许权使用费，没有任何要求。用户的游戏乃至引擎的每一行代码，都是他们的。Godot的开发完全独立且由社区驱动，允许用户以帮助塑造他们的引擎来满足他们的期望。它受到 软件自由保护 非营利组织的支持。摘自Godot中文文档：https://docs.godotengine.org/zh_CN/latest/

开源游戏引擎 Godot 3.2 已按计划在今年 1 月发布了稳定版本，Godot 3.2 基于此前的 3.1 版本进行了重大改进，带来了数十个新的重要功能以及数百个错误修复和功能增强。Godot 团队也希望通过这个拥有更高可用性的版本帮助游戏开发者不断改进他们的作品。

根据一项已发表的学术研究，使用WebAssembly的网站中大约有一半将其用于恶意目的。WebAssembly由Mozilla、谷歌、微软和苹果这四个主要的浏览器供应商协同创建，它引入了一种新的二进制文件格式，用于将代码从Web服务器传输到浏览器。一旦到达浏览器，WebAssembly代码（Wasm）就会以接近本地的速度执行，类似于已编译的C、C++或Rust代码。创建WebAssembly的目的是兼顾速度和性能。由于Wasm代码具有机器友好的二进制格式，因此它比等效的JavaScript格式小，但执行时速度也快许多倍。WebAssembly于2017年首次被提出，并于2019年底被批准为正式的W3C（万维网联盟）标准，目前受到所有主流浏览器的支持。在去年进行的一项学术研究项目中，来自德国布伦瑞克工业大学的四名研究人员研究了WebAssembly在Alexa上排名前100万的流行站点上的使用情况，以评估这种新技术的普及程度。他们加载了100万个网站中每个网站的三个随机页面，测量了WebAssembly的使用情况，以及每个网站运行代码所花费的时间。研究发现有 1,639个站点装载了总计1,950个Wasm模块，只有150个模块是独一无二的，有很多站点都在使用相同的 Wasm模块。研究小组还对每个网站正在加载的Wasm代码的性质进行了研究。他们手动分析代码，查看函数名称和嵌入的字符串，然后映射出相似代码的集群。研究人员表示，他们分析的绝大多数代码样本都用于加密货币挖掘（样本的32%）和在线游戏（样本的29.3%）。这两类Wasm代码在本质上是恶意的。用于加密货币挖掘的Wasm模块通常是所谓的加密劫持（通过挖矿驱动）攻击的一部分。另一类涉及打包在混淆的Wasm模块中的WebAssembly代码，这些模块有意隐藏其内容，一般来说是恶意广告的一部分。由于代码经常在多个域中重复使用，这些模块已被用于超过一半的样本网站。且将WebAssembly代码用于恶意目的的行为有在不断增加的趋势。研究小组还表示，这可能还只是“冰山一角”。为此，他们呼吁网络安全公司参与进来，应对新技术带来的新威胁。

近日 Oracle 开源了其在 GraalVM 中实现的 WebAssembly 引擎 GraalWasm，开发团队介绍，GraalWasm 当前实现了 WebAssembly MVP（最小可行产品）规范，并且可以以二进制格式运行 WebAssembly 程序，该程序是由诸如 Emscripten 之类的编译器后端生成的。

近日 Oracle 开源了其在 GraalVM 中实现的 WebAssembly 引擎 GraalWasm，开发团队介绍，GraalWasm 当前实现了 WebAssembly MVP（最小可行产品）规范，并且可以以二进制格式运行 WebAssembly 程序，该程序是由诸如 Emscripten 之类的编译器后端生成的。支持 WebAssembly 扩展了 GraalVM 与其它支持的语言一起执行的能力，进一步有望使其成为通用编程语言执行平台。不过目前 GraalWasm 还是一个非常早期的实现，并且处于实验模式。为了实现 GraalWasm，开发团队使用 GraalVM 作为提供有效局部评估引擎的平台，使用 GraalVM 的 Truffle API，首先实现了 WebAssembly 二进制文件的解释器。WebAssembly 的半结构化格式能够轻松地恢复程序的控制流结构，从而使存储代码的内存数据结构可以表示为 AST。用 AST 表示的程序的解释器可以用非常简单的方式编写，但是，尽管基于 AST 的数据结构更易于检查和操作，但它们确实存在引入额外内存开销的缺点。另一方面，基于位码的代码表示不需要为每个基本指令实例化树节点，这就是基于位码的 GraalVM 解释器通常具有更小的内存占用的原因。由于每个 WebAssembly 块仅包含线性指令序列，因此 GraalWasm 能够结合两种解释器方法中的最佳方法：AST 叠加在 WebAssembly 的控制流指令之上，如 if 和 loop。但是每个块都用一个 Truffle AST 节点，称之为 Wasm 块节点，这减少了内存占用，因为每个块中的单个指令不需要单独的节点对象。此外，GraalWasm 块节点不会复制原始指令流的各个部分，而是仅将指针包含在 WebAssembly 二进制文件的字节数组中。 文本 WebAssembly、二进制 WebAssembly 与 GraalWasm AST 之间的对应关系在此数据结构之上实现的解释器是基于 AST 的解释器和基于位码的解释器之间的混合体。在较高的控制流级别上，它在适当的基本块之间分配。在每个基本块中，解释器在迭代该基本块的操作码的解释循环内完成。这种设计使转译更容易理解，并简化了部分评估。运行时，解释器和程序将传递到 Truffle 的局部评估引擎，然后该引擎将解释器专门用于程序，并将专门的代码传递给 GraalVM 编译器，最终为目标平台生成高效的汇编代码。关于 GraalWasm 的更多技术细节可以查看官方博客：https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-in-graalvm-25cd0400a7f2开发团队还介绍了项目接下来的发展规划，其表示，GraalWasm 的动机之一是扩展 GraalVM 的 node.js 实现支持的 API 集，WebAssembly 支持的增加将使其能够实现加载 WebAssembly 二进制文件的 V8 兼容 API 功能。下一步将是实现 WebAssembly 系统接口（WASI），这对于在 Web 上下文外部运行 WebAssembly 程序是必需的。WASI 是一组 API，用于抽象化对各种操作系统功能的访问，例如文件 API、网络套接字和时钟。同时 GraalWasm 将专注于提高性能，初步实验和对多个 C 微基准的性能调整表明，与以最高优化水平进行编译的本地 GCC 二进制文件相比，GraalWasm 当前可实现约 0.5 倍至 0.75 倍的峰值性能。另一方面是改善 GraalWasm 中的调试支持，并将其与 GraalVM 的其余部分集成。

近日 Mozilla、Fastly、Intel 与 Red Hat 宣布成立联合组织 Bytecode Alliance（字节码联盟），该联盟旨在通过协作实施标准和提出新标准，以完善 WebAssembly 在浏览器之外的生态。WebAssembly 也叫 Wasm，它是为基于栈的虚拟机设计的二进制指令格式，Wasm 作为可移植目标，用于编译高级语言（如 C/C /Rust），从而可以在 Web 上部署客户端和服务器应用。WebAssembly 描述了一种内存安全的沙箱执行环境，该环境甚至可以在现有 JavaScript 虚拟机内部实现。当嵌入到 Web 中时，WebAssembly 将强制执行浏览器的同源和权限安全策略。目前 1.0 版本的 Wasm 已经支持 Chrome、Firefox、Safari 与 Edge 浏览器。此次四家公司为什么结成 Bytecode Alliance 呢？Mozilla 官网博客上 Lin Clark 作了介绍。Lin 表示，当前网络用户身处越来越大的风险中，目前大家在构建大规模的模块化应用，其中 80％ 的代码库来自软件包注册中心，例如 npm、PyPI 与 crates.io。这样的方式当然使得生态繁荣，但是安全问题也在极速增加。破坏这些安全的人利用的正是用户的信任，当用户使用应用时，他们并不清楚背后这些软件依赖关系，它们之中有没有恶意代码用户根本不知道，也无法明确是否可信任。所以联盟想通过 WebAssembly 技术来推动这一个领域的安全性。Bytecode Alliance 将建立起可靠安全的基础，无论在云中、本地桌面，还是小型 IoT 设备上，都可以安全地使用不受信任的代码。开发人员可以以相同的方式使用开源代码，而不会给用户带来风险，而这些通用的可重用基础集可以单独使用，也可以嵌入其它库和应用中。 具体来说，所有这些因为依赖项而产生的安全问题都是因为不同软件/模块/文件有权限访问到其它内容，而基于 WebAssembly 可以提供某种隔离，这样就可以安全地运行不受信任的代码。可以设计一个类似于 Unix 的小型进程或容器和微服务的架构，但是这种隔离十分轻量，它们之间的通信也不会比常规函数调用慢很多。使用这样的模式，可以封装单个 WebAssembly 模块实例，或者封装一小部分想要在它们之间共享内存之类的模块实例。同时也不必放弃强大的编程语言特性，例如函数签名和静态类型检查。Lin 介绍了目前 WebAssembly 的一些技术方案，包括几个要点：每个 WebAssembly 模块默认都被沙箱化，默认情况下，模块无权访问 API 和系统调用。内存模型，与直接编译为 x86 之类的普通二进制文件不同，WebAssembly 模块在其进程中无法访问所有内存，而是只能访问已分配给它的内存块。接口类型，模块可以使用更复杂的值进行通信，比如 strings、sequences、records、variants，以及它们的嵌套组合。这使得两个模块可以轻松地交换数据，并且这种方式安全且快速。具有权限概念的 API 和系统调用，以便它们可以为不同的模块赋予对不同资源的不同权限，也就是 WASI，WebAssembly 系统接口。它提供了一种方法，可以将不同的模块彼此隔离，并赋予它们对文件系统特定部分和其它资源的细粒度权限，以及对不同系统调用的细粒度权限。这些是目前已经存在于 WebAssembly 技术中的技术，但目前还没有办法将这些安全控制向下传递给依赖树，这需要一种让父模块有赋予其依赖关系同样的安全控制的方法。这也就是 Bytecode Alliance 目前在进行的工作，计划采用各个模块虚拟化的细粒度形式，研究人员已经在研究环境中验证了这一想法，目前正在努力将其引入 WebAssembly。详细技术细节查看原博客：https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance