服务工作者（或类似人员）内部的长时间运行的流程

Question

我有一个客户端JS应用程序，它使用IndexedDB来存储其状态。很好。但是，它有点慢，因为我经常从IndexedDB读写，这样当多个选项卡打开时，状态就不会变得不一致。

我的想法是。。。将所有DB access内容放在一个Service Worker中，然后我可以将值缓存在内存中，而不用担心另一个选项卡可能会更改数据库。

这似乎很好，只是我的应用程序的某些部分需要很长时间才能运行。我可以将状态（如“X%完成”）从服务人员传递到我的UI。但是，如果Firefox和Chrome运行超过30秒，它似乎都会杀死这个工人，这对我来说太短了。

有没有办法绕过这个限制？如果没有，有没有实现类似目标的想法？我认为共享工作者可以做到这一点，除了浏览器支持很差，我不认为现在服务工作者的势头会有所改善。

Answer 1

正如你所说，你需要的正是共享工作。我不知道你为什么认为实现ServiceWorkers背后的动力阻止浏览器支持SharedWorkers。他们似乎是两种不同的野兽。

据我所知，当您的应用程序脱机时，ServiceWorkers应该用作您请求的代理，繁重的工作应该在WebWorkers和SharedWorkers中完成

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker

Answer 2

我最终使用了一个共享的Worker。在不支持共享Worker的浏览器中，如Edge和Safari，我求助于Web Worker和一些黑客代码，让您一次只在一个选项卡中打开应用程序。

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

我还编写了一个库（除其他外）来规范共享worker和Web worker中使用的API，因此在这两种场景中运行的代码完全相同，唯一的区别是worker是用worker还是SharedWorker初始化的。

Answer 3

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

它在不使用时终止，在下次需要时重新启动，因此您不能依赖服务工作者的onfetch和onmessage处理程序中的全局状态。如果您需要在重启过程中保留和重用信息，那么服务人员确实可以访问IndexedDB API。

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