「2019 Google IO 大会」面向Web开发人员的WebAssembly （上）

特别说明

这是一个由 simviso 团队对2019 Google I/O 大会中关于面向Web开发人员的WebAssembly相关话题进行翻译的文档，内容并不是直译，其中有一些是译者自身的思考。Surma是Google公司WEB基础的贡献者，也是open web平台的开发倡导者。

视频地址：面向Web开发人员的WebAssembly 2019 Google I/O 上

视频翻译版权归 simviso 全部

本次参与翻译人员

前言

我是Surma，我是open web平台的开发倡导者，在伦敦与谷歌的Chrome团队合做。 今天很高兴能够跟你们谈一谈我最近发现的一个让我充满激情的东西，那就是webassembly。

你可能对它有所耳闻，若是你之后有什么问题的话，能够在 Twitter 上联系我。稍后个人同事，即来自web工程团队的 Deepti 会分享一些关于WebAssembly将来的话题。

定义

在咱们开始讲以前，我想让你们一块儿看下这张图。

由于 WebAssembly 一般与 C++ 紧密相连，以致于不少人都认为它都是关于 C++ 的，事实上，WebAssembly 远不止于此。 你能够在网上找到不少关于 C++ 和 Emscripten 的 demo。 这颇有意义，由于 Emscripten 是一个使人惊叹的工具。但对Web开发人员而言，意识到WebAssembly不只限于C++，这点很关键！

WebAssembly 自己实际上是一个很是有用的工具，你值得拥有！这就是我想在此次演讲中谈论的内容。 我想展现一些支持 WebAssembly 的其余语言，以此来让你在不学习新语言的状况下使用WebAssembly 。

而后，就像我说的，Deepti 接下来将讨论 WebAssembly 的将来。

因此要确保每一个人都知道或者但愿在场的人都知道这个网站(WebAssembly官网)，它上面解释了什么是 WebAssembly，它是一个基于堆栈的虚拟机。

若是你不知道什么是基于Web 堆栈的虚拟机，那也没有关系。 重要的是，你能意识到它是一个虚拟机， 意味着它不是一个实际存在的处理器，它的设计理念在于 咱们能够很容易的将通用代码编译到真实的运行环境下可执行的代码，这就是所谓的可移植性。所以，对虚拟机而言，设计之初须要优先考虑可移植性。

所以，当你使用任意语言编写某些代码并将其编译到 WebAssembly 时，也就是说这些代码会被编译成虚拟机可执行的指令集，而后将这些指令存储到以二进制格式存储到.wasm文件中。

由于该虚拟机能够很轻易的根据对应平台下的处理器进行代码编译，因此.wasm文件能够在运行时被读取，此时咱们这里运行的上下文极有多是浏览器。 浏览器能将.wasm文件转换成当前机器可执行的机器码，并在浏览器上执行该代码。

在一开始，webassembly就是为了面向过程安全而设计的。你能够在裸机上运行该代码，但这并不意味着它是不安全的。

实际上咱们已经在上次的Google I/O 大会上讨论过WebAssembly了。 做为一项技术，它以惊人的速度快速成长，并占据了一席之地。以前咱们也讨论了一些大公司是如何使用webassembly来运行他们以前已经存在的一些产品，这些产品极可能是用C++来编写的。

举个例子，就拿咱们使用多年的AutoCAD来说，这是一个很是知名的产品，但如今他们正努力将它编译到Webassembly上，当你想用它时，你就能够当即在浏览器上运行它，想一想都使人感到难以想象。

另外一个例子则是Unity游戏引擎以及虚幻引擎，它们如今都已经开始支持webassembly。 一般这些游戏引擎已经内建了一套抽象，由于你须要将你的游戏构建并编译到PlayStation，XBox或者其余游戏平台之上。

但如今WebAssembly已经成为它们的另外一个编译目标，那给咱们印象很深的就是经过浏览器和Webassembly就能够提供这些游戏运行所需的性能。

例子讲解

这让我以为很神奇，这些神奇的事情还在继续发生着。

二维码扫描

你经过WebKeynote就能够看到，个人同事Paul Lewis创建了一个感知工具包，它能够帮你创建一种沉浸式的体验。他们但愿经过二维码和图像检测的形式来和咱们的现实世界创建联系。

因此浏览器可以经过使用图形检测API（Shape Detection API）检测二维码，但并不是每一个浏览器都能实现了这一功能。

因此他们要作的就是该经过什么途径使用这个图形检测API。若是不可用，他们能够经过将二维码库编译到webassembly上，而后就能够按需加载。这样咱们就能够找到它。

而且图像检测根本不在Web平台上。 因此他们须要本身去构建，并使用 Webassembly 为浏览器提供新的功能。

QT Lib

UI工具包QT（QT是跨平台的软件开发工具包）宣布他们如今也支持 WebAssembly。 所以这也意味着其实你如今可使用一个旧版本的Lib QT应用程序， 并将其编译为 WebAssembly。 而后在浏览器标签体验中有一个奇怪的窗口，这看起来不太理想，这里只是为了代表它起做用了。

但QT是一个强大且通用的UI库。 因此，他们网站底部有不少Demo，实际上他们使用 Lib QT 和WebAssembly构建了一种优良且原生的UI。

Emscripten

因此若是你对 WebAssembly 不甚了解，那么你可能会问它们是怎么作到的？ 针对这些例子，给出的答案是Emscripten。

Emscripten的目标是替代C或C++编译器，取代将代码编译成你所需的本地机器码，而是将代码编译到webassembly上。 他们真的尝试着进行这方面的取代工做。不管你编写什么语言的代码，均可以跑在一个系统上，便可以很神奇地在web上面运行。这也是两种编译器之间最明显的区别。

为了实现这一目标， Emscripten 在幕后作了不少繁重的工做。

我之因此这么思考的缘由，在于它在这么多种状况下均可以很紧密和webassembly一块儿很好的工做

最初，Emscripten 是一个asm.js编译器。 这是Mozilla的一个概念，他们编写了这个编译器，用于将C语言代码并将其转换为 JavaScript。

所以能够看到，右手边的这个就是asm.js。 它只是普通的 JavaScript，也就是说，只要能够执行 JavaScript 的浏览器均可以执行asm.js。

但这个计划旨在让其它浏览器支持asm.js，从而让它们运行这类程序的时候更加快速。 因此你须要分配一块内存，同时接收一些变量。瞬间，你的C++ 代码就可以运行在你的 JavaScript 引擎上！

但 C 和 C++ 常用其余API，好比 fileopen 和 OpenGL。 所以，Emscripten 可使用 WebGL 假装成 OpenGL ，也能够经过模拟一个文件系统，使你看起来好像在处理真实的文件同样。 基本上，他们是真模仿一整套POSIX操做系统来使代码运行在 Web 上，而这些代码历来都不是为 Web 编写的。 因此他们作到了！

因此当 WebAssembly 出现时，对Emscripten来说， 只是添加了一种新的输出格式，依然保留着他们在进行模拟时能够作到的全部功能。 所以，Emscripten 能够按照以前的经验进行使用。

咱们知道，将 POSIX 代码经过WebAssembly在 Web 上运行。 这样，他们就可以以极快的速度围绕 WebAssembly 来提供很是使人印象深入而且成熟的Demo和工具。

他们值得获得你们的称赞，由于他们，全部其余语言有了这样一个平台。 我想这就是为何 WebAssembly 与 C++ 如此紧密的缘故，在于 Emscripten 的快速成熟的发展。

WEB开发人员

可是 对于Web 开发人员呢？

可能你是在 Web 机构工做或者你也多是一个自由开发者 WebAssembly 对你会有什么样的帮助？

你必需要学C++吗？ NO！

当你是一个Web开发人员，你会想，Oh，我应该须要学习 C++的，只有这样你才可使用 WebAssembly，可能不少人都会这样想。

由于当你知道JavaScript的时候，你在想C++究竟是什么？有趣的是，反过来也是同样。当我看到C++开发人员第一次看到或写JavaScript代码时，他们的表情如出一辙。

我不是说由于一种语言比另外一种语言好，仅仅是由于他们须要这样一种大相径庭的思惟方式来编写代码。 这两种语言我写的都很专业。但每当我稍微切换一下，老是须要一些时间才能想到（思惟方式的不一样）。我想说的是，对于Web开发人员来讲，至今尚未去学习 C++ 的动力。

所以，这两种编程语言都掌握很是好的人很是少。这就致使，webassembly彷佛是一个很是小众的技术。实际上，它是一个很是有用且值得你拥有的工具！

Webassembly与Javascript

这里，我想说的是，每当我想到 Webassembly 时，我一般会经过两个主要例子来讨论。 一方面，我想谈谈在 JS 应用程序中微小模块的替换、热传递和 WebAssembly 的瓶颈，同时也想谈谈 Webassembly 比 JavaScript 更快的神奇之处。

但首先，我想谈谈关于生态系统的其余方面。

这看起来有点奇怪，由于当我说 JavaScript 生态系统很是庞大时，没人会反对。 个人意思是，仅仅只是在NPM上看，它就很是巨大。 但事实上并非每一个主题的首选都是 JavaScript，也有多是其余语言。

因此有时候你可能会去面临一个问题，你须要寻找库去解决这些问题。你能够在 C 中或者 Rust 中找到这些答案，而不是在 JavaScript 中找到。

所以，你要么坐下来编写本身的 JavaScript 对应实现，要么经过WebAssembly来使用其余语言的相关实现。 这正是咱们对 Squoosh 所作的。

Squoosh 是一个彻底能够在浏览器中运行的图像压缩应用程序，能够在脱机状态下工做。你能够放入图片，而后可使用不一样的编解码器压缩它们。 以观察这些不一样的编解码器如何对你的图片的视觉质量产生不一样的影响。 若是你了解的话，能够发现浏览器如今已经提供了这一性能。

经过使用 Canvas，你能够决定你要对图片进行编码的图片格式。 你甚至能够控制图片质量！

但事实证实，浏览器经过对这些编解码器的优化而不是优化压缩质量或视觉质量来提升压缩速度。 老实说，有点不尽人意。 并且，你有点受浏览器支持的编解码器的约束。

因此直到最近，也只有 Chrome 能够编码为 WebP 格式，其余浏览器却没有。 因此这对咱们来讲还不够。

咱们利用谷歌查阅了一些相关资料，并找到了一些使用 JS 写的有关 JPEG 的编解码器 但有点奇怪，咱们并无找到一个使用JavaScript写的专门针对WebP 的编码器。 所以，咱们认为咱们得看看其余东西。。

因此咱们从其余地方查阅了一番，并在C和C++中找到了大量的相关编码器。 所以，咱们选择WebAssembly 因此呢，咱们要作的就是编译。

举个例子，将MozJPEG 这个库编译到WebAssembly上，并加载到浏览器中，而后将浏览器的JPEG 编码器替换成咱们本身加载的这个

这样咱们在相同视觉质量下获得了更小体积的图片，酷吧！ 不只如此， webassembly还容许咱们加载这个库所暴露的专业选项，而这些在浏览器中显然是不可能暴露的。

所以，配置诸如色度子采样或者不一样的量化算法等选项，不只有助于将最后几个字节从图片中舍弃，并且还能够做为一种学习工具，方便咱们去查看这些选项到底是怎么影响咱们的图片视觉和文件大小的。

这里的重点是咱们采用了一段旧代码，仿佛 MozJPEG 又回到了1991年（mozjpeg里面有个头文件是在1991开始的）

它绝对不是以 Web 为目的写的，但咱们仍是将它使用在了 Web 上，并用它来改善 Web 平台。

Emscripten操做举例

还有咱们用过的 Emscripten。 因此将它与 Emscripten 一块儿向你展现它是如何工做的。

我一般会分两步进行。

第一步是编译库，以便稍后你能够连接到它。 图片编解码器一般会用到多线程和 SIMD（单指令多数据流），由于图片压缩是一个高并发任务。 但无论是 JavaScript 仍是 WebAssembly 都还不支持多线程或 SIMD。

稍后Deepti 会带着你们来讨论这方面的内容。

可是这里咱们经过禁用SIMD 以确保在运行过程当中不会出现任何问题

在第二步中，咱们须要写一段桥接代码

这个函数我稍后将使用JavaScript来调用， 因此，它须要接收图片、图片尺寸，而后经过MozJPEG 来对它进行压缩，并返回一个包含JPEG 图片的数组类型Buffer。

当咱们写完这段桥接代码，咱们调用EMCC（Emscripten Compiler Frontend ）命令，Emscripten C编译器将编译咱们的C++文件和库文件，而后连接到一块儿供后续使用。

这个过程没有报错，而后获得输出文件：一个已经配置好了的JS文件和对应的webassembly文件。

这里要记住，Emscription做为一个替代者，已经将Emulations相关的复杂工做全都帮你作了（Emulations 是C++11的一个库） 你须要一直关注你文件大小，由于这种文件系统emulations 相关api代码须要其余的相关底层输入。 所以若是你使用了大量的C语言的API，那么生成的文件将会很大，尤为是JS文件。

咱们一直在与Emscripten团队密切合做，为了让生成的文件尽量的小。 可是若是你想让Emscripten成为一个替代品，你只能尽你所能作的更多。 因此仍是要注意生成文件的大小。

关于WebAssembly 的另一个例子就是使用Squoosh进行图片的缩放。 为了将一张图片放大或者缩小， 有不少方式能够经过许多不一样的视觉效果和视觉输出来实现这一点。 能够经过多种不一样的视觉效果和视觉输出进行实现。

所以对于浏览器，若是你只是使用浏览器缩放图片，你会获得一张缩放的图片。 它可能会很快，可能看起来也不错。 但有时候经过对这张图片缩放操做进行不一样的变量控制真的能够产生巨大的视觉冲击力

因此，在这个视频上，你能够看到我在 Lanczos3 和浏览器拥有的算法之间来回切换。 你能够看到，经过Lanczos3算法，我会有一个线性RGB色彩空间转换。

实际上，我对这张图片中的亮度有更真实的感知。 因此在这种状况下，它其实是一段很是有用的代码。 咱们在 Squoosh 中使用的这些图像缩放算法，其实是从 Rust 生态系统中提取的。

Mozilla 为 Rust 生态系统进行了大力投资， 他们的团队为 Rust 编写了 WebAssembly 工具，同时社区也将这些东西抽象为通用工具。 其中一个工具是 wasm-pack，它真的很趁手，能够帮你将你的 Rust 代码转化为 WebAssembly 模块，一个现代化形式的 JavaScript（译者注：JS能够调用.wasm文件，变相对功能拓展，因此称之现代化） ，而且它很是小。 我以为这种东西真的颇有趣。

因此对于Rust，一样的道理，咱们有一个库，用来编写咱们这么一小点桥接代码。

在这个例子中，我想经过JS调用这个resize函数。它经过接收图片、我输入的图片大小和输出的大小，而后经过这个函数我会获得调整后的图片。

而后你就能够将全部这些代码经过wasm-pack转换为一个咱们可用的webassembly模块， 如今比较文件大小有失公平，由于它是一个不一样的库，并且这个库相对较小。

因此不能直接从文件大小层面比较。可是就平均而言，讲道理说，Rust每每会产生更小的胶水代码。由于Rust没有作任何关于POSIX的文件系统模拟

你不能在rust使用关于文件的函数，由于它根本就没有作文件系统模拟。 若是你想要的话，也能够放入一些它们提供的封装模块。它更像是一种可插拔的配置。

所以，最低咱们也要用到 Squoosh，也就是咱们须要使用至少来自两种不一样语言的四个不一样的库。 这些库与web 无关，但咱们仍然继续要在web上使用它们。

这正是我想要你从这整件事中获得的东西，若是你在Web平台上发现一个（技术）空白，而且该空白其余语言已经实现了不少次，但却不是用于Web上或者不是经过JavaScript实现的。

两种语言的比较

WebAssembly 多是一个工具。

但如今让咱们来谈谈在你的 JavaScript中关于Hot Path（有大量循环迭代的代码实现）的替换，以及 WebAssembly 比JavaScript 更快的神奇之处。

如今这对我来讲很是重要，而这就是为何我想出了使用这张图来表达个人意思。

JavaScript 和 Webassembly 都有相同的峰值性能。 它们运行都很快，可是在运行比较稳定的代码（fast path）这点上，使用 Webassembly比JavaScript快得多（译者注:fast path 是已经编译后的代码，slow path是须要临时进行编译的代码）

fast path: Frontend -> simple code generator -> assembler
slow path: Frontend -> IR optimizer (sometimes more than one level of IR) -> code-generator -> assembler 
复制代码

或者反过来说，若是你运行一些不稳定的代码(slow path)，相比WebAssembly 而言，js就更加容易出现一些意想不到的意外。

目前，WebAssembly 正在寻找支持多线程和 SIMD 的解决方案，而这是JavaScript 永远作不到的

所以，一旦这些技术实现，WebAssembly 将有机会真正的超越 JavaScript 。但在目前状态下，它们的峰值性能都是相同的。

Chrome引擎

为了理解在Fast Path环节下JS的总体性能降低，让咱们来谈谈一点关于Chrome 的 JavaScript V8引擎 和 WebAssembly 引擎吧。

JavaScript 文件和WebAssembly 文件有两个不一样的引擎入口点。 JavaScript 文件传递给V8的解释器：Ignition。 因此，它能够将JavaScript 文件做为文本读取，并解析和运行它。

当这个解释器运行时，它会搜集有关代码行为的分析数据，而后经过Turbofan这个优化编译器来生成机器码。

另外一方面，webassembly文件将会传给Liftoff这个流式webassembly编译器

一旦这个编译器完成操做，turbofan 就会启动并生成优化代码。 这里有一些区别。

第一个明显的区别是他们有不一样的名称和不一样的Logo，但也有概念上的区别。 ignition是一个解释器，Liftoff是一个生成机器代码的编译器。

虽然咱们不能老是以偏概全的去说机器码永远要比解释性程序代码跑得更快。 但总的来说，确实是这么一回事。

那么，第一个区别就是速度感知方面

但更重要的是JavaScript的这一区别。 但对于JavaScript来说，更重要的区别是优化编译器只会在最后启动，在这以前JS代码必须进行运行并进行观察才能被优化。

由于某些假设是根据观察结果得出的。 生成机器码，而后再运行机器码。 可是一旦这些假设没有办法再Hold住情况，你必须回到解释器。由于咱们不能再保证机器是否能够正常工做。这被咱们称为deopt，即负优化。

有了WebAssembly，Turbofan老是在Liftoff编译器以后起做用，而且你能一直留在Turbofan 上输出。

你能一直留在fast path 上，而且你永远不会出如今deopt情况，我想这也是你们对于WebAssembly速度更快这个观点的在认知上的误区。

在Javascript上你会很容易就获得deopt状态，而在WebAssembly上就不会。

基准测试

来自Rust WebAssembly 团队的 Nick Fitzgerald 其实作了一个很是好的基准测试，他为JavaScript 和 WebAssembly 编写了一个基准测试。

图中JavaScript是红色部分，WebAssembly 是蓝色部分，运行在不一样的浏览器上。 看到这里，你会说Yes，OK，WebAssembly 更快。

可是这里主要的时间消耗能够看出JavaScript消耗跨度比较大。 它须要多长时间才是不可预料的，而不管在哪一个浏览器上WebAssembly始终如一，消耗的时间基本相同。

我想这才是关键，这也是我想带给大家的。WebAssembly 为你提供了可预测性更强的性能。 它提供了比 JavaScript 可预测性更强的性能。

这就是我想经过Squoosh这个例子来告诉你们的东西， 咱们想旋转一个图片。 因此，咱们想好了，咱们用 Canvas 实现吧。可是咱们不能使用它，由于Canvas 运行在主线程上。

在Chrome中的OffscreenCanvas不多运行在主线程上 （译者注：OffscreenCanvas提供了一个能够脱离屏幕渲染的canvas对象，是针对上面提到的主线程的补充）

因此，咱们最终手写了一段 JavaScript 来旋转它或者只需从新排列像素便可旋转图片。 它真的很管用，很是快，但事实证实，咱们在其余浏览器测试得越多，它就变得有点奇怪。

因此在这个测试案例中，咱们将一张4K分辨率的图片进行旋转。

这不是为了比较浏览器。而是关于比较 JavaScript 的。

最快的浏览器须要花费400毫秒， 最慢的浏览器须要8秒， 甚至在脱离主线程的状况下，对于用户来讲，按下按钮旋转图像消耗的时间实在太长了。

从这里你切实能够看到，很明显，咱们能够在一个浏览器中停留在fast path 上，但咱们在另外一个浏览器中却失败了。 不是这个浏览器不够快，只是一些浏览器的优化有所不一样。

因此，咱们将咱们写的旋转代码运行在WebAssembly 上或经过其余语言实现这段代码并编译到WebAssembly ，而后来进行性能比较。

你能从这幅图中看到什么？ 几乎全部支持WebAssembly 的语言都能使咱们的运行时间下降到大约500毫秒左右。

我认为这是可预测的。 个人意思是这些语言仍然存在一些差别， 但抛开JavaScript的数据，其它的就没什么差距， 这简直是指数级的下降。

一样，咱们也能够从这里看到，我有注意到在WebAssembly 最优性能体现这块， WebAssembly和JavaScript的最优性能几乎是同样的。

AssemblyScript

所以，若是你看图表，你可能想知道 AssemblyScript 是什么。 若是你还不了解它，我会很兴奋， 由于 AssemblyScript 确实将我带回了我这节课要演讲的主题，那就是Web开发人员的WebAssembly 。

AssemblyScript是一个从TypeScript到WebAssembly的编译器。

这么说可能会误导你， 由于你不能将你现有的 TypeScript放到这个编译器中，并从中获取WebAssembly 。

由于在WebAssembly 中你没有Dom API， 这样你就不能只使用相同的代码。 可是AssemblyScript 可使用TypeScript语法写的不一样类型的库

这也就意味着你根本不须要去学一门全新的语言用来写WebAssembly，这也是让我感到最为惊艳的一点 因此这看起来像什么，就是Typescript语言，只不过有一点点区别

就好像图中的 i32，它实际上并非JavaScript中的一种类型，但它倒是WebAssembly的一种所属类型。

而后，如load和store这些内置函数，能够从内存中读取和写入值。 AssemblyScript编译器会将这些转变为WebAssembly模块。

so，你如今彻底能够在不学习一门新语言的状况下，你就可以去写WebAssembly，并从中获益而且可以利用全部WebAssembly所能提供给你的好处，这是很是强大的。

有些事情须要你记住，WebAssembly并不像TypeScript那样具备垃圾回收功能，至少如今尚未。 Deepti以后会关于这个进一步讨论。 至少目前而言，你须要本身作内存管理

因此AssemblyScript提供给咱们一系列的内存管理模块。你只须要将它们从仓库里拉下来，而后用这些C语言风格的代码对它们进行内存分配管理 这是咱们目前须要去习惯的，但它确实十分有用。一旦WebAssembly支持垃圾回收，它会变得更好

AssemblyScript已经彻底开源，但它仍是一个处于起步阶段的小项目 背后有许许多多充满激情的人在为它做支持 尽管它已经有了几个赞助商，但仍是比不上像有Mozilla在背后作支持的Rust或Emscripten。

全部人都说这是确定有用，而且体验感很好。

个人同事Arron Turnner用AssemblyScript写了一套完整的模拟器

若是你由于使用它感到心累，那么你能够在GitHub上看他是如何写这个代码的。

建议

在这里，我想向各位明确的是，目前而言，将全部的东西都编译为wasm并非一个明智的决定 JavaScript和WebAssembly并非竞争对手，相反它们更应该是合做关系。在一块儿使用它们的同时，并不会将对方所取代 好比调试webassembly会变得更难。还有在对webassembly代码作code split（代码拆分）的时候，会比javascript更加困难

你必须来回调用函数，这并非一个很好的体验 已经有很多人在推特告诉我说，他们想用C++来编写他们的Web组件

我不知道为何他们想这么作，若是他们真的想这么作，我也不推荐。 我想说一些适合WebAssembly来作的一些事，好比作一些性能审查，测量你的性能瓶颈在哪里，看看WebAssembly是否能够帮助你。若是你有发现平台上的空白，你能够用其余语言来弥补它。 再次强调，WebAssembly只是你的工具。

相关连接

• Surma介绍
• Qt Examples For Webassembly
• Squoosh App(文中的主要例子)
• Assemblyscript
• Wasm Pack
• Emscripten

联系咱们

欢迎加群和咱们交流

若是感兴趣能够关注咱们的微信公众号