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。队列不会立即排空，但会尽快发送消息事件。