vlambda博客
学习文章列表

Wasm一直在火的路上，从未停歇，W3C 成立了专门的 WWG 工作组来负责 Wasm 技术的标准迭代与实现，四大主流浏览器（Google Chrome、FireFox、Edge和Safari）已经全部实现 WebAssembly 技术在其 MVP 标准中制定的所有特性，C/C++、Go 和 Rust 等高级语言已经逐渐开始支持编译到 Wasm 格式。这一系列的发展和变化都说明了人们对该项技术所寄予的厚望，而今天有幸邀请到了国内第一本wasm书籍《深入浅出WebAssembly》的作者于航老师做客TLC2020采访室。

Q.WebAssembly 近几年非常火爆，对于前端同学有什么重大意义？

Wasm 起源于 Web，最初是 Google 为了能够取代 PNaCL 和 AMS.js，提出并创造的一种更加高效、更易于移植，且更加安全的字节码格式。因此，鉴于它拥有的这些特性，我们可以方便地在浏览器中借助它来创建性能更加卓越的 Web 应用。但目前，受限于 MVP 标准，作为前端同学，我们暂时可能还无法通过 Wasm 来构建可以直接与浏览器 DOM 进行交互的传统 Web 前端应用。但是 Post-MVP 标准中的一些提案已经处在了标准化的过程中，而一旦有了这些提案的帮助，Wasm 与 Web 前端将会走的更近。

相信接触过 Wasm 的前端同学应该都或多或少有这样的疑问：“我们是否可以用 Wasm 来改进诸如 React 和 Vue 等前端框架的性能呢？”就目前而言，我们可以使用 Wasm 来改写框架中的诸如“计算 V-DOM 差异”等涉及到密集计算过程的逻辑，但其实际带来的性能提升却可能并不会令人十分满意。因此就目前而言，改写的成本、ROI、稳定性以及兼容性也都是需要考虑的因素。但我相信，在不久的将来，待 Wasm Post-MVP 中的诸如 Reference Type 和 GC 等提案能够在浏览器中最终实现落地，那时的 Wasm 将会带给前端领域新的生机。毕竟，在 2019 年年底的 12 月份，W3C 已经正式宣布，Wasm 将成为除 HTML、CSS 以及 JavaScript 外的第四种 W3C 官方推荐使用在 Web 上的“语言”。

Q.很多同学都有通过您的新书《深入浅出 WebAssembly》来学习相关内容，但是它的更新迭代如此之快，如何快速跟上变化呢？何时才能达到相对稳定？

确实，一项新的技术在其初期发展时的变化速度甚至可以按“周”为单位来进行计算。但对于 Wasm 来说，我们其实要区分出它的“变”与“不变”的地方。首先，经常发生改变的主要还是 Post-MVP 中提案的设计和实现细节；偶尔会发生变化的是 Wasm 相关配套基础设施的一些对外接口和使用方式。其中，使用人数最多并且接口还不算那么太稳定的要属 Emscripten 了。Emscripten 的对外接口不稳定其实也是有一些历史原因的，因为早期的 Emscripten 主要还是用于生成 ASM.js 代码。虽然从某种程度上来说，Wasm 与 ASM.js 有很多相似的地方，比如运行时模型，但 Emscripten 在两者的实现细节方面却有很多不同。比如早期生成 Wasm 的方式是通过名为 Fastcomp 的编译器后端，而后期由于 Wasm 发展过于迅速，Emscripten 便改用了 LLVM 后端。再比如笔者两年前曾遇到过的，Emscripten Binding 对 C++ scoped-enum 的支持也并不算友好。等等这些其实都跟 Wasm 的迅速发展以及 Emscripten 本身的实现复杂性有着紧密的联系。

除了上面提的这些易变部分，那不变的部分是什么呢？首先就是 Wasm 已经发布的 MVP 标准。在这个标准中规定了 Wasm 的字节码格式、编码方式，甚至运行时模型等细节。而这部分内容我们可以基本认为其不会再被改变。因此，所谓“跟上变化速度”，我认为最好的方式是直接关注在官网列出的“提案进展列表”。在这个列表中，官方会及时维护所有与 Wasm 相关提案的当前所在阶段，以及它们在各浏览器中的落地实现情况。而作为开发者，便可以在第一时间去相应的浏览器体验这些新的功能。

总体来看，Wasm Post-MVP 标准中还有几个比较重要的提案暂时没有较大的进展，其中一个便是 GC。而这些提案将直接影响 Wasm 整个体系所具有的能力。在可预见的未来，Wasm 标准的真正稳定可能还需要 2-3 年的时间。但值得庆幸的是，这整个过程不是一蹴而就的，为了能够让 Wasm 以“渐进式”的方式得到发展，GC 这个大提案的实现实则是被拆分成了多个小提案，而每一个小提案的落地都将让 Wasm 标准变得更加完善和稳固。

Q.您编写 Wasm 虚拟机的初衷是什么？TWVM 相对于其他 Wasm 虚拟机有哪些优势？

当初在打算自己编写 VM 时的计划是想要构建一个“轻量级的、具有高可移植性且同时兼具足够高性能的 Wasm 虚拟机”。因为彼时大部分知名的 VM 都基本借助 LLVM 来构建 JIT 引擎，从某种程度上看，这会导致牺牲一定的可移植性，并且最终编译生成的目标二进制代码体积也会相应增大很多。而这也会导致某种程度上，不太易于将 Wasm 推广到更多特殊的应用场景中，比如嵌入式。

从另一方面讲，就目前 VM 这个领域的发展而言，其实已经很难单凭技术革新就将整个 VM 的性能提升到另一个更高的层次。大部分的 VM 也只能够以 fine-tuning 的方式来对性能进行调优，因此除了性能以外的其他“配套设施”就显得更加重要。比如，VM 集成的复杂度、文档的完善程度、社区的活跃度等等。而 TWVM 的设计目的其实也并不在于性能上的比拼，甚至可以说会通过牺牲一定性能来满足其他方面的要求，比如可移植性和目标代码体积。

除此以外，开发 TWVM 的另一个目的也是希望能够在未来方便地将 Wasm 应用到更多本地化的场景中。我们都知道，国内的市场其实与国外大不相同。从用户量到使用习惯都有着很大的差异。伴随而来的便是很多“独特”的技术解决方案，比如我们天天都在使用的“小程序”。因此，自己开发 VM 的一个好处在于，这使得在将 Wasm 与这些技术领域进行结合时可以更好地把控实现细节，甚至在某种程度上 VM 可以为这些场景进行特殊的适配和优化。

Q.如何看待未来 WebAssembly 与 Javascript 的关系?

其实关于这个话题，一个问的最多的问题就是“Wasm 最终会不会取代 JavaScript？”。这里我们还要再明确一下这个问题：“Wasm 会不会超过 JavaScript 成为浏览器上使用最多的一种低级代码格式？”。答案其实也比较简单：“至少目前在可预见的时间范围内，这个是不需要担心的问题”。首先，从技术角度来看，Wasm 与 JavaScript 两者其实是没有任何关系的。一个是静态类型高级语言的编译目标，另一个是动态类型的高级编程语言。其次，从 JavaScript 发展 20 余年的“垄断地位”来看，短时间内它也不是可以被完全取代的存在。再考虑到社区的体量、使用成本等因素，短时间内，Wasm 与 JavaScript 还只能够是互相补充的存在。

但是，毕竟 Wasm 在初期的设计定位时，并没有被考虑要求作为 JavaScript 的辅助角色。因此 Wasm 最终能够成为什么？这是另一个可以让人脑洞大开的话题。

活动推荐

在即将到来的 腾讯2020TLC 上，于航将在大会分享《WebAssembly and TWVM》。目前还有少量早鸟票，欲购从速。2020年9月5日，科兴科学园国际会展中心，不见不散！