1

我了解安装引导扩展的便利性，但有一个问题困扰了我很长时间。

覆盖和引导扩展之间是否有过性能和资源/内存使用比较？

在覆盖扩展中，很多工作，即 XUL 覆盖等都是由应用程序（即 Firefox）本地处理的。在自举扩展中，所有上述工作都留给扩展开发人员，这通常涉及手动添加许多事件侦听器和观察者来实现相同的目的（这可能不像应用程序核心那样原生）。

我注意到在某些窗口上有时无法启动的令人吃惊的插件。我还注意到有时令人吃惊的插件，插入本身很明显（即功能、图像、图标在加载窗口后稍微出现）。此外，使用的均匀监听器的类型并不统一，变化很大。

我有一种烦人的感觉，手动（而不是本地）添加菜单、上下文菜单、功能、字符串包、首选项、本地化等和枚举窗口会使用更多资源（除了它的效率将在很大程度上取决于开发人员的技能这一事实） .

我期待你的评论 ：）

4

1 回答 1

3

插件的执行方式主要取决于实际的实现（插件的作用和方式）和它保存的数据。因此，您不能仅仅比较覆盖与无重启附加组件的性能。

我将附加组件从叠加转换为之后表现更好的无重启附加组件，因为我在此过程中优化了一些东西。当然，在其他情况下，情况可能正好相反。

内存消耗取决于附加组件的功能，包括。它创建了多少个事件监听器。除非您创建成千上万的事件侦听器（这也是闭包中的伪泄漏内容），否则这些侦听器消耗的内存通常可以忽略不计，因为 about:memory 会告诉您。您可以拥有需要大量内存的叠加加载项和轻量级的无需重启的加载项，反之亦然。

没错，效率很大程度上取决于开发人员所拥有的技能，即实现的质量和通常与所述技能直接相关的数据结构设计。

  • 创建一个简单的“按钮”SDK 插件很容易，但是 SDK 有很多抽象来简化它，这些抽象会消耗资源（内存、CPU 甚至文件 I/O）。
  • 创建一个等效的覆盖附加组件有点困难，但你仍然可以免费获得很多东西（overlay, style）。这些细节也是更高级别的抽象，并且是有代价的。
  • 创建一个等效的引导加载项是相当困难的，但如果做得正确，它可能会胜过其他加载项类型，即使在启动期间（没有 chrome.manifest 可以读取、解析和解释，没有同步加载覆盖和相关样式， ETC。）

这有点像将 C（无重启）与 Java（覆盖）与 Ruby（SDK）进行比较。人们喜欢 Ruby 的便利性，但正确的 Java 代码很容易胜过它。话又说回来，Java 通常会胜过由新手开发人员编写的等效 C 程序（而且那些新手开发人员更有可能到处泄漏内存；），但由熟练开发人员编写的 C 程序可能会胜过 Java。

你在这里问什么基本上表明过早优化。而是根据您的技能水平在必要时进行编码、测量然后优化。

一旦您注意到您的插件消耗大量内存或运行缓慢，然后测量和/或调试原因。或者只是主动测量。重点是：测量。

如果不是您的插件行为不端，请告诉作者，或者如果它真的很糟糕，请提交技术布道错误。

既然您询问 DOM 操作/覆盖，addEventListener与“本机”相比：

  • 覆盖可能比从 JS 调用一堆 DOM 方法更快。但是话又说回来，overlays 是 XML，需要从磁盘读取，然后解析成 DOM，然后 DOM 需要与被覆盖的 DOM 合并，遵循各种规则等。这需要各种 I/ O，（临时）内存，CPU等。因此覆盖可能会更慢。取决于覆盖。
  • addEventListener通常速度非常快。实际上，覆盖“事件”侦听器（那些讨厌的//oncommand属性）在内部使用相同的实现（嗯，有点），此外，这些属性的字符串值无论如何都会通过从这些创建匿名函数被扔到 JS 引擎中字符串（这也需要时间；）onclickonwhatever

无论如何，在少数情况下，我实际上确实在不重启的附加组件（仅 JS 中的 DOM 内容）中测量了 UI 初始化，并且对于任何具有合理的附加组件，它总是在（较低的）两位数毫秒范围内进行测量DOM 和侦听器的数量（<100）。

顺便提一句：

我还注意到有时令人吃惊的插件，插入本身很明显（即功能、图像、图标在加载窗口后稍微出现）。

是的，一些无需重启的附加组件，例如异步加载（工具栏按钮）图像，或延迟（某些）它们的初始化（例如，为什么要在之前填充上下文菜单popupshowing？）。这可能效率低一些（因为它可能导致重绘）或者效率更高（因为浏览器可以继续执行其他初始化代码，例如在后台加载图像）。

如果无需重启的附加组件无法初始化，那么这就是一个错误。但我确实提到过，无需重启的附加组件已经很难编写了。

PS：Gecko Profiler是你的about:memory朋友；）

于 2014-06-25T13:13:00.713 回答