0

我正在开发一个 Chrome 扩展程序，该扩展程序旨在检查用户导航到的任何网页的内容，然后提醒用户该内容的某些“功能”。（也许最容易想到的是在网页的文本数据中搜索大量字符串，尽管这是一个相当大的简化。）按照设计，有一个非常大的集合（数千万）扩展程序检测到并因此可以做出反应的功能。每个这样的特性都可以表示为一个 JS 数字（8 个字节），因此数据总量可能在 100 MB 左右，甚至更多。

该数据可以存储在 IndexedDB 中，但是为了能够快速分析页面数据（由内容脚本发送），后台页面脚本（MV2 中）或服务工作者（MV3 中）确实需要具有这些功能（其中被检查）存储在 RAM 中，以便能够从网页中快速检查小得多但仍然大量的特征，以查看其中是否存在于其自己的数据集中。

这个设置实际上在我创建的原型清单版本 2 (MV2) 扩展中运行良好。后台脚本将首先从 IndexedDB 中获取数据并将其放入 RAM 中的结构中。这在我的笔记本电脑上需要一些时间（几秒钟，我没有精确的数字），但只需要在浏览器启动时完成一次。之后，后台脚本能够快速响应来自内容脚本的请求以检查网页内容。

现在，试图过渡到 manifest 版本 3 (MV3)，问题是服务工作者不是持久的，甚至不是特别长寿。因此，每次重新启动时，直接翻译都会让服务工作者从 IndexedDB 到 RAM 进行昂贵且缓慢的加载。这显然不是一个有效的设置。

那么显而易见的问题是：有什么方法可以避免 Chrome 停止服务工作者（从而让扩展服务工作者持续很长时间）？如果没有，是否有某种方式可以让 RAM 中的数据保留下来，并且服务人员在启动时获取对它的访问权限？（我远不是 Chrome 扩展和服务工作者方面的专家，所以如果我的问题很幼稚，我深表歉意。）我阅读了一些讨论，这些讨论似乎表明上述任何一种方式目前都不可能，但如果是这样，它基本上会让整个概念在 MV3 下是非首发。有什么解决方法吗？（如果是，这些变通办法在 Chrome 网上应用店审核过程中是否可接受？）

我将非常感谢任何指示！

4

1 回答 1

0

我遇到过类似的情况，其中扩展基于以 p2p 方式共享的 CRDT 仅附加日志。如果添加重复或不必要的数据，此日志将变得太大。

第一个设计

我最初想要一个后台脚本，将日志保存在内存中，并且内容脚本在遇到感兴趣的事情时通知后台脚本。这样，后台脚本可以将新信息与日志中已有的信息进行比较，并决定是否添加/更新信息。我查看了 keep-alive解决方法，并对 Chrome 网上应用店的审核流程有类似的保留意见。

MV3 设计

为了避免内存中的 MV2 架构，我更新了设计以使用更多的存储和处理能力而不是内存。内容脚本只是将通常发送到后台脚本的任何内容写入 localStorage。当 service worker 唤醒它时：

  1. 将整个日志读入内存
  2. 读取内容脚本记录的所有项目
  3. 执行与从内容脚本接收消息时相同的逻辑

上面的设计确实使用更多的存储来存储内容脚本遇到的所有内容。它还必须在运行时将整个日志读入内存。它确实避免了 100% 的时间连接内存。

这种架构让我想起了在 Android 或 iOS 中开发移动应用程序时所做的权衡，除了极少数情况外，您的任务可能随时存档。MV3 确实需要添加类似于 Android 的AcquireWakeLock()的东西，但我不会屏住呼吸，这很快就会发生。

于 2021-12-23T19:42:52.933 回答