浏览器通知推送服务选型

浏览器通知推送服务选型

背景

最近由于项目中有提升用户使用体验的需求,所以有必要引入浏览器通知。

虽然以前就已经知道有浏览器通知这个玩意,但还是第一次正式在项目中应用,深入了解后发现如果要接入到项目里,还是有一定的困难的。

这其中最关键的一环就是如何根据项目现有情况,选择一个最适合我们的推送服务。

所以本文就来对比分析一下几个比较有代表性的推送服务各自的优劣,希望能帮助读者更好地选择适合自己的推送服务。

推送通知 API

在开始之前有必要先介绍一下相关知识,主要是介绍一下 Notification API、Push API、以及推送的整个流程。

如果你对上面提到的信息都有一定了解,可以直接跳到结论。

浏览器通知相关的 API 主要有两个:

  • Notification API
    • 可以在客户端给用户推送消息,但前提是必须打开页面。


  • Push API
    • 可以在服务端向用户推送消息,即便应用不处于活动状态。
    • 即便没有打开浏览器,也会在下次打开浏览器的时候推送消息。


当然这一切的前提是用户已经允许该站点的通知权限。

关于这两个 API 的更多技术细节可以参考这篇文章:Introduction to Push Notifications

推送流程

从上面的介绍我们可以看出,仅靠 Notification API 起不到多大的作用,还需配合 Push API 使用。

不过两者的功能设计本来就是互补的,Push API 是用于订阅并推送消息给 Service Worker,而 Notification API 用于从 Service Worker 发送消息给用户。

一个完整的 Web Push 流程,只有浏览器是不够的,还需要服务端发送消息。

下图所示的流程图出自 Web Push 协议草案,展示了网络推送实现的整个基本流程:

从上图可以看出,要实现一个完整的推送流程,需要有三个角色:

  • UA:用户的浏览器
  • Push Service:推送服务器,用于管理推送订阅、消息推送等功能的第三方服务器,这个是由浏览器决定的:
    • Chrome / Edge(Base on Chromium):FCM
    • Firefox:Mozilla Push Service(autopush)
    • Safari:APNs
    • 这里说的都是 PC 平台,但其实在不同的平台上,使用的推送服务也会不同,需要了解请自行查阅


  • Application Server:即网站应用的后端服务


关于这个流程图的详细讲解可以参考这篇文章:网络推送

选择哪个服务?

补充完前置知识,终于来到本篇文章的核心要点,选择合适我们的推送服务。

推送服务主要分为两个阵营:

  1. 直接使用浏览器内置的推送服务(FCM、autopush、APNs)
  2. 使用第三方的推送服务,但本质上还是利用桥接和托管形式来使用浏览器内置的推送服务。

这两者有什么区别呢?区别主要在于:如果使用 FCM 等官方内置的推送服务,你可能需要为此编写更多的代码来接入;而使用第三方推送服务则可以更轻松地接入,除此之外第三方还可以提供更多很方便的功能,如:分组推送、多语言等,当然第三方难免也会有它的问题,比如收费、数据隐私等。

本次对比分析主要针对以下三个服务:

  1. FCM:Chrome 内置推送服务
  2. Webpushr:新兴第三方推送服务
  3. OneSignal:老牌第三方推送服务

当然推送服务远不止这些,我只是挑出三个比较具有代表性的,而且从这三个服务也能横向对比出其他服务的优劣。

结论

  1. FCM:如果你不想用第三方服务,并且有足够的精力来接入,推荐直接使用浏览器内置的推送服务。
  2. Webpushr:如果你用户量大、不是很在意社区生态,那么可以尝试一下这个。
  3. Onesignal:如果你用户量少、想快速上手,那还是优先考虑这个。

而我们最终的选择是 OneSignal,原因在于:OneSignal 在 Nuxt 已经有集成模块、社区用户群体也比较大,可以很方便地接入,从而减轻很多开发工作,同时由于 30k 订阅用户数以内免费,所以不需要考虑收费问题。

方案一:FCM

Firebase云消息传递(英语:Firebase Cloud Messaging,通常简称FCM),也称Firebase云信息传递,前身为Google云消息传递(GCM),是一项针对Android、iOS及网络应用程序的消息与通知的跨平台解决方案,目前可免费使用。

使用 FCM,你需要编写代码来实现你所需要的功能,对于大型项目,这确实是一个更灵活、更稳妥的方式,但如果对于一个小型项目,这成本相对来说就有点高。

优点:

  • 完全免费
  • 网上有很多相关文档,踩坑记录

缺点:

  • 需要编写所有的代码
  • 请求 API 需要科学上网

方案二:Webpushr

Webpushr 是营销人员喜欢和开发人员依赖的增长最快的 Web 推送通知平台。支持所有流行的浏览器。

它作为一个新兴的推送服务,功能非常全面,并且有各大平台的集成(如 WordPress、WooCommerce、Zapier 等),同时保证 60k 用户以下将可以持续免费地使用所有特性。

它还承诺:完全透明且易于理解的数据保护和隐私政策,与广告和数据经纪公司没有任何当前或以前的关联/合作关系。

看到这个宣传语,让我确实对这个服务商很感兴趣,然而却没有在网上找到有太多的使用者,社区的讨论也寥寥无几,可能还需要再观望一段时间。

如果你是应用于个人项目,那么不妨尝试一下。

优点:

  • 60k 订阅用户以内免费
  • 使用简单,无需编写过多代码
  • 请求 API 无需科学上网

缺点:

  • 没生态,网上找不到太多使用者

方案三:OneSignal

OneSignal 是客户参与的市场领导者,支持移动+网络推送、电子邮件和应用内消息。

这个相信大部分人都知道,已经是行业比较有名的推送服务了。

它的情况是这样的:30k 订阅用户以内免费,同时具有跨平台的功能,基本能够涵盖你的需求。

它是支持主流的浏览器的,但是 Safari 需要做一些额外的配置。

好处:

  • 30k 订阅以内免费
  • 生态好,行业比较有名,Nuxt 有相关模块
  • 无需科学上网

缺点:

  • 兼容 Safari 需要做额外操作
  • 免费额度比 Webpushr 低

由于最终我们选择了该服务,这里说一下接入后发现浏览器兼容问题

  • 支持的浏览器:
    • Chrome
    • Edge(Base on Chromium)
  • 不支持的浏览器:
    • Firefox:在最新版(82.0 64 位)中即便允许推送也会被自动拦截,导致无法订阅 OneSignal ,报错信息:
      • DOMException: user denied permission to use the push api.
      • DOMException: Error retrieving push subscription.
      • 当然这个应该是 Firefox 本身的问题,可能跟 OneSignal 关系不大

写在最后

其实根本没有最好的服务,只有最适合你的服务,希望本文能让你对浏览器通知推送有初步的了解,并且下次有遇到需要接入浏览器推送的情况,也能从容地选择出适合的方案。

当然本文只针对最核心的优缺点进行对比分析,如果需要进行更仔细的参数分析,这里推荐两个网站:stacksharecapterra

另外由于篇幅有限,其实还有很多服务商没有列出来,如果在座读者有使用过其他服务,也不妨在评论区说说你的使用感受。

扩展阅读

编辑于 10-27

文章被以下专栏收录