服务工作者,我想用我的网站上两个服务人员:一个为我的PWA的经典脱机缓存(/sw.js
)和其他类似的东西,它使用背景的本地数据库“服务器”同步和推送(/sw-db.js
)。由于后者往往要做大量的工作(阻塞事件循环几ms),最好将它分开。两个在同一时间
由于数据库sw不用于提取请求,我会给它一个虚拟范围,而sw.js
是作用于整个域的。
做的第一,这是为了响应“取”事件,也有助于代码/ URL为/sw-db.js
(保持它在同步与网站的更新有点),或者是服务人员总是通过网络更新。
服务工作者,我想用我的网站上两个服务人员:一个为我的PWA的经典脱机缓存(/sw.js
)和其他类似的东西,它使用背景的本地数据库“服务器”同步和推送(/sw-db.js
)。由于后者往往要做大量的工作(阻塞事件循环几ms),最好将它分开。两个在同一时间
由于数据库sw不用于提取请求,我会给它一个虚拟范围,而sw.js
是作用于整个域的。
做的第一,这是为了响应“取”事件,也有助于代码/ URL为/sw-db.js
(保持它在同步与网站的更新有点),或者是服务人员总是通过网络更新。
当您检查更新时,您传递到navigatior.serviceWorker.register('/path/to/sw.js')
的sw.js
脚本URL将始终绕过其他服务人员而被抓取。因此,要回答您的问题,其他服务人员的fetch
处理程序将不会被触发。
只要有一个服务人员脚本更新检查的HTTP cache does come into play。所以你应该确保你为你的用例设置了正确的HTTP缓存控制头。
通常,服务工作者更新检查由于导航到由服务工作人员控制的页面而被触发,但如果服务工作人员使用“虚拟”范围,则最终不会控制任何页面。也就是说,当服务工作人员处理程序sync
或push
事件时,您最终还会触发更新检查。我不确定每个sync
或push
是否会触发检查,或者只检查其中的一部分,例如导致新服务人员产卵的检查。但至少在某些时候会发生。