webassembly_WebAssembly在这里！

webassembly

It’s been a while since we announced our intention to switch to WebAssembly (a.k.a. Wasm) as the output format for the Unity WebGL build target. Since Unity 2018.2 is the release that finally delivers this change, we would like to explain how we got to this point and what this means for all of you who make interactive web content with Unity.

自从我们宣布打算切换到WebAssembly (又名Wasm)作为Unity WebGL构建目标的输出格式已经有一段时间了 。 由于Unity 2018.2是最终实现此更改的版本，因此我们想解释一下这一点以及这对使用Unity制作交互式Web内容的所有人的意义。

通往瓦斯之路 (The Road to Wasm)

We released WebAssembly support in Unity 5.6 as an experimental feature, more or less when it also became available in the four major desktop browsers. Since then, several improvements and bug fixes have been implemented in Unity as well as in the browsers. In the meantime, user adoption increased, and the feedback we received was positive. So the next step was obviously to support it officially: Unity 2018.1 marked the removal of the experimental label and, at the same time, we made it possible to make Wasm-only builds.

我们在Unity 5.6中发布了WebAssembly支持，并将其作为一项实验性功能，在四种主要的桌面浏览器中也都或多或少地提供了支持。 从那时起，已在Unity以及浏览器中实现了多项改进和错误修复。 同时，用户采用率有所提高，我们收到的反馈是积极的。 因此，下一步显然是要正式支持它： Unity 2018.1标志着实验标签的删除，与此同时，我们使仅Wasm的构建成为可能。

Then in 2018.2, Wasm finally replaced asm.js as the default linker target.

然后在2018.2中 ，Wasm最终将asm.js替换为默认链接器目标 。

This means Unity 2018 LTS will default to Wasm when you’re publishing for the Unity WebGL build target.

这意味着在发布Unity WebGL构建目标时，Unity 2018 LTS将默认为Wasm。

This is an important milestone for us since we’ve been working towards this goal for a while. We had a few requirements: we needed to make sure Unity’s implementation and browser support were stable, and we needed internal test coverage for Wasm, which involved upgrading Emscripten and fixing several issues in our code.

对于我们来说，这是一个重要的里程碑，因为我们已经为实现这一目标而努力了一段时间。 我们有一些要求：我们需要确保Unity的实现和浏览器支持稳定，并且需要Wasm的内部测试范围，其中涉及升级Emscripten并修复代码中的几个问题。

Today we have Wasm variations of all our test suites, so any changes that will be merged into our mainline have been tested against WebAssembly:

今天，我们所有的测试套件都有Wasm变体，因此将要合并到我们的主线中的所有更改都已针对WebAssembly进行了测试：

Note that we still maintain and run asm.js test suite, but now every change that goes into the mainline is tested against Wasm.

请注意，我们仍然维护和运行asm.js测试套件，但是现在对主线进行的每个更改都针对Wasm进行了测试。

WebAssembly与asm.js (WebAssembly vs asm.js)

Let’s take this opportunity to talk about WebAssembly more in detail and go over the major differences compared to asm.js.

让我们借此机会更详细地讨论WebAssembly，并讨论与asm.js相比的主要区别。

Wasm is faster, smaller and more memory-efficient than asm.js, which are all pain points of the Unity WebGL export. Wasm may not solve all the existing problems, but it certainly improves the platform in all areas. Nevertheless, please be mindful that performance may vary depending on the browser implementation. The good news is that all vendors are committed to supporting and improving it.

与asm.js相比，Wasm更快，更小且内存效率更高，这都是Unity WebGL导出的难点。 Wasm可能无法解决所有现有问题，但可以肯定地改善了所有领域的平台。 不过，请注意，性能可能会因浏览器的实现而有所不同。 好消息是， 所有供应商都致力于支持和改进它 。

When you open a Wasm file, you will immediately notice that it’s a binary file, as opposed to asm.js, which is text. This is a more compact way to deliver your code, but it also makes it impossible to read or change for debugging purposes.

当打开Wasm文件时，您会立即注意到它是一个二进制文件，而asm.js则是文本。 这是交付代码的更紧凑的方法，但是它也使得无法出于调试目的而进行读取或更改。

Wasm has its own instruction-set, whereas asm.js is a “highly optimizable” subset of Javascript. In Development builds, WebAssembly adds more precise error-detection in arithmetic operations, which can throw exceptions on things like division by zero, rounding a large float to an int, and so on. In non-development builds, this kind of detection of arithmetic errors is masked, so the user experience is not affected.

Wasm有其自己的指令集，而asm.js是Javascript的“高度可优化”子集。 在开发版本中，WebAssembly在算术运算中添加了更精确的错误检测，这可能引发诸如零除，将大浮点舍入为int之类的异常。 在非开发版本中，这种算术错误的检测被屏蔽，因此用户体验不会受到影响。

代码大小 (Code Size)

To generate WebAssembly, we have a complex toolchain (based on IL2CPP, emscripten and binaryen) that will transform C/C++ and C# code to WebAssembly. This produces a binary file (<build name>.wasm.code.unityweb), which results in smaller builds than asm.js.

为了产生WebAssembly，我们有一个复杂的工具链(基于IL2CPP ， emscripten和binaryen )，将改变C / C ++和C＃代码WebAssembly。 这将生成一个二进制文件(<内部版本名称> .wasm.code.unityweb)，从而生成的版本比asm.js小。

Whereas, the code size for development builds is tens of MBs smaller, for non-development builds, it’s smaller by several hundred KBs. Just to give you an idea of the baseline, the code size for an empty project is ~12% smaller or ~18% if 3D physics is included.

相比之下，用于开发构建的代码大小要小几十MB，而对于非开发构建的代码大小要小几百KB。 只是为了让您对基准有所了解，一个空项目的代码大小要小12％，如果包括3D物理，则大约18％。

Note that this has been measured excluding all unnecessary packages, excluding all built in shaders and using Brotli as the compression format.

请注意，此度量标准已排除所有不必要的软件包 ，不包括所有内置的着色器并使用Brotli作为压缩格式。

As with any  improvement (performance, memory, load-times), your mileage may vary depending on your project.

与任何改进(性能，内存，加载时间)一样，您的里程可能会因项目而异。

记忆 (Memory)

One of the limitations we had with asm.js was the restriction on the size of the Unity Heap: Its size had to be specified at build-time and could never change. WebAssembly enables the Unity Heap size to grow at runtime, which lets Unity content memory-usage exceed the initial heap size specified at startup.

我们使用asm.js的限制之一是对Unity Heap大小的限制：它的大小必须在构建时指定，并且永远不能更改。 WebAssembly使Unity Heap大小在运行时增加，这使Unity内容的内存使用量超过了启动时指定的初始堆大小。

This means you can make your content start with a small heap (let’s say 32mb) and let it grow as needed, which was not possible before.

这意味着您可以使内容从一个小堆开始(例如32mb)，并根据需要进行扩展，这是以前不可能的。

Think of the Memory Size value as the initial size that your content starts with. This is a feature built in 2018.2, so you can take advantage of it today. However, this approach is not possible if you are targeting asm.js as well, since the Heap can’t resize.

将“ 内存大小”值视为内容开始的初始大小。 这是2018.2中内置的功能，因此您可以立即使用它。 但是，如果您也以asm.js为目标，则无法使用此方法，因为Heap无法调整大小。

Just keep in mind that the browser might still run out of memory if the Heap grows too much. How much is “too much” depends on the browser. To get consistent behavior across browsers, set up the maximum size to the Unity Heap. You can do this by setting the emscripten argument  “-s WASM_MEM_MAX=<value>” in editor script, for example:

请记住，如果Heap增长太多，浏览器可能仍会耗尽内存。 “多少”多少取决于浏览器。 为了在浏览器中获得一致的行为，请为Unity Heap设置最大大小。 您可以通过在编辑器脚本中设置emscripten参数“ -s WASM_MEM_MAX = <值>”来执行此操作，例如：

PlayerSettings.WebGL.emscriptenArgs = "-s WASM_MEM_MAX=512MB"; PlayerSettings.WebGL.emscriptenArgs = "-s WASM_MEM_MAX=512MB";

1	PlayerSettings.WebGL.emscriptenArgs = "-s WASM_MEM_MAX=512MB";

1	PlayerSettings . WebGL . emscriptenArgs = "-s WASM_MEM_MAX=512MB" ;

Note that the Maximum Memory Size is 2032 and that any value larger than that will result in a run-time error in the browser.

请注意，最大内存大小为2032，任何大于该值的值都会在浏览器中导致运行时错误。

Lastly, Wasm will be more memory-efficient at load time. Therefore reducing out of memory problems that many users experienced with asm.js, especially on 32-bit browsers.

最后，Wasm在加载时将提高内存效率。 因此，减少了许多用户使用asm.js遇到的内存不足问题，尤其是在32位浏览器上。

For more information on how memory works in Unity WebGL, read this blog post.

有关内存如何在Unity WebGL中工作的更多信息，请阅读此博客文章 。

性能 (Performance)

The performance difference between Wasm and asm.js depends on the browser. As a binary format, Wasm has the potential to load up much faster than asm.js, which is parsed as a JavaScript text file.

Wasm和asm.js之间的性能差异取决于浏览器。 作为二进制格式，Wasm的加载速度可能比asm.js(解析为JavaScript文本文件)快得多。

In addition,  wasm-code modules that have already been compiled can be stored into an IndexedDB cache, resulting in a really fast startup when reloading the same content. To take advantage of Wasm caching, just make sure the Data Caching option is enabled.

此外，可以将已经编译的wasm代码模块存储到IndexedDB缓存中，从而在重新加载相同内容时实现真正快速的启动。 要利用Wasm缓存，只需确保启用了Data Caching选项。

After startup, execution speed will be comparable to asm.js on browsers that are already optimized for the asm.js style of code in their JavaScript engines. If you are running Wasm on a browser that previously did not recognize asm.js, Wasm should noticeably speed things up.

启动后，在已经针对其JavaScript引擎中的asm.js样式的代码进行了优化的浏览器上，执行速度将与asm.js相当。 如果您在以前无法识别asm.js的浏览器上运行Wasm，则Wasm应该会明显加快速度。

Depending on the code, some instructions might be faster in Wasm, such as 64-bit integer arithmetics, which asm.js does not have specific instructions for.

根据代码的不同，Wasm中的某些指令可能会更快，例如64位整数算术，而asm.js没有特定的指令。

多线程 (Multi-Threading)

WebAssembly multi-threading support is probably the most awaited feature, and the one which will improve performance the most. It was supposed to ship in browsers earlier this year but SharedArrayBuffer support, one of the building blocks to make this possible, had to be disabled because of security concerns due to Spectre and Meltdown. Thankfully, in the last few months, browsers have been putting in place a number of security measures in order to be able to re-enable SAB, and we are seeing signs that they are ready to ship in upcoming versions.

WebAssembly多线程支持可能是最期待的功能，并且它将最大程度地提高性能。 它应该在今年早些时候在浏览器中发布，但是由于Spectre和Meltdown的安全问题，必须禁用SharedArrayBuffer支持(使之成为可能的构建块之一)。 值得庆幸的是，在过去的几个月中，浏览器已经采取了许多安全措施，以便能够重新启用SAB ，并且我们看到有迹象表明它们已准备好在即将发布的版本中发布。

On the Unity side, we want to be ready for when that happens so we are actively working on Wasm multi-threading support, which will initially be released as an experimental feature in the next few months and will only be limited to internal native threads (no C# threads yet). By internal, we mean job threads for skinning, animation, culling, AI pathfinding and other subsystems. They might not be all enabled at the beginning, but our long-term goal is to take advantage of multi-threading as much as possible.

在Unity方面，我们希望为发生这种情况做好准备，因此我们正在积极致力于Wasm多线程支持，该支持最初将在接下来的几个月中作为实验性功能发布，并且仅限于内部本机线程(还没有C＃线程)。 内部 ，是指用于蒙皮，动画，剔除，AI寻路和其他子系统的作业线程。 在一开始可能并没有全部启用它们，但是我们的长期目标是尽可能多地利用多线程。

调试 (Debugging)

Debugging has always been a challenge with asm.js. Unfortunately, it hasn’t gotten better with WebAssembly yet. While browsers have begun to provide WebAssembly debugging in their devtools suites, these debuggers do not yet scale well to Unity3D sizes of content. The good news is that Wasm has been designed to be “open and debuggable” so you can expect in the future that browsers will provide better tools for this purpose. In the meantime, you can use other debugging techniques:

调试一直是asm.js的挑战。 不幸的是，WebAssembly还没有变得更好。 虽然浏览器已开始在其devtools套件中提供WebAssembly调试，但这些调试器仍无法很好地扩展到Unity3D大小的内容。 好消息是，Wasm被设计为“开放且可调试”的，因此您可以期望将来浏览器将为此目的提供更好的工具。 同时，您可以使用其他调试技术：

It’s also worth mentioning that 2018.2 just added Managed code debugging support for IL2CPP. which we will start experimenting with as soon as we have WebAssembly multi-threading support implemented.

还值得一提的是，2018.2刚刚添加了对IL2CPP的托管代码调试支持。 一旦实现了WebAssembly多线程支持，我们将开始进行试验。

未来 (Future)

Browser vendors are committed to continue improving WebAssembly support. In fact, since they shipped the MVP (Minimum Viable Product), they kept working on new features as well as optimizations that improve startup times and performance, such as:

浏览器供应商致力于继续改善WebAssembly支持。 实际上，自从他们发布了MVP(最低可行产品)以来，他们就一直致力于开发新功能以及优化以缩短启动时间和性能的优化，例如：

Note that some of the features above are already implemented, depending on the browser. For more information about future feature specifications and their status, check this page.

请注意，取决于浏览器，上面的某些功能已经实现。 有关未来功能规格及其状态的更多信息， 请查看此页面 。

In conclusion, we strongly believe in WebAssembly and we encourage developers to use it by default too. If needed, it’s possible to keep asm.js as a runtime fallback for old browsers. This can be achieved by selecting WebGLLinkerTarget.Both in the WebGL Player Settings.

总之，我们强烈相信WebAssembly，并且我们鼓励开发人员默认使用它。 如果需要，可以将asm.js保留为旧浏览器的运行时备用。 这可以通过在WebGL Player设置中选择WebGLLinkerTarget.Both来实现。

Just be aware that we plan on deprecating asm.js in 2018.3. This means that going forward, asm.js will not get any of the Wasm-specific improvements, such as multi-threading, SIMD and so on. Having said that, it will still be available in 2018 LTS, which we’re going to officially support for two years, following its release date at the end of the year.

请注意，我们计划在2018.3中弃用asm.js。 这意味着向前看，asm.js将不会获得Wasm特定的任何改进，例如多线程，SIMD等。 话虽如此，它仍将在2018 LTS中可用，我们将在今年年底正式发布之后正式支持两年。

Check here if you want to know if a specific browser supports WebAssembly.

如果您想知道特定的浏览器是否支持WebAssembly，请在此处检查。

In the next blog post, we look at some benchmarks to see how the browsers compare to each other.

在下一篇博客文章中 ，我们将查看一些基准测试，以了解浏览器之间的比较。

We’re looking forward to hearing your feedback on the Unity WebGL Forum.

我们期待听到您对Unity WebGL论坛的反馈。

翻译自: https://blogs.unity3d.com/2018/08/15/webassembly-is-here/

webassembly