服务工作者与共享工作者

Service Worker和Shared Worker有什么区别？

什么时候应该使用Service Worker而不是Shared Worker,反之亦然？

服务工作者具有超出共享工作者可用功能的其他功能,并且一旦注册,它们将在给定网页的生命周期之外持续存在.

服务工作者可以响应message事件,例如共享工作者,但他们也可以访问其他事件.处理fetch事件允许服务工作者拦截任何网络流量(源自受控页面)并采取特定操作,包括从Request/ Response缓存提供响应.还计划向push服务工作者公开事件,允许Web应用程序在"后台"接收推送消息.

另一个主要区别与持久性有关.一旦服务工作者注册了特定的来源和范围,它就会无限期地保持注册状态.(如果底层脚本发生更改,服务工作者将自动更新,并且可以手动或以编程方式删除,但这是例外.)因为服务工作者是持久的,并且具有独立于Web浏览器中活动页面的生命它打开了诸如使用它们为上述推送消息传递提供动力的大门 - push只要浏览器正在运行,服务工作者就可以"醒来"并处理事件,无论哪个页面处于活动状态.未来的Web平台功能也可能会利用这种持久性.

还有其他技术差异,但从更高层次的角度来看,这些是突出的.

甲SharedWorker上下文是一个状态的会话,并且被设计来复用的网页到经由异步消息(客户机/服务器模式)的单个应用程序.它的生命周期是基于域的,而不是像DedicatedWorker(双层范例)这样的单页面.

一个ServiceWorker方面的设计是无状态的.它实际上根本不是持久会话 - 它是控制反转(IoC)或基于事件的持久性服务范例.它提供活动,而不是会议.

一个目的是为数据库和其他持久性服务(即云)的长期运行查询(LRQ)提供并发安全异步事件.正是线程池在其他语言中的作用.

例如,如果您的Web应用程序为各种云服务执行许多并发安全LRQ以填充自身,那么ServiceWorkers就是您想要的.您可以立即执行数十个安全LRQ,而不会阻止用户体验.SharedWorkers和DedicatedWorkers不能轻易处理许多并发安全LRQ.此外,某些浏览器不支持SharedWorkers.

也许他们应该称之为ServiceWorkers:为了清晰起见,CloudWorkers,但并非所有服务都是云.

希望这个解释可以引导您思考各种工作者类型如何设计为一起工作.每个都有自己的专业化,但共同的目标是减少DOM延迟并改善基于Web的应用程序的用户体验.

在一些WebSockets中输入推送通知和WebGL图形,你可以构建一些像多人游戏机游戏一样的吸烟热门网络应用程序.