web开发之PPAPI开发指南.docxVIP

PPAPI插件开发指南 转载请注明出处：/fangkm/p/4401075.html 前言 插件一直是浏览器的重要组成部分，丰富浏览器的运行能力，实现一些HTML+JS实现不了本地应用（比如音视频、文件操作等）。早期广为熟知的是IE下的插件ActiveX，这是一项熟悉可能暴露年龄的技术，它基于COM规范，在IE占浏览器市场主流份额的时代，ActiveX可谓出尽了风头，但它并不是浏览器业内的插件标准。由网景发布的NPAPI长久以来是除了IE之外的其他浏览器共同支持的业内标准。ActiveX和NPAPI长久共存，如果某项业务要发布浏览器插件，一般都需要实现这两种插件规范。有个开源的插件开发框架FireBreath?抽象了这两种插件的接口细节，让开发者专注于业务逻辑（个人比较嫌弃FireBreath?开发出来的插件体积太大）。早期的银行开发网页安全控件都是使用ActiveX开发，所以他们都要求在IE浏览器或者其他双核浏览器的兼容模式下登录。现在很多银行已经支持NPAPI版本的安全控件，但NPAPI却做为不安全因素被主流浏览器（Chrome、FireFox）抛弃，好在国内的双核浏览器都保留有NPAPI功能的移植，让市面上大量的NPAPI插件得以正常运行。现在，随着IE逐渐退出历史舞台，ActiveX插件的运行范围越来越窄，NPAPI也成为过时的插件标准，虽然HTML5标准也在逐渐完善，很多之前只靠Web技术做不到的功能都能得到很好的支持，但是并不是所有的功能都能通过HTML5实现，本地插件依然是我们这个时代绕不开的功能应用，最典型的比如Flash。于是Chrome提出了名叫PPAPI的全新插件机制，运行在Chrome浏览器的沙箱环境。 插件类型 Chrome 基于Chromium核的浏览器 IE ActiveX No No Yes NPAPI No Yes（暂时兼容） No PPAPI Yes Yes No 从对比可以看出，PPAPI的运行场景完全覆盖NPAPI，以后开发插件完全可以只开发PPAPI+ActiveX两个版本。但是目前市面上，除了内置的PPAPI版本的Flash组件以及Pdf组件，没遇到其他的PPAPI版本的商业组件，可见再造一个平台是多么地不容易。 PPAPI组件介绍 在Chrome中，PPAPI组件分为两种存在形式： 可信组件：可信的PPAPI组件可以通过平台动态库的形式（Windows下为dll文件，Linux下是so文件）由浏览器直接加载，比如内置的Flash组件、Pdf组件，或者通过指定命令行参数--register-pepper-plugins来加载，比如：chrome --register-pepper- plugins="D:\\ppapi\\ppapi_example_gles2.dll;application/x-ppapi-example-gles2" D:\\ppapi\\gles2.html，这种方案常用于调试。可信的PPAPI组件以平台动态库的形式存在，所以一般Chrome沙箱内允许的API（比如CreateThread）都可以调用。 不可信组件：不可信的PPAPI组件需要使用Native Client机制发布（以Native Client的形式发布到Chrome Web Store或者以Portable Native Client的形式发布了网址的Web服务器上），而Native Client需要维系跨平台可移植性，完全与系统API告别了，只能使用PPAPI提供的开发库和C/C++运行库，不过目前来看，基本的需求也是可以满足的。 下面贴一段PPAPI与JS交互的典型场景： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 <object id="plugin"?type="application/x-ppapi-post-message-example"??width="1"?height="1"/> ??function?HandleMessage(message_event) { ????if?(message_event.data) { ??????alert("The string was a palindrome."); ????}?else?{ ??????alert("The string was not a palindrome."); ????} ??} ? ??function?AddListener() { ????var?plugin = document.getElementById("plugin"); ????plugin.addEventListener("message", Handl