自从 WebAssembly 标准发布以及各大浏览器完成对其默认支持之后,WebAssembly 成为前端热门话题。在 WebAssembly 之前,类似的前端二进制标准有火狐主导的 asm.js 和 Chrome 主导的 PNaCl。二者均用于将后端 C/C++ 代码用于前端,作为它们折中方案,WebAssembly 标准更偏向于 asm.js 的实现。Chrome 在支持了 WebAssembly 标准之后,宣布将放弃对PNaCl 的支持。
作为前端标准,PNaCl 在创立之初就有其先天不足。在设计上,PNaCl 代码和前端代码(Javascript、HTML 等)高度独立,并且PNaCl 代码运行在独立进程中,这使得PNaCl 代码和页面代码交互成本非常高(需要通过IPC 方式)。另外,处于安全考虑,PNaCl 进程运行在沙箱环境中,Chrome 为此定义了一套API,称为:Pepper。Pepper 定义的API 中,有许多和现行Web 标准重复。
更加严重的问题是,不论是Pepper 还是PNaCl,都没有明确的二进制代码规范。因此非Chrome 浏览器如果要兼容PNaCl 插件,要么反向工程Pepper 来自己实现一套接口实现,要么从Chromium 工程中导入其中的实现代码。无论哪种方式,都需要和Google 的修改同步。这对于开发者来说是不可接受的。
相反,asm.js 实现方式从一开始就尽量贴近前端开发和已有前端标准。asm.js 用Javascript 数组来表示内存,并将C/C++ 代码编译成Javascript 以操作这个数组。这种实现方式相比PNaCl 有一个很大的优势:所有代码在同一个JS 虚拟机中运行,可以方便的和其他Javascript 代码、DOM 进行交互。另外,这样的实现没有引入新的API,因此文档相关的工作也比较少。
综上所述,WebAssembly 标准最终和asm.js 比较接近,它实现在JS 虚拟机中,可以和页面Javascript 之间方便的进行调用。WebAssembly 标准除了新增加载和链接WebAssembly 代码相关的 API 之外,没有定义新的平台相关 API。和 asm.js 不同的是,WebAssembly 完整定义了二进制代码规范,相关规范文档已经完成。
当然,Google 和其他团队在WebAssembly 标准的制定上也功不可没。针对PNaCl 插件,Google 已经发布了迁移文档。可以说,WebAssembly 标准的发布,真正的赢家是开发者!
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论