WebAssembly如何演进为“浏览器第二编程语言”？
极客时间编辑部
讲述：丁婵大小：9.93M时长：07:14
你好，欢迎收听极客视点。
WebAssembly 无疑是近年来让人最为兴奋的新技术之一，它虽始于浏览器但已经开始不断地被各个语言及平台所集成。在实际的工业化落地中，区块链、边缘计算、游戏及图像视频等多个领域都依靠 WebAssembly 创造了让人称赞的产品。
最近，Coupang 资深全栈工程师赵洋在公众号“前端之巅”详细地介绍了 WebAssembly 的演变历程，本文摘录了其中的重点内容分享给你，帮助你深入理解 WebAssembly 这门技术的使用场景，从而更好地学习和使用 WebAssembly 技术。
JavaScript 的弊端
JavaScript 毫无疑问是技术领域的佼佼者，但随着各类应用功能的复杂化，受限于 JavaScript 语言本身动态类型和解释执行的设计，其性能问题也逐渐凸显。
在 2008 年底，Google、Apple、Mozilla 为 JavaScript 引入了 JIT（Just-In-Time）引擎，试图解决 JavaScript 的性能问题，并取得了非常好的效果。
但是，JIT 引擎的优化并非是完全无代价的，同时由于 JavaScript 自身的灵活性，如果编写 JavaScript 代码时并没有将数据类型严格固定，那么 JIT 的效果将会大打折扣。在 Google V8 团队的 《JIT-less V8》 文章中，使用 JIT-less 模式的 V8 在运行 Youtube 的 Living Room 页面时，其测试成绩与使用 JIT 的 V8 实际差距仅为 6%。这个测试侧面反映了 JIT 在生产中并不是完全的“性能银弹”。
那么 JavaScript 能变得更快吗？还是说需要其他技术来解决 JavaScript 的性能问题？此时 NaCl 和 PNaCl 应运而生。
NaCl 与 PNaCl
NaCl（Native Client）由 C/C++ 语言编写并定义了一套 Native Code 的安全子集（SFI 技术)，同时执行于自己独立的沙盒环境之中，以防止安全性未知的 C/C++ 代码对操作系统本身产生危害，2009 年正式达到生产可用状态。
NaCl 应用及其模块在性能上与原生应用的差距非常小，但由于 NaCl 与 CPU 架构强关联且不具有可移植性，需要针对不同的平台进行开发和编译，导致开发者无法自由分发 NaCl 应用及模块。为了解决这个问题，NaCl 改进技术 PNaCl 出现了。
PNaCl（Portable Native Client）通过替换 Native Code 为 LLVM IR 子集并在客户端编译为 NaCl 的方式解决了 NaCl 的分发问题。PNaCl 不依赖于特定的 CPU 架构，更易于被部署和使用，但同样的，PNaCl 也是运行在自己的独立沙盒之中，其无法直接访问 Web APIs，而是需要通过一个名为“PPAPI”的接口来与 JavaScript 通信。
PNaCl 技术在当时看起来是一个非常理想的方案，其兼具高性能和易于分发的特点，但实际上并没有受到非常强的支持。PPAPI 出现的时代正好是处于人们尽可能试图摆脱 Flash、Java Applet 等插件的时代，尽管当时 Chrome 已经直接集成了 NaCl 与 PNaCl，但其运行在独立沙盒环境与使用独立 API 的方式，跟 Flash、Java Applet 等插件非常类似。同时，其开发难度、成本以及糟糕的兼容性问题都成为了 NaCl/PNaCl 普及的最大障碍。
让人惊艳的 asm.js
2010 年，阿隆·扎凯（Alon Zakai）加入 Mozilla 负责 Android 版 Firefox 的开发，在工作之余，他创造了 Emscripten。到 2011 年，Emscripten 已经具备编译中大型项目的能力。Mozilla 看到了 Emscripten 项目的巨大潜力，让阿隆·扎凯全职负责 Emscripten 项目的开发。
为了使得 JavaScript 运行得更快，在 2013 年，阿隆·扎凯联合卢克·瓦格纳（Luke Wagner）、大卫·赫曼（David Herman）发布了 asm.js。
通过添加类似的类型注解，Emscripten 编译的 asm.js 在运行速度上相比普通 JavaScript 有了质的飞跃。但是 asm.js 自身也存在一些无法忽视的问题，比如“慢启动”问题、拓展 asm.js 越来越复杂且不可靠，以及随着 asm.js 想要更加接近于 Native 的执行性能，不免会对诸多 Math 函数进行拓展和改写。总之， asm.js 并不是一个非常理想的技术方案。
合作共赢 - WebAssembly
在 2013 年，NaCl/PNaCl 与 asm.js/Emscripten 形成了不同路线发展的竞争态势，但与此同时，Google 及 Mozilla 也在工具及虚拟机层面加强了许多合作，其中包括：
每月 Google 和 Mozilla 工具团队之间开展交流会；
Emscripten 和 PNaCl 开始共享部分代码；
尝试将 NaCl 应用通过 Emscripten 编译，并开源 Pepper.js；
Google 及 Mozilla 共同向 asm.js 贡献代码，并规划未来 Native Code 在 Web 上的合理方案；
就 WebAssembly 前身“WebAsm”进行标准和方案的讨论。
最终在 2015 年的 4 月 1 号，“WebAssembly”击败了“WebAsm”。至 2015 年 6 月 17 号，两方就 WebAssembly 的标准化工作达成一致，并搭建了 WebAssembly 官网开始对外宣传。WebAssembly 的设计汲取了 NaCl 与 asm.js 两者的优点：
WebAssembly 并不依赖于 JavaScript，与 NaCl/PNaCl 一样，它基于二进制格式，能够被快速解析；
与 asm.js 一样，依靠 Emscripten 等工具链提供的 API，它以非常自然的方式直接操作 Web APIs，而不用像 PNaCl 一样需要处理与 JavaScript 之间的通信；
WebAssembly 依赖于 LLVM IR 并使用独立的 VM 环境，因此其它语言 / 平台能够以较低成本接入，同时能够且易于被持续优化至接近 Native 的性能。
目前各大主流浏览器已经完全实现了 WebAssembly 的 MVP 版本，并将其接纳为“浏览器的第二语言”。依靠优秀的设计，WebAssembly 也从浏览器平台走向更多平台，随着 WebAssembly 相关标准逐渐确定和完善，WebAssembly 技术的应用领域将会越来越广。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论