内容简介:WebAssembly,火狐赢了?
自从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 )关注我们。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 前 Mozilla 高管爆料,谷歌一直在破坏火狐
- 火狐 Firefox 63 Nightly 更新支持 GPU 网页渲染
- Mozilla 优化 WebAssembly 和 JS 在火狐的调用
- Mozilla 优化 WebAssembly 和 JS 在火狐的调用
- 火狐浏览器66将减少内存占用,扩展插件性能加强
- 你追我赶,Opera 51 运行速度比量子火狐快 38%
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Music Recommendation and Discovery
Òscar Celma / Springer / 2010-9-7 / USD 49.95
With so much more music available these days, traditional ways of finding music have diminished. Today radio shows are often programmed by large corporations that create playlists drawn from a limited......一起来看看 《Music Recommendation and Discovery》 这本书的介绍吧!