@babydragon
2017-06-08T19:50:09.000000Z
字数 1170
阅读 1636
前端
自从WebAssembly标准发布以及各大浏览器完成对其默认支持之后,WebAssembly成为前端热门话题。作为asm.js和PNaCl的折中方案,Chrome在支持了WebAssembly标准之后,宣布将放弃对PNaCl的支持。这意味着火狐在前端二进制代码标准制定上的胜利吗?
自从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标准的发布,真正的赢家是开发者!