我了解安装引导扩展的便利性，但有一个问题困扰了我很长时间。
覆盖扩展和自举扩展之间是否曾进行过性能和资源/内存使用比较？
在覆盖扩展中，很多工作，即 XUL 覆盖等都是由应用程序（即 Firefox）本地处理的。 在自举扩展中，所有上述工作都留给扩展开发人员，这通常需要手动添加许多事件侦听器和观察器来实现相同的目的（这可能不像应用程序核心那样原生）。
我注意到在某些窗口中有时无法启动的令人吃惊的插件。我还注意到有时令人吃惊的插件，插入本身很明显（即功能、图像、图标在加载窗口后稍微出现）。此外，使用的偶数监听器类型不统一，变化很大。
我有一种烦人的感觉，即手动（而不是本地）添加菜单、上下文菜单、函数、字符串包、首选项、本地化等以及枚举窗口会使用更多资源（除了它的效率将在很大程度上取决于开发人员的技能）。
期待你们的cmets :)
【问题讨论】：
标签： firefox-addon firefox-addon-restartless
插件的执行方式主要取决于实际的实现（插件的作用和方式）以及它保存的数据。因此，您不能真正仅比较覆盖与无需重启的附加组件的性能。
我将附加组件从覆盖转换为之后表现更好的无重启附加组件，因为我在此过程中优化了一些东西。当然，在其他情况下，情况可能正好相反。
内存消耗取决于插件的功能，包括。它创建了多少个事件监听器。除非您创建成千上万的事件侦听器（这也是闭包中的伪泄漏内容），否则这些侦听器消耗的内存通常可以忽略不计，因为 about:memory 会告诉您。您可以拥有需要大量内存的叠加加载项和轻量级的无需重启的加载项，反之亦然。
您说得对，效率很大程度上取决于开发人员所拥有的技能，即实施的质量和通常与所述技能直接相关的数据结构设计。
overlay、style）。这些细节也是更高层次的抽象，而且是有代价的。这有点像将 C（无重启）与 Java（覆盖）与 Ruby（SDK）进行比较。人们喜欢 Ruby 的便利性，但正确的 Java 代码很容易胜过它。话又说回来，Java 通常会胜过由新手开发人员编写的等效 C 程序（而且那些新手开发人员更有可能到处泄漏内存；），但由熟练开发人员编写的 C 程序可能胜过 Java。
你在这里问的基本上是premature optimization。而是根据您的技能水平进行编码、测量，然后在必要时进行优化。
一旦您注意到您的插件消耗大量内存或运行缓慢，请测量和/或调试原因。或者只是主动测量。重点是：测量。
如果不是您的插件行为不端，请告诉作者，或者file a tech evangelism bug 如果它真的很糟糕。
由于您询问 DOM 操作/覆盖，addEventListener 与“原生”：
addEventListener 通常速度非常快。实际上，覆盖“事件”侦听器（那些讨厌的oncommand/onclick/onwhatever 属性）在内部使用相同的实现（嗯，有点），此外这些属性的字符串值将被扔进JS 引擎还是通过从这些字符串创建匿名函数（这也需要时间；）无论如何，在少数情况下，我实际上确实在不重启的附加组件（仅 JS 中的 DOM 内容）中测量了 UI 初始化，并且对于任何附加组件，它总是在（较低的）两位数毫秒范围内进行测量具有合理数量的 DOM 和侦听器 (
顺便说一句：
我还注意到有时令人吃惊的插件，插入本身很明显（即功能、图像、图标在窗口加载后稍微出现）。
是的，一些无需重启的附加组件，例如异步加载（工具栏按钮）图像，或将它们的初始化（某些）延迟到稍后的时间点（例如，为什么要在 popupshowing 之前填充上下文菜单？）。这可能效率低一些（因为它可能导致重绘）或效率更高（因为浏览器可以继续执行其他初始化代码，例如在后台加载图像）。
如果无需重启的附加组件无法初始化，那么这就是一个错误。但我确实提到过，无需重启的插件已经很难编写了。
PS：Gecko Profiler 和 about:memory 是你的朋友 ;)
【讨论】：