服务工作者内部长时间运行的过程(或类似的东西)

Question

我有一个客户端JS应用程序,它使用IndexedDB来存储其状态.工作良好.但是,它有点慢,因为我经常读取和写入IndexedDB,以便在打开多个选项卡时状态不会变得不一致.

我的想法是......将所有数据库访问内容放入Service Worker中,然后我可以在内存中缓存值,而不必担心另一个选项卡可能已经更改了数据库.

这似乎工作正常,除了我的应用程序的某些部分需要很长时间才能运行.我可以将服务工作者的状态(例如"X%done")传达给我的UI.但是如果它运行超过30秒,Firefox和Chrome似乎都会杀死它,这对我来说太短了.

这种限制有什么办法吗？如果没有,任何实现类似的想法？我认为共享工作者可以做到这一点,除了浏览器支持很差,我现在预计服务工作者背后的动力不会改善.

Answer 1

谷歌关于服务工作者的文档告诉我们，使用服务工作者作为内存缓存是不可能的：

它在不使用时终止，并在下一次需要时重新启动，因此您不能依赖 Service Worker 的 onfetch 和 onmessage 处理程序中的全局状态。如果您需要在重启后保留和重用某些信息，Service Worker 确实可以访问 IndexedDB API。

我的建议是继续使用 service worker 将数据持久化到数据库，并使用 localStorage在页面之间创建共享缓存。然后，进行更改的选项卡负责更新 localStorage 中的缓存并通过 Service Worker 持久化到 IndexedDB。

Answer 2

我最终使用了共享工作者。在不支持 Shared Workers 的浏览器（例如 Edge 和 Safari）中，我会使用 Web Worker 和一些 hacky 代码，只允许您一次在一个选项卡中打开应用程序。

由于我 90% 的用户都使用 Firefox 或 Chrome，所以我认为这并不是一个巨大的损失。

我还编写了一个库来（除其他外）标准化 Shared Workers 和 Web Workers 中使用的 API，因此我在这两种情况下运行完全相同的代码，唯一的区别是工作程序是否使用 或 进行Worker初始化SharedWorker。