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 回答