PWA资料整理（三）：Service Worker 消息推送

最新推荐文章于 2024-09-11 15:34:14 发布

草半

最新推荐文章于 2024-09-11 15:34:14 发布

阅读量1.5k

点赞数 1

分类专栏：前端杂物筐文章标签： PWA

本文链接：https://blog.csdn.net/qq_35368183/article/details/82965993

版权

本文作为PWA系列的第三篇，详细介绍了利用Service Worker实现消息推送的原理和流程。内容包括消息推送的整体架构，通过Push Service进行消息传递的机制，以及客户端的订阅和消息接收过程。此外，还提到了安全性和SW在浏览器关闭时无法接收消息的限制。

摘要由CSDN通过智能技术生成

本篇是 PWA 资料整理的第三篇，主要介绍 Service Worker 所实现的消息推送相关内容。

系列链接

Manifest 添加到桌面
Service Worker 离线缓存
Service Worker 消息推送（本篇）

消息推送

说到消息推送就想到 HTTP2 push。实际上 HTTP2 push 就是一个缓存相关的机制，与消息推送没有关联。
拓展资料：Http/2 push is tougher than I thought（我之前的博客中也有对该文章的阅读理解，如果懒得看英文原文的话可以直接看我的内容概括）。

事实上，同 SW 实现的消息推送一样，SW 本身仅仅是提供类似 Web Worker 的功能，需要结合 cache api 才能实现离线缓存功能。使用 SW 实现消息推送需结合 notification api，具体功能就不介绍，可以查看 MDN 文档。

消息推送整体架构

消息推送看起来似乎很简单，就是服务端给客户端发送消息这样简单粗暴的东西嘛，其实并不是。
实际上，服务端无法直接给客户端发送消息，而必须借助 Push Service 进行消息的推送。Webpush 的整体架构如下图所示：
Webpush 架构
这里的 UA 即 user agent，也就是用户代理；Application Server 为应用的服务端；Push Service 也就是推送服务，指的是 google 的 fcm (以前叫 gcm)，或者 apple 的 APNs（苹果现在还不支持 webpush）等。

消息推送具体流程

在使用消息推送之前，客户端需要通过 SW 进行消息订阅：

同样是在注册 service worker 时，先通过 pushManager.getSubscription方法获取当前客户端是否已经订阅过了，没有订阅则需要对推送订阅对象进行生成；
在向 push server 发送请求（pushManager.subsribe）之前，浏览器已经生成了一个推送订阅对象；
得到响应之后，客户端会将推送服务生成的地址（end point）加入这个推送订阅对象中；