1 files changed, 275 insertions, 0 deletions
diff --git a/files/zh-cn/mozilla/add-ons/webextensions/构建一个跨浏览器的扩展插件/index.html b/files/zh-cn/mozilla/add-ons/webextensions/构建一个跨浏览器的扩展插件/index.html
new file mode 100644
index 0000000000..6d1a21497c
--- /dev/null
+++ b/files/zh-cn/mozilla/add-ons/webextensions/构建一个跨浏览器的扩展插件/index.html
@@ -0,0 +1,275 @@
+---
+title: 构建一个跨浏览器的扩展程序
+slug: Mozilla/Add-ons/WebExtensions/构建一个跨浏览器的扩展插件
+tags:
+  - Web插件
+  - 扩展
+  - 指南
+  - 插件
+translation_of: Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension
+---
+<p>{{AddonSidebar()}}</p>
+
+<p>浏览器扩展 API 的引入为浏览器扩展的开发创造了 “一次开发跨浏览器” 的前景。然而，在使用扩展 API 的浏览器中(主要是 Chrome、 Firefox、 Opera 和 Edge) ，API 的实现和覆盖范围都存在差异。除此之外，Safari 使用了它自己的 Safari 扩展脚本系统。</p>
+
+<p>最大化兼容浏览器扩展意味着至少在两个不同的浏览器上兼容同一个扩展。本文探讨了在创建跨浏览器扩展时所面临的六个主要挑战，并在每种情况下提出了如何应对这些挑战。</p>
+
+<p>本文不讨论为 Safari 构建浏览器扩展。您可以通过 Safari 扩展共享一些资源，比如图片和 HTML 内容。然而，如果您要进行 JavaScript 部分的编程则需要作为一个单独的开发项目进行，除非您希望创建自己的 polyfill。</p>
+
+<h2 id="跨平台扩展的开发障碍">跨平台扩展的开发障碍</h2>
+
+<p>在开发跨平台扩展时，需要注意以下六个方面:</p>
+
+<ul>
+ <li>API 命名空间</li>
+ <li>API 异步事件处理</li>
+ <li>API 函数覆盖率</li>
+ <li>Manifest 的字段</li>
+ <li>打包扩展</li>
+ <li>发布扩展</li>
+</ul>
+
+<h3 id="API_命名空间">API 命名空间</h3>
+
+<p>在四大主流浏览器中，有两个 API 命名空间正在使用:</p>
+
+<ul>
+ <li><code>browser.* </code>是 Firefox 和 Edge 使用的扩展 API 的标准</li>
+ <li><code>chrome.*</code> 是 Chrome 和 Opera 使用的扩展 API 的标准</li>
+</ul>
+
+<p>Firefox 也支持 Chrome 浏览器的 <code>chrome.*</code> 名称空间，主要用于协助扩展移植。然而，首选应该使用浏览器 <code>browser.*</code> 命名空间。除了被提议的标准外， <code>browser.*</code> 使用 promises ーー一种现代化且简单的处理异步事件机制。</p>
+
+<p>只有在非常小的扩展中，命名空间才可能是唯一的跨平台问题。因此，如果你遇到了且试图专门解决这个问题的话，可能很少会有帮助。最好的方法是通过异步事件处理来解决这个问题。</p>
+
+<h3 id="API_异步事件处理">API 异步事件处理</h3>
+
+<p>在四个主要浏览器中，有两种方法可以处理异步事件:</p>
+
+<ul>
+ <li>promises 是 Firefox 使用的扩展 API 的标准</li>
+ <li>callbacks 是 Chrome、Edge 和 Opera 使用的扩展 API 的标准</li>
+</ul>
+
+<p>Firefox 还支持 <code>chrome.*</code> 命名空间中的 callbacks 风格的 API，这主要是为了便于从 Chrome <a href="https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Porting_a_Google_Chrome_extension">迁移</a>。然而，应该首选使用 promises（以及 <code>browser.*</code> 命名空间），它已被采纳为拟议标准的一部分。它极大地简化了异步事件处理，特别是在需要将事件链接在一起的情况下。</p>
+
+<div class="blockIndicator note">
+<p>如果你对这两种方法之间的差异不熟悉，可以看一下 <a href="https://medium.com/codebuddies/getting-to-know-asynchronous-javascript-callbacks-promises-and-async-await-17e0673281ee">了解异步 JavaScript: Callbacks、 Promises 和 Async/Await </a>或者 MDN 的 <a href="/en-US/docs/Web/JavaScript/Guide/Using_promises">Using promises</a> 页面。</p>
+</div>
+
+<h4 id="浏览器扩展_API_的垫片（Polyfill）">浏览器扩展 API 的垫片（Polyfill）</h4>
+
+<p>那么，当 Firefox 是唯一支持它的浏览器时，你如何轻松地使用 promises 呢？解决方案是使用 promises 为 Firefox 编程，并使用<a href="https://github.com/mozilla/webextension-polyfill/">浏览器扩展 API 的垫片（Polyfill）</a>！<br>
+ <br>
+ 这个 polyfill 解决了跨 Firefox、 Chrome 和 Opera 的 API 名称空间和异步事件处理。在撰写本报告时(2018年11月) ，Edge 的支持正在开发中。<br>
+ <br>
+ 要使用 polyfill，可以使用 npm 安装到开发环境中，或者直接从 <a href="https://github.com/mozilla/webextension-polyfill/releases">GitHub Relase</a> 页面下载。</p>
+
+<p>然后，引入 <code>browser-polyfill.js</code> 到:</p>
+
+<ul>
+ <li><code>manifest.json</code>，修改后使它可以用于 background 和 content 脚本</li>
+ <li>HTML 文件，例如 <code>browserAction</code> 弹出窗口或标签页</li>
+ <li>使用 <code>tabs.executeScript</code> 上的 <code>executeScript</code> 动态注入脚本（不需要事先在 manifest.json 的 <code>content_scripts</code> 中申明</li>
+</ul>
+
+<p>例如，这个 <code>manifest.json</code> 代码让你的后台脚本可以使用 polyfill:</p>
+
+<pre class="brush: json notranslate">{
+ // ...
+ "background": {
+   "scripts": [
+     "browser-polyfill.js",
+     "background.js"
+   ]
+ }
+}</pre>
+
+<p>您的目标是确保在任何其他扩展脚本执行 <code>browser.*</code> API 前执行 polyfill。</p>
+
+<div class="blockIndicator note">
+<p>关于如何使用模块打包器使用 polyfill 的更多细节和信息，请参阅 <a href="https://github.com/mozilla/webextension-polyfill/blob/master/README.md">GitHub 上的项目自述文件</a>。</p>
+</div>
+
+<p>还有其他的 polyfill 选项，但是在撰写本文时，没有一个提供浏览器扩展 API polyfill 的覆盖范围。所以，如果你没有把 Firefox 作为你的首选，你的选择就是接受 polyfills 的限制，移植到 Firefox 并添加跨浏览器的支持，或者开发你自己的 polyfill。</p>
+
+<h3 id="API_函数覆盖率">API 函数覆盖率</h3>
+
+<p>这四个主要浏览器提供的 API 函数的实现差异可分为三大类:</p>
+
+<ul>
+ <li><strong>缺乏对整个功能的支持。</strong>例如，在撰写本文时，Edge 没有提供对<a href="https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/privacy#Browser_compatibility">隐私</a>功能的支持。</li>
+ <li><strong>缺乏对某些特性的支持。</strong>例如，在撰写本文时，Firefox 不支持 <code>onButtonClicked</code>，而只支持 <code>onShown</code>。</li>
+ <li><strong>专有功能，支持特定于浏览器的特性。</strong>例如，在撰写本文时，容器是一个特定于 firefox 的特性，由 <code>contextualidentity</code> 函数支持。</li>
+</ul>
+
+<p>你可以在 <a href="https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs">Mozilla Developer Network 浏览器对 JavaScript API 页面的支持</a>上找到4个主要浏览器对扩展 API 的支持细节，以及 Firefox for Android 对扩展 API 的支持细节。浏览器兼容性信息也包含在每个函数及其方法、类型和事件的 Mozilla Developer Network <a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/API">JavaScript APIs</a> 参考页面中。</p>
+
+<h4 id="处理_API_差异">处理 API 差异</h4>
+
+<p>解决这些差异的一个简单方法是将扩展中使用的函数限制在没有 API 差异的函数范围内。在实践中，对于大多数扩展，这种方法可能限制性太强。<br>
+ <br>
+ 相反，如果 API 之间存在差异，则应该提供替代实现或降级功能。(请记住: 您可能还需要这样考虑同一浏览器的不同版本之间的 API 支持差异。)</p>
+
+<p>使用运行时检查函数特性的可用性是实现备选或降级功能的推荐方法。执行运行时检查的好处是，如果函数是可用的，您不需要更新和重新分发扩展来使用它。</p>
+
+<p>下面的代码使您能够执行运行时检查:</p>
+
+<pre class="brush: js notranslate">if (typeof &lt;function&gt; === "function") {
+   // safe to use the function
+}</pre>
+
+<h3 id="Manifest_字段">Manifest 字段</h3>
+
+<p>4个主要浏览器支持的 <code><a href="/zh-CN/docs/https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_compatibility_for_manifest.json">manifest.json</a></code> 文件字段的差异大致可分为三类:</p>
+
+<ul>
+ <li><strong>扩展信息属性。</strong>例如，在撰写本文时，Firefox 和 Opera 包含和 <code><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/author#Browser_compatibility">author</a></code> 地位相等的 <code><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/developer#Browser_compatibility">developer</a></code> 关键字，以获取扩展的开发者和作者的详细信息。</li>
+ <li><strong>扩展功能。</strong>例如，在编写本文时，Edge 不支持扩展定义快捷键的 <code><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/commands#Browser_compatibility">commands</a></code> 字段。</li>
+ <li><strong>字段可选性。</strong>例如，在编写本文时，在 Edge 中 <code><a href="/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/author#Browser_compatibility">author</a></code> 字段是必需的，但在其他主要浏览器中是可选的。</li>
+</ul>
+
+<p>浏览器兼容性信息包含在 Mozilla Developer Network <code><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json">manifest.json</a></code> 页的每个字段中。</p>
+
+<p><code>manifest.json</code> 文件在不同浏览器之间的版本号可能有所不同，为每个浏览器创建和编辑一个静态版本号通常是最简单的方法。</p>
+
+<h3 id="扩展打包">扩展打包</h3>
+
+<p>通过浏览器扩展商店打包和分发扩展相对简单。</p>
+
+<ul>
+ <li><font>火狐、 Chrome 和 Opera 都使用简单的 zip 格式打包，同时需要 </font><code>manifest.json</code> <font>文件位于压缩包的根目录。</font></li>
+ <li><font>但是，提交到 Microsoft 扩展商店需要对扩展文件进行额外打包。</font></li>
+</ul>
+
+<p>有关打包的详细信息，请参阅相应扩展的开发人员门户网站上的指南。</p>
+
+<h3 id="扩展发布">扩展发布</h3>
+
+<p>这四种主要浏览器都维护有浏览器扩展商店。每个商店还对扩展进行审核，以检查安全漏洞。</p>
+
+<p>因此，您需要为每个商店分别添加和更新扩展。在某些情况下，您可以使用脚本上传扩展。</p>
+
+<p>下表总结了每个商店的做法和特点:</p>
+
+<table>
+ <tbody>
+  <tr>
+   <td></td>
+   <td>
+    <p>注册费</p>
+   </td>
+   <td>
+    <p>上传模块</p>
+   </td>
+   <td>
+    <p>发布审核</p>
+   </td>
+   <td>
+    <p>开发者账号需要2FA验证</p>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p>Firefox</p>
+   </td>
+   <td>
+    <p>否</p>
+   </td>
+   <td>
+    <p><a href="/en-US/Add-ons/WebExtensions/web-ext_command_reference">web-ext</a></p>
+   </td>
+   <td>
+    <p>全自动，仅需要几秒钟<sup>1</sup></p>
+   </td>
+   <td>
+    <p>否</p>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p>Chrome</p>
+   </td>
+   <td>
+    <p>是</p>
+   </td>
+   <td>
+    <p>是</p>
+   </td>
+   <td>
+    <p>全自动，短于一小时</p>
+   </td>
+   <td>
+    <p>是</p>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p>Opera</p>
+   </td>
+   <td>
+    <p>否</p>
+   </td>
+   <td>
+    <p>否</p>
+   </td>
+   <td>
+    <p>人工审核，但不需要提供SLA</p>
+   </td>
+   <td>
+    <p>否</p>
+   </td>
+  </tr>
+  <tr>
+   <td>
+    <p>Edge</p>
+   </td>
+   <td>
+    <p>是</p>
+   </td>
+   <td>
+    <p>否</p>
+   </td>
+   <td>
+    <p>人工审核，需要72小时<sup>2</sup></p>
+   </td>
+   <td>
+    <p>是</p>
+   </td>
+  </tr>
+ </tbody>
+</table>
+
+<p><sup>1</sup> 在发布后会延期进行一次人工审查，如果发现了需要解决的问题，可能导致扩展被暂停。</p>
+
+<p><sup>2</sup> 在撰写本文时，微软只允许发布预先批准的扩展。</p>
+
+<h3 id="其他考虑">其他考虑</h3>
+
+<h4 id="扩展命名">扩展命名</h4>
+
+<p>Microsoft 要求扩展具有唯一的名称，并通过 Windows Dev Center 为扩展声明一个或多个名称。因此，即使您不打算立即支持 Edge，为微软保留一个扩展名可能是最谨慎的做法。</p>
+
+<h4 id="版本号指定">版本号指定</h4>
+
+<p>Firefox 和 Chrome 商店要求每个上传的扩展发布包都有一个单独的版本号。这意味着如果在线上遇到问题，就不能恢复到之前的版本号。</p>
+
+<h4 id="在不同的实现中共享资源">在不同的实现中共享资源</h4>
+
+<p>即使你要支持的平台中包括 Safari，仍然可以在对于不同浏览器的实现中共享许多资源。其中包括:</p>
+
+<ul>
+ <li>Images</li>
+ <li>HTML</li>
+ <li>CSS</li>
+</ul>
+
+<h2 id="总结">总结</h2>
+
+<p>在进行跨平台扩展开发时，可以通过对标 Firefox 和使用 <a href="https://github.com/mozilla/webextension-polyfill/">WebExtension API Polyfill</a> 来解决扩展 API 之间的根本差异。遵循这种方法，您将在使用与提议的 WebExtension API 标准紧密结合的 API 特性中受益，并使用 promises 来简单的处理异步事件。</p>
+
+<p>跨平台工作的主要重点可能是处理主要浏览器支持的 API 特性之间的差异。创建你的 <code>manifest.json</code> 文件应该是相对简单的，你可以手动完成。然后，您将需要考虑扩展包中的打包差异，以及提交到每个扩展商店的过程差异。</p>
+
+<p>您同时可以使用<a href="https://github.com/notlmn/browser-extension-template"> browser-extension-template</a> 用于快速设置、生成和发布浏览器扩展项目。</p>
+
+<p>根据本文中的建议，您现在应该能够创建一个在四种主要浏览器上都运行良好的扩展程序，使您能够将扩展功能交付给更多的人。</p>