本文最初发布于 Uno 平台的博客。
和去年一样(去年作者写了WebAssembly 2020的发展和2021年的预测)，本文将首先回顾过去一年WebAssembly的发展，然后预测其未来一年的走势。
回顾2021
在过去的一年里，WebAssembly的发展比我之前预测的要快很多，尤其是Safari web浏览器。
Safari浏览器
2017年WebAssembly刚刚发布MVP版本的时候，Safari和其他浏览器处于同一水平。然后经过多年的发展，Safari不幸被甩在了后面。
时间到了2021年，看到Safari不断发布WebAssembly支持的更新，我很兴奋。这可能是Safari追赶其他厂商的开始。随着2021年12月14日Safari 15.2版本的发布，2021年全年的Safari更新发布了以下功能：
编译流大内存操作可寻址内存高达4GB异常处理响应头支持COOP和COEP的原子指令。对于使用COOP/COEP响应头的网站，重新开放对共享缓存的支持。
借助共享缓存，WebAssembly可以实现多线程之间的内存共享。不幸的是，由于共享缓存中目前存在Spectre和Meltdown安全漏洞，共享缓存被禁用，直到人们找到合适的漏洞解决方案。
Chrome桌面应用率先采用站点隔离作为漏洞解决方案，重新启用共享缓存。之后，在响应头中添加COOP或COEP意味着告诉浏览器创建一个隔离环境，以便安全地重新启用共享缓存。
2020年，Firefox桌面应用程序通过将这些响应头添加到响应头中，首次重新启用了共享缓存。到2021年初，Chrome桌面应用将把对共享缓存的支持更新到最新标准。之后，如果您想使用共享缓冲区函数，您必须添加这些响应头。
同时，Chrome的Android端也在2021年初宣布支持这些响应头，使得在移动端使用WebAssembly多线程成为可能。随着最新版本的Safari重新开放对共享缓存的支持，除了Firefox之外的所有现代浏览器都支持WebAssembly的多线程。
我期望Firefox mobile在2021年支持这些响应头，可惜没有实现。不过在2022年，火狐手机很有可能会支持这些响应头。
固定宽度SIMD
SIMD是指同一条指令同时作用于多个数据节点。这样，计算性能可以大大提高。例如，通过利用CPU的SIMD指令，可以大大提高图像处理能力。
SIMD有很多种。首先，WebAssembly决定首先支持128位固定宽度的SIMD操作。
Chrome和Firefox分别在2021年5月和6月增加了对固定宽度SIMD的支持，但Safari还不支持。
异常处理
直到现在，WebAssembly还没有内置的异常处理模块。为了弥补这个空缺，应用程序必须使用JavaScript来添加额外的异常处理代码。然而，当这些异常处理逻辑代码被内置到模块中时，不仅会增加模块的体积，还会影响性能。因此，除非必要，一般建议不要在模块中使用异常处理。
Chrome在9月正式发布了异常处理，但是，让我惊讶的是，Safari也在12月实现了异常处理，并决定在15.2版本中正式发布。
目前Firefox和Node.js还不支持，还在做。
根据V8(Chrome和Node.js的JavaScript引擎)的发布说明，使用WebAssembly进行异常处理的代码规模比使用JavaScript的代码规模减少了43%，比没有任何异常处理的代码规模增加了9%。同时，WebAssembly的异常处理对性能没有影响，而JavaScript的异常处理对性能有30%的负面影响。
如果您对V8中WebAssembly异常处理的细节感兴趣，可以查看V8发行说明：https://v8.dev/.
blog/v8-release-95#webassembly。模块链接和接口类型
模块链接提案是关于在两个或多个模块定义之间建立链接，且让 WebAssembly 运行时在运行期间为你处理这种链接的过程。
接口类型提案描述的是模块相互之间如何通过高级的数据类型定义实现相互之间的通信。例如，一个模块可能使用 UTF-8 字符串，而另一个模块可能使用 UTF-16 字符串，通过描述它们的数据类型，WebAssembly 运行时就会更加容易实现模块间的通信。
我原先预计这两项提案会在 2021 年完成，目前看来，虽然取得了一些阶段性的成果，但未来仍然需要继续发力。
.NET 6
过于的一年里，为了进一步提高对 WebAssembly 的支持，不管是在工具方面还是性能方面，.NET 都做了很多努力。在 11 月份 6 版本中发布的 AOT 编译功能就是其中之一。
通常.NET 代码的编译分两步，首先将本地代码编译为 IL（.NET 架构中的中间语言），然后在部署的目标机器上，通过目标机器的即时编译完成剩下的编译。这个过程其实和 WebAssembly 的工作机制有点类似。
当这种编译机制的代码运行在客户端浏览器的时候，WebAssembly 代码就是.NET WebAssembly 运行时本身，而应用的代码则全是 IL 文件。这种按需编译执行 IL 文件的方式在性能上无法和直接执行已编译文件的方式相提并论。
在 AOT 编译方式中，应用的.NET 代码将全部被编译为 WebAssembly。这种方式虽然增加了文件的大小，但却获得了更好的性能，不过，大文件会导致应用的首次加载时间过长。
考虑到 IL 和 AOT 两种不同编译方式的优劣，使用配置导向的 AOT 编译或许是最佳选择。通过这种方式，我们可以将频繁使用的代码通过 AOT 进行编译，而剩下的部分则采用 IL 的编译方式。
除此之外，我们的 Uno 平台还引入了一个名为 XAML 资源修剪的功能。它可以与 AOT 编译一起删除那些未使用的代码。人们在测试中发现，通过这种方式可以使 WebAssembly 应用程序的代码减少 50%。
字节代码联盟
字节码联盟最初是由英特尔、Mozilla、红帽和 Fastly 组成的一个组织，其目标是通过利用 WebAssembly 和 WASI 等标准，构建一个可以在任何平台、设备或操作系统上运行不可信代码的安全平台。
WASI（WebAssembly 系统接口）是如何在浏览器之外的场景安全且一致的使用 WebAssembly 的标准。如果你想了解更多相关信息，Lin Clark 写了一篇很好的文章来解释 WASI: WASI-WebAssembly 系统接口标准：https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/。
联盟从一开始就希望更多的组织加入，为此组织内部的架构必须做相对应的调整，才可以满足组织未来的发展和壮大。在创建基金会的时候，红帽公司退出，微软加入且帮助其他创始人将该组织合并为一个非营利性组织。2021 年，联盟得以扩大，现在组织成员包括了微软、谷歌、Arm、DFINITY 基金会、普莱普工作室、Shopify 和加州大学圣地亚哥分校。
除了支持 WASI，该联盟也是 Wasmtime、cranlift、Lucet、WAMR 和 Enarx 等项目的来源。如果你对字节码联盟感兴趣，可以通过链接获取更多信息：https://bytecodealliance.org/。
WebAssembly 应用领域
每年我们都看到越来越多的商业产品增加了对 WebAssembly 的支持。例如，在 2020 年，Zoom、谷歌 Meet、谷歌 Earth 和 Firefox 浏览器都加入了诸如 Cloudflare Workers 等基于 WebAssembly 的无服务计算产品竞的争行列。除此之外，还有 eBay 的条形码扫描仪、AutoCAD 的 web 应用程序以及 Unity 游戏引擎。
2021 年也不例外，下面是一些运用 WebAssembly 的新领域：
Disney+ 应用程序开发工具包使用 WebAssembly网页上发布了一个简化版的 Photoshop微软的飞行模拟器有一个基于 webassembly 的插件系统
随着功能和工具的改进，以及越来越多的商业产品使用 WebAssembly，我们开始看到 WebAssembly 在框架和常规 Web 上的应用。虽然应用的领域和产品还是很少，但是他的持续增长是令人兴奋的。
2021 年对 WebAssembly 来说是伟大的一年，那么我们对 2022 年有什么期待呢?
预测 2022
我认为 2022 年一定会发生的事情是，WebAssembly 在几乎所有领域的功能会得到进一步的增强和改善。这其中我最期待的是异常处理。
异常处理
异常处理是许多编程语言必要的一个主要特性，因此它位于待办事项列表的前列。Safari、Chrome 和 Edge 已经具备了此功能，并且 Firefox 和 Node.js 也在积极开发中。
由于低性能的 JavaScript 版本依然还能继续使用，因此当你的模块中需要用到异常处理的时候，如果可以使用性能更好的 WebAssembly 异常处理那么就升级使用，否则就回退到使用 JavaScript 异常处理的版本。
共享缓存区
正如前面提到的，包括 Firefox 桌面在内，几乎所有现代的桌面端和移动浏览器现在都支持了 COOP/COEP 响应头。这些响应头允许浏览器安全地启用共享缓存区，从而允许你的模块使用 WebAssembly 多线程。
在现代浏览器中，现在只剩下 Firefox 移动端不支持这些响应头，不过 Firefox 移动端已经规划在 2022 年 2 月发布的 97 版本中支持这些响应头。
固定宽度 SIMD
我预测此功能将在今年的 Safari 版本中实现。
我的理由是，Safari 在 2021 年增加了对 WebAssembly 的支持，WebAssembly 固定宽度 SIMD 规范现在已经标准化，而且 Xcode(苹果的操作系统开发环境) 也已经支持了 SIMD。
尾部调用
为了支持 WebAssembly，一些编程语言不得不运用尾部调用，虽然很多事情都可以有变通的路径，但其过程缓慢。除此之外，尾部调用在编译优化和流程控制上也是有积极的作用。该提案已经完成一段时间了，但至如果想要进入到第四阶段，就必须至少有 2 个厂商（Chrome、Firefox 或 Safari）实现此功能。Chrome 已经在一个版本标签中实现了此功能，但在它达到第四阶段之前 Chrome 并不打算正式发布它。所以我们仍然必须等待至少再多一个厂商实现此功能。
并非各厂商不想实现此功能，而是他们都为各自认为更重要的事情而忙碌。因此人们正试图提高此功能在各个厂商眼中的重要性和优先级。
支持多内存
此提案是使模块拥有多个内存模块。
多内存的一个使用场景是，模块将一个内存区域作为自己的内部数据区域使用，将另外一个内存区域传递给某些需要写入数据的模块使用。通过此方式，你可以防止模块内部数据因为外部模块的异常写入而发生错误。同时这种方式还可以很好的隔离敏感数据和共享数据，起到一定的安全作用。
另一个多内存的使用场景是，在 WebAssembly 的多线程中，你可以让这些线程有一个共享的内存区域，同时将其他的模块数据保存到另外一个内存区域中。
如果你对多内存区域的使用场景感兴趣，可以查看多内存介绍（https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md）来了解更多使用场景。
目前此提案已经到了第三阶段，同时还有很多引人注目的应用场景。所以我特别希望它在今年能正式发布。
WASI（WebAssembly 系统接口）
在本文的前面提到，我预期模块链接和接口类型两个提案会在 2021 年完成。不过可惜，它们目前依然还在推进中，并没有像我的预期那样在 2021 年完成。
这些建议不仅仅是 WebAssembly 的一部分，它们还是创建组件模型必不可少的功能。根据此 WASI 的帮助文档描述，组件模型和操作系统的进程模型类似，都是用来定义进程是如何启动以及相互之间通信的。WASI 的在这里扮演的角色就类似操作系统的 API 层。
所以，2022 年组件模型和 WASI 的接口类型提案都将持续发展。如果你对 WASI 的提案感兴趣，可以通过 WASI 提案列表（https://github.com/WebAssembly/WASI/blob/main/docs/Proposals.md）查看更多。
总结
过去的一年里，在提高 WebAssembly 性能方面，我们看到了 WebAssembly 多线程的共享缓冲区、固定宽度 SIMD 和异常处理等特性。同时，.NET6 中提高了对 WebAssembly 的支持，并且.NET 和 Uno 平台都通过增加 AOT，进一步提高 WebAssembly 的性能。
Safari 在 2021 年是一个大惊喜，他们在追赶其他浏览器的 WebAssembly 支持上做了很多工作。
在 2021 年，我们看到更多的商业产品加入了使用 WebAssembly 的行列，同时，WebAssembly 也开始在大众网络上得到应用。
如此看来，2022 年必将会是 WebAssembly 发展的又一个好年份，因为那些现在还不支持的功能特性，很有可能在 2022 最终正式发布且投入生产。
针对 WebAssembly 本身有非常多有趣的功能提案，同时字节码联盟也将继续助力 WebAssembly 在浏览器以为场景的落地和功能升级。
如果你对 WebAssembly 功能支持的发展路径有兴趣的话，可以通过下面的网站进行了解。第一列显示的是特性列表：WebAssembly 功能特性 RoadMap（https://webassembly.org/roadmap/）。
感谢特邀嘉宾 Gerard Gallant，他是“WebAssembly in Action”一书的作者，也是一名高级软件开发人员，他写了另一篇关于 WebAssembly 当前和未来状态的综合文章。
