Firefox addon Firefox扩展：性能：覆盖vs引导

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

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

在覆盖扩展中，很多工作，比如XUL覆盖等都是由应用程序（ie Firefox）本地处理的。 在自举扩展中，所有上述工作都留给扩展开发人员完成，扩展开发人员通常需要手动添加许多事件侦听器和观察器以实现相同的功能（可能不像应用程序核心那样是本机的）

我注意到一些窗口上的惊人插件有时无法启动。我也注意到了一些惊人的插件，有时候，插入本身是显而易见的（即功能、图像、图标在窗口加载后稍微出现）。此外，所使用的偶数侦听器的类型并不一致，而且差异很大

我有一种烦人的感觉，手动（而不是本地）添加菜单、上下文菜单、函数、字符串包、首选项、本地化等并枚举窗口将使用更多的资源（此外，其效率将在很大程度上取决于开发人员的技能）

我期待着您的评论

---

：）

外接程序的执行方式主要取决于实际实现（外接程序的功能和方式）及其保存的数据。因此，您不能仅仅比较overlay和restartless插件的性能

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

内存消耗取决于插件的功能，包括它创建了多少个事件侦听器。除非您创建成千上万的事件侦听器（也就是闭包中的伪泄漏内容），否则这些侦听器消耗的内存通常可以忽略不计，因为内存会告诉您。您可以使用内存不足的覆盖加载项和轻量级无重启加载项，反之亦然

你是对的，效率在很大程度上取决于开发人员的技能，即实现和数据结构设计的质量，这通常与所述技能直接相关

• 创建一个简单的“按钮”SDK插件很容易，但是SDK有很多抽象使其变得容易，而且这些抽象会消耗资源（内存、CPU甚至文件I/O）
• 创建一个等价的覆盖插件有点困难，但仍然可以免费获得很多东西（

  overlay

  ，

  style

  ）。这些细节也是更高层次的抽象，需要付出代价
• 创建一个等效的引导加载项是相当困难的，但是如果操作正确，它可能会优于其他加载项类型，即使在启动期间也是如此（没有chrome.manifest来读取、解析和解释，没有覆盖和相关样式的同步加载，等等）

---

这有点像比较C（无重启）、Java（覆盖）和Ruby（SDK）。人们喜欢Ruby的便利性，但适当的Java代码很容易胜过它。同样，Java的性能往往优于新手开发人员编写的同等C程序（这些新手开发人员也更有可能到处泄漏内存），但由熟练开发人员编写的C程序的性能可能优于Java

你在这里问的基本上是暗示。相反，编码、测量，然后根据您的技能水平进行优化（如有必要）

一旦您注意到加载项占用大量内存或运行缓慢，请测量和/或调试原因。或者只是主动测量。重点是：衡量

如果不是你的插件出了问题，告诉作者，或者是真的很糟糕

由于您询问了DOM操作/覆盖，

addEventListener

vs.“native”：

• 覆盖可能比从JS调用一堆DOM方法更快。但同样，覆盖是XML，需要从磁盘读取，然后解析为DOM，然后需要将DOM与覆盖的DOM合并，遵循各种规则等。这些规则需要各种I/O、（临时）内存、CPU等。因此覆盖可能会较慢。取决于覆盖层

• addEventListener

  通常速度极快。事实上，覆盖“事件”侦听器（那些讨厌的

  oncommand

  /

  onclick

  /

  onwhatever

  属性）在内部使用相同的实现（嗯，有点），另外，这些属性中的字符串值无论如何都会通过从这些字符串创建匿名函数扔到JS引擎中（这也需要时间；）

---

无论如何，在少数情况下，我确实在无重启加载项（仅JS中的DOM内容）中测量了UI初始化，对于任何具有合理数量的DOM和侦听器的加载项，结果总是在（较低的）两位数毫秒范围内（再次感谢您花时间和您的全面回复）：我不熟悉插件，但我开始用Perl和PHP（早期的PHP）编写服务器端程序。因此，我一直在考虑性能和优化。我查看了SDK，认为它不适合我。我更喜欢深入了解代码的核心。在性能比较中，我指的是将相同的加载项/代码打包为覆盖和无重启。我已经编写了一些覆盖加载项。我将更仔细地研究引导加载ly（尽管文档数量有限）“而且那些新手开发人员更可能到处泄漏内存”-通过js ctypes有罪>_