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

Question

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

我的想法是......将所有数据库访问内容放入Service Worker中，然后我可以在内存中缓存值，而不必担心其他选项卡可能会更改数据库。

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

有没有办法解决这个限制？如果没有，任何实现类似的想法？我认为共享工作者可以做到这一点，除了浏览器支持很差，我现在预计服务工作者背后的势头不会改善。

Answer 1

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

  

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

我的建议是继续使用服务工作者将数据保存到数据库，并使用localStorage创建shared cache between pages。然后，进行更改的选项卡负责更新localStorage中的缓存并通过服务工作者持久保存到IndexedDB。

Answer 2

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

由于我的用户中有90％使用的是Firefox或Chrome，我认为这并不是一个巨大的损失。

我还wrote a library（除其他外）规范化共享工作者和Web工作者中使用的API，因此我在两种情况下都运行完全相同的代码，唯一的区别是工作者是否使用{初始化{1}}或Worker。

Answer 3

正如你所说，SharedWorkers似乎正是你所需要的。 我不确定为什么你认为实施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