Firefox擴展：性能：覆蓋與自舉

Question

我理解安裝自舉擴展的方便性，但有一個問題一直困擾着我。

覆蓋和引導擴展之間是否有性能和資源/內存使用比較？

在疊加擴展中，許多工作，即XUL疊加等都由應用程序（即Firefox）進行處理。 在引導擴展中，所有上述工作都留給擴展開發人員，這通常涉及手動添加許多事件監聽器和觀察者以實現相同的目標（可能不像應用程序核心本地化）。

我注意到在某些窗口上無法啟動的無啟動插件。 我也注意到了無用的插件，有時，插入本身是顯而易見的（即窗口加載后功能，圖像，圖標稍微有點）。 此外，所使用的均勻收聽者的類型不均勻並且變化很大。

我有一種嘮叨的感覺，手動（而不是原生）添加菜單，上下文菜單，函數，字符串捆綁，首選項，本地化等，枚舉窗口將使用更多的資源（除了它的效率將極大地依賴於開發人員的技能） 。

我期待你的評論 ：）

Answer 1

附加組件的執行方式主要取決於實際的實現（附加組件的作用和方式）以及它保留的數據。 因此你真的不能只比較與無需重啟附加組件覆蓋的性能。

我將附加組件從疊加轉換為無重啟的附加組件，之后表現更好，因為我在此過程中優化了一些功能。 當然，在其他情況下，情況恰恰相反。

內存消耗取決於附加組件的功能，包括。 它創建了多少個事件監聽器。 除非你創建成千上萬的事件監聽器（也就是閉包中的偽泄漏），否則這些監聽器消耗的內存通常可以忽略不計：內存會告訴你。 您可以擁有內存飢餓的覆蓋加載項和輕量級無重啟加載項，反之亦然。

你的權利很大程度上取決於開發人員的技能，即實施和數據結構設計的質量，這通常與所述技能直接相關。

• 創建一個簡單的“按鈕”SDK附加組件很容易，但SDK有很多很多的抽象來使它變得簡單，而這些抽象消耗資源（內存，CPU甚至文件I / O）。
• 創建一個等效的疊加插件有點困難，但是你仍然可以免費獲得很多東西（ overlay ， style ）。 這些細節也是更高層次的抽象，並且需要付出代價。
• 創建一個等效的自舉附加組件是相當困難的，但是如果正確完成它可能會勝過其他附加類型，即使在啟動時也是如此（沒有chrome.manifest來讀取，解析和解釋，沒有同步加載疊加和相關樣式等）

這有點像將C（無重啟）與Java（覆蓋）與Ruby（SDK）進行比較。 人們喜歡Ruby的便利，但正確的Java代碼很容易超越它。 然后，Java通常會勝過由新手開發人員編寫的等效C程序（也是那些新手開發人員更有可能在整個地方泄漏內存;），但是由熟練的開發人員編寫的C程序可能勝過Java。

你在這里問的內容基本上表明過早優化 。 而是根據您的技能水平編碼，測量然后根據需要進行優化。

一旦您注意到您的附加組件消耗大量內存或運行緩慢，則測量和/或調試原因。 或者只是積極主動地衡量。 關鍵是： 衡量 。

如果不是你的附加組件行為不端，請告訴作者，或者如果真的很糟糕，請提交技術布道錯誤 。

因為你詢問DOM操作/覆蓋， addEventListener與“native”：

• 覆蓋可能比從JS調用一堆DOM方法更快。 但是再一次，疊加是XML，需要從磁盤讀取，然后解析成DOM，然后DOM需要與覆蓋的DOM合並，遵循各種規則等。這需要各種I / O，（臨時）內存，CPU等。因此疊加可能會更慢。 取決於疊加層。
• addEventListener通常非常快。 實際上，覆蓋“事件”監聽器（那些令人討厭的oncommand / onclick / onwhatever屬性）在內部使用相同的實現（好吧，有點），此外，通過創建匿名，來自這些屬性的字符串值將被拋入JS引擎來自這些字符串的函數（這也需要時間;）

無論如何，在少數情況下，我實際上測量了無重啟加載項中的UI初始化（只有JS中的DOM內容），並且它總是出現在（較低的）兩位數毫秒范圍內的任何附加組件中的一些合理的DOM和偵聽器的數量（<100）。

BTW：

我也注意到了無用的插件，有時，插入本身是顯而易見的（即窗口加載后功能，圖像，圖標稍微有點）。

是的，一些無重啟的附加組件，例如異步加載（toolbarbutton）圖像，或者將它們的初始化延遲（一些）到以后的點（例如，為什么在popupshowing顯示之前填充上下文菜單？）。 這可能效率稍低（因為它可能導致重繪）或者可能更有效（因為瀏覽器可以繼續執行其他初始化代碼，例如圖像在后台加載）。

如果無重啟的加載項無法初始化，那么這就是一個錯誤。 但我確實提到過不重新啟動的附加組件已經很難編寫了。

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