第三方推送已死

xiguadada 发布于2019-06-25 10:52 / 2877人阅读

摘要：所以，如果推送服务商还在使用以往相互拉起的技术手段，那么我们可以断言，第三方推送已经在走向死亡。云巴近期推出了一键集成小米华为推送的功能，方便开发者快速集成厂商的推送服务。

国内第三方推送的起源

2010 年左右，Android 手机在国内迅速发展，Google 的原生推送（C2DM，现在的 GCM）由于种种原因不能正常使用，当时的 Android 开发者使用各种办法来解决这个问题，其中就包括 Android 手机厂商开发出自己的推送方案。

对于大部分开发者来说，除了做一个 App，还要独立开发一套推送系统是件异常困难的事情。哪怕是用户数量很大的 App ，这也不是一件容易的事情。于是在 2011 年底，我产生了做独立第三方推送服务的想法，也就有了后来的极光推送。

推送消息能送达的关键

这几年经常有业内的朋友探讨推送能否送达的关键因素。其实最重要的是 SDK 能否保活。

具体地说，有以下两方面：

SDK 如果不能及时地发起心跳，运营商网络的长连接会被断开。

SDK 的任务如果被杀掉了，不能被拉起，消息就完全没有机会下发。

参考之前的文章：《推送技术原理》 http://zhang.hu/mobile-push/

如果 SDK 端不能有效地保活，那么无论服务器端怎么优化，都不能保证消息及时地送达。

对 Android 手机厂商来说，这里有一个矛盾的问题。手机厂商都希望自己出产的手机能有尽量长的待机时间，但是 App 定时在后台启动、维持心跳的行为，会极大地影响手机待机时间。

因此，最近几年，手机厂商为了控制后台服务，持续地推出各种限制手段。比如之前的心跳对齐，也就是不允许 App 任意使用 RTC 后台唤醒手机。还有更严厉的手段，就是定时清理所有后台服务，并且不允许服务通过监听广播自动拉起。

第三方推送已死

正如前文所提到的，最近主流的 Android 手机都会清理后台服务，禁止服务自动拉起，以前各种 SDK 保活手段相继失效，这个问题从根本上动摇了 Android 第三方推送服务的基础，导致几乎所有的 Android 第三方推送服务都不能保证送达。

所以，如果推送服务商还在使用以往相互拉起的技术手段，那么我们可以断言，第三方推送已经在走向死亡。

面对这样的问题，App 开发者该如何应对？

更合理的方案

因为推送服务的特点，它最应该以系统原生服务的形态存在。在 iOS/Android 系统推出的早期，都考虑到了这个问题，iOS 有 APNs，Android 有 C2DM（GCM）。可惜的是，Android 的 GCM 在国内早已不能被有效使用，而 Android 方面没有试图解决这个问题，而把问题留给了手机厂商和 App 开发者。

考虑到推送服务的特点，我们自然而然就想到了通过厂商的推送通道来解决这个问题，就像在 iOS 上使用 APNs 一样。使用 App 内的消息通道发消息给 App，再通过厂商的推送通道唤醒 App，App 被打开后，接受消息通道的离线消息。

从目前的实践情况来看，这是解决后台进程被清理的最有效办法。

国内 Android 厂商推送通道现状

目前国内几个主要的 Android 厂商中，小米、华为都有提供官方的推送服务。经过我们团队的验证，他们的推送服务在自己品牌的手机上，有相对稳定的送达率。目前表现最好的是小米，华为的推送延迟有时比较大，也不太稳定。

而另外的几家 OPPO、VIVO、金立都没有官方的推送服务。

云巴近期推出了一键集成小米、华为推送的功能，方便开发者快速集成厂商的推送服务。但是对于没有提供推送服务的厂商，目前还没有特别好的办法。我们期待各主流手机厂商为了 App 有更好的体验，都能提供解决这个问题的方案。

文章作者：@Tiger_张虎，云巴 (yunba.io) 创始人，yunba.io 云端实时消息服务。 JPush 创始人，原CTO。 Oracle VM 创始团队成员。

云服务器专线服务短信推送手机推送推送端口推送服务

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/13328.html

第三方推送已死

摘要：所以，如果推送服务商还在使用以往相互拉起的技术手段，那么我们可以断言，第三方推送已经在走向死亡。云巴近期推出了一键集成小米华为推送的功能，方便开发者快速集成厂商的推送服务。国内第三方推送的起源 2010 年左右，Android 手机在国内迅速发展，Google 的原生推送（C2DM，现在的 GCM）由于种种原因不能正常使用，当时的 Android 开发者使用各种办法来解决这个问题，其...

whinc 2019-06-25 15:47 评论0 收藏0
传统 Ajax 已死，Fetch 永生

摘要：结果证明，对于以上浏览器，在生产环境使用是可行的。后面可以跟对象，表示等待才会继续向下执行，如果被或抛出异常则会被外面的捕获。，，都是现在和未来解决异步的标准做法，可以完美搭配使用。这也是使用标准一大好处。只允许外部传入成功或失败后的回调。 showImg(https://cloud.githubusercontent.com/assets/948896/10188666/bc9a53...

fai1017 2019-08-21 10:41 评论0 收藏0
下一代防火墙（NGFW）已死！

摘要：不妨把丑话说在前头下一代防火墙已死，而死因是云。由防火墙入侵预防系统和代理合并而来，成为了安全界的瑞士军刀。这将进一步侵蚀传统的价值。这造成了一种有害的文化安全人员被赋予重大的责任，却毫无实际行使这一责任的权力。死亡才会带来变化。不妨把丑话说在前头：下一代防火墙（NGFW）已死，而死因是云。　　然而，这不是立即处死，而是面对一个更敏捷的竞争对手，慢慢变得无关紧要。如今NGFW产品弥漫着死亡和...

Tecode 2022-06-28 18:59 评论0 收藏0
春阳：SaaS已死，下一个

摘要：中国的是一个阴谋让我们首先回到的初衷。春阳曾经分享过的藏宝图报告里有过一个关于家厂商毛利水平的统计，如下图所示，其中位数是。每一年，都会有人问我，春阳，你觉得SaaS行业到时候了吗？每一年，都会有媒体发文，SaaS已来，未来可期．．．．是的，每一年．．．行业的媒体人喜欢给SaaS灌鸡汤是没有毛病的，本身这就是个留不住人才、熬不出日子的行业，如果我们再看衰它，媒体本身也是活不下去了…对这个问题...

rainyang 2019-04-30 14:34 评论0 收藏0
中国SaaS死或生之四：卧榻之侧，是谁在捅刀 SaaS？

摘要：在死或生系列文章的第一阶段，我们分别从的细分领域和进行了阐述，指出目前国内普遍存在缺心的弊病。说起来，从国内第一批效仿者成立算起来，在中国也已经走过了十余载光阴。在《SaaS 死或生》系列文章的第一阶段，我们分别从 SaaS 的细分领域 CRM、ERP 和 SCM 进行了阐述，指出目前国内 SaaS 普遍存在「缺心」的弊病。在这里，我们想说的是，缺不可怕，知道怎么补才是关键。承接着第一阶段，...

mingzhong 2019-04-30 14:35 评论0 收藏0