聊聊即时通讯开发中Android消息推送

Posted 2022-09-07 wecloud1314

我们在讨论 android 手机上的推送时，大多数情况是在说集成第三方推送，因为即使是像微信这样的大厂，也需要厂商加到启动白名单里才能保持在线。

这样一来，国产手机的推送就成了个问题，也带了机会。

 

推送的实现方式

总结一下几种推送实现方式，其中有些我们只要了解即可，因为属于历史解决方案，现在已经被废弃掉了。

轮询

客户端定期询问服务器有没有新的消息，这种方式最大的缺点就是性能和实时性的矛盾，轮询时间过长和过短都不好。

短信

这种方式还没出生就不被允许了，首先运营商不会配合，其次拦截手机短信本身就是一个高危权限，大多数用户不会买单。

长连

目前最通用的方案，客户端与服务端建立 TCP 长连，定时发送心跳包保活，有新消息时服务端通过该长连通道进行推送。

这里再简单说明一下长连和心跳包。长连接就是建立连接之后，双方互相发送数据,，发完了也不主动断开连接。

但是在某些情况下长连会断开，问题就在断开这件事上，而且这件事必须是由客户端知道，因为客户端是可以重连服务器的，服务器却没法再联系上客户端。这样才确定了心跳包必须由客户端发给服务器。所以心跳包的作用就是告诉服务端客户端还活着，如果服务端挂了，客户端能知道，所以保活说的是保持两边都活着。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

上面说的某些情况中， NAT 超时算是一个典型的例子。因为 IPv4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet ，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。所以长连接心跳间隔必须要小于 NAT 超时时间（aging-time），如果超过老化时间不做心跳， TCP 长连接链路就会中断，服务器就无法发消息给客户端，只能等到客户端下次心跳失败后，重建连接才能取到消息。

有了长连，即使在休眠模式下，有推送消息过来，也能唤醒 Android 系统，这是由系统机制决定的，我们这里只要知道结论就好。

推送的指标

在接入推送服务时有几个核心指标需要考量。

在线率

在线率 = 在线用户数 / 总用户数。

推送服务后台保持在线的方法：

    Push 进程常驻后台，需要用户手动让应用常驻；
    共享连接通道的方式，比如极光或者个推，通过共享连接，当应用有推送到达时，唤起该应用。

显然，后者在体验上更加接近 GCM 。

到达率

到达率 = 实际到达数 / 目标用户数

在线数 -> 目标用户数 -> 成功下发数，如果后端的计算或调用出现问题这两个数据就会不准确；

在线数 -> 实际到达数 -> 展示数，数据收到后，是否展示要看用户有没有打开该应用的允许通知的开关，可以通过如下方法判断：
    
notificationManagerCompat.areNotificationsEnabled();

耗电量

耗电量受到很多方面的影响，如果收到推送比较多，打开应用比较频繁，耗电量自然也会上去不少，但这个用户是可以接受的。

以下几个耗电量的因素用户是比较反感的：

    应用间互相唤醒产生的耗电，因为这个耗电是别的应用的，用户本来没有意图要去打开；
    错误重试造成的耗电，重试策略的优化包括重试时间的累加和重置。

推送选型

上面提到，我们这里聊的推送，是第三方推送，那有开发者要问了，为什么不自己做推送？

自己做不是不行，但需要考虑几个问题：

    开发成本问题， ROI 是否可以接受；
    如果不加入白名单，那么一旦应用被彻底杀掉，是没人给你吟唱复活魔法（互相唤起）的。

第三方推送主要有厂商推送和非厂商推送：

    华为、小米、魅族推送；
    个推、极光、友盟；
    阿里、腾讯、百度。

其中，选型的几个因素：

    厂商推送通知是否系统通道（所有厂商支持）；
    厂商推送透传是否系统通道（仅魅族）；
    非厂商推送的市场占有率（影响共享连接互相唤起的概率）。