我正在开始规范一个项目来实现浏览器通知。从高层次上看，它似乎类似于：
- 创建订阅 pubsub 主题的服务工作进程。
- 利用通知 API 和 WindowClient 在事件发生且窗口处于非前台状态时发布浏览器通知。
看起来，足够直截了当。但是，从移动的角度来看，我有点挂断了。也就是说，这似乎是典型的模式，如果移动设备同时打开了移动网站并安装了应用程序，则本机通知应优先，浏览器通知应静音。
但是，我似乎无法弄清楚服务工作者将如何检查移动应用程序是否存在。不过，我完全有可能从错误的角度处理这个问题，并且典型的方法处理方式不同。
布伦特，IIUC 您的问题不是问题，因为W3C Push API或IETF网络推送协议根本不支持基于主题的订阅。恐怕这是设计使然：-(
因此，您的本机应用将不会传递与浏览器 UA 相同的广播消息。
如果 OTOH 您谈论的是保存到主屏幕 WebApp 和在选项卡中运行的网页，那么我相信，您的服务工作者可以选择活动客户端集合的哪个成员进行前台(如有必要)，但只有一个 Toast 消息(如果给定管理盲目/不可见通知的规则)