Chrome 扩展性能差异 - 警报 + 历史 vs 存储 + 历史

Question

我的扩展程序（清单 v3）需要跟踪一组网站在一整天或特定时间内的访问次数 windows，然后在访问次数超过限制时执行操作.

我可以想到两种实现方法：

1. alarm + history：创建每5分钟运行一次的警报，搜索所需网站的历史记录并统计访问次数。如果计数超过限制执行操作
2. storage + history: 添加监听器到chrome.history.onVisited。如果访问的站点来自所需列表，则在 storage 中增加访问计数。如果存储计数超过限制，则执行操作

以上哪种方法对 Chrome 的浏览性能影响最小？或者，我可以使用其他 api(s) 来达到同样的目的吗？
我希望我的扩展程序消耗最少的用户电池 :)

Answer 1

在 1 中，当用户不使用浏览器时，扩展程序会做很多不必要的工作。

在 2 中，如果用户导航很多但在导航之间暂停超过 service worker 的生命周期（默认为 30 秒），这是典型的交互场景，则扩展的后台脚本将更频繁地重新启动。

在这两种情况下，对于观察用户 activity 的扩展，ManifestV3 更大的固有问题不是扩展本身，而是重启后台工作程序的巨大开销，这是自动的自上次观察到的事件 30 秒后终止（如果使用 ，则为 5 分钟）。用户 activity 中的这种暂停在 browsing/interacting 中很典型，因此对于许多用户来说，worker 每天将重启数百次。启动 worker 需要 50-100 毫秒，并在整个持续时间内对 CPU+内存+磁盘施加压力，而在简单观察扩展代码中花费的典型时间仅为 1-2 毫秒。

换句话说，观察用户 activity 的扩展程序在 ManifestV3 中的效率本质上比在具有持久后台脚本的 ManifestV2 中低 25-100 倍。

解决方案。

1. 延长 Service Worker 的生命周期以减少其重启次数，如图所示 。为了避免让浏览器保持打开状态而不使用它几个小时的用户浪费内存，您可以通过测量和平均事件之间的间隔来动态调整生命周期持续时间，或者提供一个选项来设置扩展中的持续时间 UI。希望将来浏览器会自动执行此操作，但可能需要数年时间才能真正实现此功能，即使那样它仍然可能会过于频繁地重新启动后台脚本。
2. 为您的网站使用 chrome.webNavigation 事件和 URL 过滤器，以便仅在访问这些特定 URL 时才唤醒后台脚本。如果 URL 是由用户配置的，您需要先取消注册监听器（例如，通过使监听器成为一个命名的全局函数），然后使用新的 URL 过滤器注册它。如果经常访问这些 URL，您可能仍然需要延长 worker 的生命周期。