Chrome擴展消息架構

Question

我最近開始開發我的第一款Chrome擴展程序，主要是爲了瞭解我是否可以做到這一點，並且我想知道消息傳遞的具體方式。這可能是關於windows.postMessage API的更普遍的問題，但我想知道是否有人能夠解釋控制消息接收和傳播的幕後過程。

這是我目前的消息WRT Chrome擴展的理解：

• 有四類的Javascript：(1) JS綁在彈出，(2) JS在後臺或作爲事件運行，(3) JS內容腳本，以及注入到頁面的JS的(4)。
• (2) -> (1)和(3) -> (1)由runtime.sendMessage()發送。只有在彈出窗口打開時纔會收到它們。
• (1) -> (2)和(3) -> (2)分別由runtime.sendMessage()或tabs.sendMessage()從(3)和(1)發送。它們被儘快接收，因爲背景/事件JS是持久的（我不太確定這是否合適，因爲事件JS必須綁定到eventListeners中）。由tabs.sendMessage()發送。它們被儘快接收，因爲只要網頁是內容腳本（因爲它存在於並行沙箱中），內容腳本就處於活動狀態。
• (*) -> (4)和(4) -> (*)不能被chrome.*的安全問題處理，但是(3) -> (4)和(4) -> (3)可以通過window.postMessage()，進行處理，因爲它們都在網頁的上下文中存在。

有幾件事情我有關於具體問題 - 當然，如果我已經正確地描述了一些事情，第一個問題。其餘的是這些：

• 究竟是runtime.sendMessage()和tabs.sendMessage()是規定了哪些JS實際上可以使用它們之間的區別？
• 消息如何傳遞？當調用*.sendMessage()或window.postMessage()時，後臺會發生什麼情況？

Answer 1

• 有四類的Javascript：(1) JS綁在彈出，(2) JS在後臺或作爲事件運行，在內容腳本(3) JS和JS (4)注入頁面。

(1)和(2)實際上是相同的（ 「彈出」 下的 「擴展碼」 也屬於 - 見）。

• (2) -> (1)和(3) -> (1)由runtime.sendMessage()發送。只有在彈出窗口打開時纔會收到它們。
• (1) -> (2)和(3) -> (2)分別由runtime.sendMessage()或tabs.sendMessage()從(3)和(1)發送。它們被儘快接收，因爲背景/事件JS是持久的（我不太確定這是否合適，因爲事件JS必須綁定到eventListeners中）。

runtime.sendMessage的確可以通過(1)，(2)和(3)發送。在接收者的角色中，(1)和(2)之間沒有特別的區別。這裏是my classification of scripts進來的地方：由chrome.runtime.sendMessage發送的消息被擴展代碼接收，除了發送者的幀。例如，如果您將放在後臺頁面中，並且從背景頁面調用chrome.runtime.sendMessage，則將在該幀中觸發chrome.runtime.onMessage。

當event pages正在使用中時，只有在等待事件頁面加載之後纔會調度消息事件。

• (1) -> (3)和(2) -> (3)由tabs.sendMessage()發送。它們被儘快接收，因爲只要網頁是內容腳本（因爲它存在於並行沙箱中），內容腳本就處於活動狀態。

chrome.tabs.sendMessage是有道理的，只要你有一個有效的標籤ID。由於背景頁面沒有標籤ID，因此無法使用tabs.sendMessage將消息發送到背景頁面。內容腳本，選項卡中的擴展頁面，選項卡中的擴展框架都可以接收由chrome.tabs.sendMessage發送的郵件，因爲它們是該選項卡的一部分。

• (*) -> (4)和(4) -> (*)不能被chrome.*的安全問題處理，但是(3) -> (4)和(4) -> (3)可以通過window.postMessage()，進行處理，因爲它們都在網頁的上下文中存在。

(4) -> (1,2)（網頁擴展碼）經由externally_connectable是可能的。

和(4) -> (4)也可能與window.postMessage，但不直接與*.sendMessage（因爲這不包括髮件人）。

• 究竟是runtime.sendMessage()和tabs.sendMessage()是規定了哪些JS實際上可以使用它們之間的區別？

tabs.sendMessage當將該翼片API可只能用，將消息發送到接片，而runtime.sendMessage還可以通過內容腳本中使用。

可以使用tabs.sendMessage發送消息到一個標籤，使用runtime.sendMessage發送消息到您的擴展的另一部分。

• 消息如何傳遞？當調用*.sendMessage()或window.postMessage()時，後臺會發生什麼情況？

• window.postMessage具有恰好一個接收器，即message event只調用一次。 *.sendMessage有零個或多個接收器（如果使用tabs.sendMessage，則可以通過設置frameId參數將其限制爲一個），因此可以多次調用chrome.runtime.onMessage（每幀一次）。

• 如果您不小心，可以通過window.postMessage意外地將信息泄露給不受信任的腳本。確保你在兩個方向驗證所有消息（從網頁到網頁） - 請參閱Window.postMessage#Security concerns article on MDN瞭解更多信息。 *.sendMessage只在您的擴展內傳遞消息，因此通常是安全的。

• *.sendMessage消息是JSON-serialized，它比postMessage所使用的structured cloning algorithm更受限制。

• *.sendMessage總是需要至少兩個IPC messages（發送者到瀏覽器進程，瀏覽器進程到每個接收者）。 postMessage可以更有效地處理，因爲消息是在同一個渲染器進程中處理的。
  這是一個內部實現細節，並不保證在未來。實際上，如果您發送大量數據並描述性能，那麼最有可能觀察到*.sendMessage比window.postMessage更多的問題（對於單向基準測試，請參閱Is there a size limit like 32bytes or 64Bytes? for message passing between content scripts and background pages for chrome extensions?）。

• *.sendMessage(any message, optional function responseCallback)在內部實現的東西，相當於 調用chrome.runtime.connect（或chrome.tabs.connect），使用port.onMessage.addListener註冊responseCallback然後斷開端口（立即如果沒有回調設置，回調被稱爲否則只有後）。

  window.postMessagequeues a message。隊列不會立即排空，但會盡快發送消息事件。