bige_1110170910_7079.png
推送的意义
「推送机制」为我们提供了一条可以「直接触达用户」的路径，使移动设备终端的「全时信息传播」成为可能，是C端运营人员提高用户活跃度、提高应用留存率的常规途径之一，以助于其「更高效地完成运营目标」。
推送的技术实现难点
自建推送通道
主流的推送方案实现，是由客户端和服务端建立一条TCP长连接通道，并由客户端定期向服务端发送心跳包，以保持长连接可用。服务端有消息要推送时，即可通过这个长连接通道直接下发到客户端。
Online(1).png
然而，要实现这样一套自建推送通道，却没有以上所描述的那样简单。且不说服务端需要应对海量长连接的维护管理，客户端自身也要妥善处理包括「网络的频繁变化」、「系统对内存/电量的限制」以及「移动网络运营商的NAT超时」等问题。
应用级的方案的开发成本太大，那么系统级的方案又能不能解决问题呢？
系统推送通道
iOS系统提供了APNs（Apple Push Notification service，Apple推送通知服务），负责接管「将推送消息路由到指定iOS设备上，进而传递给指定App」的工作，统一的方案，清晰的流程，没有什么好讲的。
Android系统虽然也提供了FCM（Firebase Cloud Messaging ，Firebase云消息传递），但是由于众所周知的原因，Google服务在国内并不能正常的访问，因此想要依赖FCM执行可靠的推送并不可行。
在这样的背景下，国内的手机厂商都陆续在其定制Android系统上搭建起自己的厂商推送通道，以弥补国内定制Android系统在系统推送通道这一块的缺陷。
但可能由于不同手机厂商建立消息推送通道的起步时间不一样，某些厂商在这方面的技术积累和实践比较少，导致不同厂商推送通道的推送消息到达率和及时率表现不一。
除此之外，每个厂商推送通道SDK的接入方式和调用API都不一样，需要单独去对接每个厂商，集成步骤也较为繁琐。
那么就真的没有办法了吗？
第三方推送平台
也正是由于推送功能是国内Android系统的一个痛点，因此才诞生了如今市面上形形色色的第三方推送平台。
虽然几乎所有的第三方推送平台的核心技术原理都别无二致，都是帮我们完成了上面所说的「自建推送通道」和「厂商推送通道对接」的工作，但确实让我们将更多的时间精力放在了能让App与众不同的方面上。对于大多数App来说，推送这种非核心功能的技术实现，完全可以交给第三方推送平台的专业团队帮我们完成。
那么，有哪些第三方推送平台可以让我们选择呢？
推送平台分类
纵观目前市面上主流的第三方推送平台，大致上可以分为两类：
一类是以推送业务起步，并专注于推送业务，以此为核心竞争力的，如：极光推送、个推等。
另一类是依托大厂建设的生态和技术积累，单独剥离出一个推送业务团队的，如：腾讯云推送(原信鸽)。
推送平台选型
以下是根据我从事过数年的IM开发、对接过多个第三方推送平台和厂商推送通道的经验所总结的一些技术选型的建议，仅供参考：
第一，术业有专攻
专精于某领域的平台相对会投入更多的开发资源，可能会比把该领域比作为多条业务线其中之一的大公司表现更好一点。
这个不难理解，虽然大厂有雄厚资本和技术实力为其背书，但是你可以想想，这些大厂的核心技术人员会被安排到哪里呢？固然会是其核心产品上面，比如百度的顶尖人才会集中在搜索引擎上(画外音：也可能是在竞价排名系统上。。。)。
但是也不能一概而论，关键还是得看团队在推送业务上投入的开发资源。这里有一个很好的参考标准就是：
SDK的更新频率和更新内容。
以某推送为例(为避免有打广告的嫌疑，此处隐去了具体名字)，通过查看其更新日志可知：
更新时间：
- 2021-10-28
- 2021-08-18
- 2021-07-26
- 2021-07-12
- 2021-07-02
- 2021-03-30
- 2021-02-25
- 2021-01-04
- ...
平均更新频率在一个月左右，并且都附上了详细的Change Log告知开发者更新内容。
ChangeLog.png
相反，对比查看某曾经推送巨头的更新日志：
ChangeLog2.png
what.jpg
其最近的更新频率比较高也许是因为《隐私法》的发布不得不更新，而之前几乎是平均4个月一更甚至年更，而且就更新内容来看都是些不痛不痒的东西，完全没看出有跟随Android系统版本迭代或突破性的技术升级，其技术投入的程度就不言自喻了。
第二，看市场占有率
早期的第三方推送平台广为人诟病的一点就是关联启动，即同一设备中，同时接入了该平台SDK的所有App，都会被一连串拉起，导致设备的内存和电量快速耗尽，这其实是跟平台自建推送通道的技术实现原理有关。
正如前面所说，使用自建推送通道进行消息推送的前提，是TCP长连接可用。为了最大限度保持这个长连接，平台SDK一般会选择一个当前设备中正在运行的App，由该App与平台的推送服务器建立TCP长连接，并为设备中同时接入了该平台SDK的所有App提供推送代理，所有App共享这一长连接通道。
当有消息需要推送时，即可通过该共享通道，将消息有效的下发到指定设备端，并将设备中指定的App拉起。更有甚者，在共享通道启动时，就已经扫描一遍设备上的其他应用并全部拉起了。
虽然作为用户我们厌恶这种行为，但是从开发的角度看，这种做法确实可以提高推送的到达率和及时率。所以，如果是为接入推送功能考虑，我们可以看有哪些知名的、安装率高的App接入了该平台，通常设备中接入该平台SDK的App越多，推送成功率相对也就越高。
不过，随着厂商推送通道的日渐完善，第三方推送平台提升推送到达率和及时率的技术权重也逐渐向厂商推送通道倾斜，通过自建推送通道成功完成推送的比例其实占比不大。具体的比例可以看看平台提供的数据统计，此项可以选择性考虑。
第三，看需求场景
也就是说，看你是注重「更高的推送到达成功率」、「更及时的推送速度」、「更丰富的推送点击行为」、「更灵活的推送用户分群」还是「更精确的推送数据统计」等，可以看不同平台官网提供的文档来评判符不符合你们的需求。
比如说，如果你做的是即时通讯App，那接入第三方推送平台大概率是为了覆盖离线场景下的消息推送，对于「更高的推送到达成功率」和「更及时的推送速度」的要求自然都要非常严格。
而如果你只是普通的App，那接入第三方推送平台大概率是为了推送营销的广告，对于「更及时的推送速度」其实要求不高，只需要「更高的推送到达成功率」，保证能送达到用户就好；除此以外，通常还需要「更灵活的推送用户分群」来进行针对特定人群的营销，以及「更精确的推送数据统计」来验证是否达到营销目的。
第四，看服务跟进
有在线技术客服能随时联系反馈问题，永远比只能提工单干等着好。推送平台说到底是服务提供方，把用户需求和用户体验置于工作流程之下是很不负责任的表现。
另外，平台解决问题的能力也很重要，合格的SDK提供方应该要比开发者更早地预见政策的变化和问题的产生（如本次《隐私法》的发布），并快速给出相应的解决方案，而不是后知后觉等到大量开发者反馈问题才着手改进。
最后才是看价格
在功能表现差异不大的情况下，自然是选择价格较低的一个。
创业团队通常对价格比较敏感，但其实比起糟糕的用户体验和后期替换方案的巨大成本，价格往往是应该考虑的因素中权重较低的。
结语
看完以上内容，相信你对如何选择第三方推送平台已经有了大致的一个思路了，如果你有更好的建议，欢迎在评论中补充。如果这篇文章对你有所帮助，不要忘记给一个赞哈！
网友评论