我理解安装自引导扩展的便利性，但有一个问题一直困扰着我很长一段时间。
是否曾经有过演出&重叠&资源/内存使用比较;引导扩展?
在覆盖扩展中，很多工作，如XUL覆盖等都是由应用程序(如Firefox)本地处理的。在自引导扩展中，上述所有工作都留给扩展开发人员，这通常涉及手动添加许多事件侦听器和观察者来实现相同的目标(这可能不如应用程序核心那样原生)。
我注意到在某些窗口上无法启动的插件。我还注意到，在某些情况下，插入本身是明显的(即功能，图像，图标在窗口加载后稍微出现)。此外，所使用的均匀侦听器的类型也不统一，差异很大。
我有一种唠叨的感觉，手动(而不是本地)添加菜单，上下文菜单，函数，字符串包，首选项，本地化等和枚举窗口将使用更多的资源(除了它的效率将在很大程度上取决于开发人员的技能)。
我期待你的评论:)
附加组件如何执行主要取决于实际实现(附加组件做什么以及如何做)和它保存的数据。因此，你不能真正的只是比较叠加和无重启的附加组件的性能。
我将附加组件从覆盖转换为事后表现更好的无重启插件，因为我一路上优化了一些东西。当然，在其他情况下，情况可能正好相反。
内存消耗取决于附加组件的功能，包括它创建了多少个事件侦听器。除非您创建了成千上万的事件侦听器(在闭包中也是伪泄漏的东西)，否则这些侦听器消耗的内存通常可以忽略不计，正如内存会告诉您的那样。你可以有占用大量内存的附加组件和轻量级的不重启附加组件，反之亦然。
你是对的，效率很大程度上取决于开发人员的技能，即实现和数据结构设计的质量，这通常与上述技能直接相关。
- 创建一个简单的"按钮"SDK插件很容易，但是SDK有很多抽象使它变得容易，这些抽象消耗资源(内存，CPU甚至文件I/O)。
- 创建一个等效的覆盖附加组件有点困难，但仍然可以免费获得相当多的东西(
overlay,style)。这些细节也是更高层次的抽象，并且是有代价的。 这是相当困难的创建一个等效的启动附加组件，但如果做得正确，它可能优于其他类型的附加组件，甚至在启动期间(没有chrome)。manifest需要读取、解析和解释，没有同步加载叠加和相关的样式等)
这有点像比较C(无重启)、Java(覆盖)和Ruby (SDK)。人们喜欢Ruby的便利性，但是合适的Java代码很容易胜过Ruby。然而，Java通常会优于由新手开发人员编写的同等C程序(而且这些新手开发人员更有可能到处泄漏内存;)，但是由熟练开发人员编写的C程序可能会优于Java。
你在这里问的基本上是过早优化的指示。取而代之的是编码、测量，然后根据你的技能水平进行必要的优化。
一旦您注意到您的附加组件消耗大量内存或运行缓慢，那么测量和/或调试原因。或者只是主动地衡量。关键是:测量。
如果不是你的插件有问题，告诉作者，或者如果它真的很糟糕，就提交一个技术布道错误。
既然你问DOM操作/覆盖，addEventListener vs。"本地":
- Overlays可能比从JS中调用一堆DOM方法要快。但话说回来，覆盖层是XML，需要从磁盘读取，然后解析为DOM，然后DOM需要与被覆盖的DOM合并，遵循各种规则，等等。这需要各种I/O、(临时)内存、CPU等。所以叠加可能会比较慢。取决于覆盖。
-
addEventListener通常非常快。事实上，叠加"事件"监听器(那些讨厌的oncommand/onclick/onwhatever属性)，在内部使用相同的实现(好吧，有点)，此外，这些属性的字符串值将通过从这些字符串创建匿名函数(这也需要时间;)，无论如何都会被扔进JS引擎。
无论如何，在少数情况下，我确实测量了UI初始化在无重启的附加组件(只有DOM的东西在JS中)，它总是在(低)两位数毫秒范围内的任何附加组件与合理数量的DOM和监听器(<100)。
顺便说一句:
我还注意到，在某些情况下，插入本身是明显的(即功能，图像，图标在窗口加载后稍微出现)。
是的，一些不可重启的附加组件，例如，异步加载(工具栏按钮)图像，或延迟(一些)初始化到稍后的点(例如，为什么在popupshowing之前填充上下文菜单?)这可能会降低效率(因为它可能导致重绘)或更有效(因为浏览器可以继续执行其他初始化代码，例如在后台加载图像)。
如果不启动的附加组件初始化失败，那么，这是一个bug。但是我确实提到过，不启动的附加组件已经相当难以编写了。
PS: Gecko Profiler和about:memory是你的朋友;)