创建 chrome 扩展时，API 调用应该从后台脚本还是前端进行？

Question

我正在创建一个 chrome 扩展，每当加载新页面时都需要调用 HTTP Get Request API。然后，我的扩展程序在网页中插入一个 IFrame，我想向其提供来自 API 调用的数据。我设计了两种不同的方法来做到这一点。我已经能够获得两种工作方式，但是，我想知道哪种方式更可取。在内容脚本注入 iframe 后，它会调用后台脚本。在后台脚本中，我们获取数据并使用postMessage函数进行消息传递以将数据发送到 IFrame。然后数据由 IFrame 内的脚本接收并加载数据。在内容脚本注入 iframe 后，一个脚本会在 IFrame 内运行以获取数据。然后这个相同的脚本加载数据。或者如果有任何其他方法，我将不胜感激任何建议。我现在比较我描述的两种方法的逻辑是，第一种方法具有从 backgorund 脚本执行 API 调用的优点，而第二种方法具有不需要在各种脚本之间进行大量通信的优点。这些方法中的任何一种都优越吗？谢谢你的建议。

Answer 1

任何具有chrome-extension://URL 的扩展页面或框架都具有同等权利。它包括您在网页中插入的 iframe，这些 iframesrc指向通过manifest.json 中的web_accessible_resources公开的扩展程序中的 html 文件。

这意味着没有固有的限制或首选方法。
它只取决于数据的生命周期。

在后台页面发出请求什么时候有意义：

• 如果您出于某种原因有一个持久的背景页面，则将其缓存在变量/对象中；

• 避免由于用户或主文档的脚本关闭或导航选项卡而中断请求；

• 使用您在后台脚本中加载的某个库转换数据，并且出于某种原因不想将其加载到 UI 页面/框架中，例如加载速度慢。

• 任何其他原因。

至于页面之间的共享，即使使用消息传递也应该很快，除非您的数据超过 64MB 消息大小限制，在这种情况下，您必须使用URL 或通过返回后台脚本对象的getBackgroundPageBlob直接访问变量。还有一个BroadcastChannel API，它应该能够在所有 chrome-extension:// 页面或扩展的框架之间工作，并且在 Chrome 中，由于使用结构化克隆算法而不是消息传递使用的 JSON 字符串化/解析，它应该比消息传递快得多内部。window

作为任何与性能相关的问题的经验法则：使用 devtools 性能分析器。