MobTech MobPush|推送的下发逻辑是什么样的

Mobpush是一款由MobTech提供的专业免费的推送SDK，可以帮助开发者实现智能化的推送服务。它支持多种推送消息类型，全链路数据统计分析，多种厂商通道，以及用户行为分析等功能。那么，Mobpush是如何将推送消息下发到用户设备的呢？本文将从以下几个方面介绍Mobpush推送的下发逻辑：

• 推送模式
• 推送协议
• 厂商通道
• 心跳机制

推送模式

Mobpush整体使用Mobpush自有通道+厂商通道的方式，厂商通道包括iOS的APNs，Android的厂商通道包括华为、小米、魅族、OPPO、vivo等。如下图先看下整体的推送流程：

以上是Mobpush整体的流程。
iOS的通知栏消息全部是基于APNs首先下发的，但是如果APNs发送失败，我们会再尝试使用自有消息通道进行消息下发，然后再由客户端处理为本地通知的方式到达通知栏，这样可以保证更高的消息到达能力。
Android的通知消息如果对接了厂商通道，则优先会经过厂商系统级别的通道发送，并且如果厂商通道失败，会采用离线的方式保留，待客户端下次上线之后采用Mobpush通道下发；所有的透传消息都是需要经过Mobpush自有通道下发的。

推送协议

Mobpush自有通道是自定义的一套基于UDP的更为简单的二进制网络通信协议。为什么会考虑使用UDP协议呢？有以下几个原因：

• Mobpush定位为广大开发者提供稳定、实时的推送服务，需要能够承受极大的网络负担压力，会连接大量的客户端，并且要积极保障可快速响应；对于推送服务来说消息内容却更多是短消息内容，并非短文，大多类似于短信长度的提醒、通知、营销内容，可以控制在UDP数据包长度内，不需要进行分包处理，Internet上的标准MTU（最大传输单元）值为576字节，网络层IP需要占据20，UDP首部占用8个，所以只需要控制下发内容长度在576-20-8 =548字节即可；对于PUSH 来说，对数据的到达顺序性要求比较低，不像IM这种交互需要保障消息的顺序。
• UDP更加适合Mobpush的协议选型了，当然在Mobpush也并不是完全放弃如MQTT的Qos机制，这个会在对应的设置条件下可保障消息有一次的到达。
• Mobpush在消息安全上也有所考虑，会在下发消息经过压缩、AES加密处理，而加密的AES KEY是动态生成。

厂商通道

厂商通道是指一些手机厂商提供的推送服务，如iOS的APNs，Android的华为、小米、魅族、OPPO、vivo等。厂商通道的优势是可以利用系统级别的权限和资源，保证推送消息的高效到达和低耗电。Mobpush可以自动适配不同厂商的通道，实现多通道的智能推送。
为什么需要对接厂商通道呢？其实这个也是和APP的保活有及大的关系，当前Android的保活、互拉及其困难，但是绝对重要。一般的保活方式包括：利用系统Service机制、设置进程优先级的方式、利用系统广播、使用AlarmManager、进程间相互拉起、利用Native进程等等，但是现在android的对这些机制都有了对应策略，很难发挥相对大的作用。诚然在华为、小米、魅族各系统中已经有厂商自己的推送链接服务，厂商自己的推送服务肯定是不会被杀死的，所以在考虑推送服务的时候，利用好厂商自有通道，可以很好的保障消息的准确到达，并且有的机型可以很好唤醒APP。

心跳机制

心跳机制是指客户端和服务器之间定期发送一些小数据包来维持连接状态和检测网络状况。Mobpush依靠心跳的机制来维护客户端、路由器、基站、服务端的关系，以此对抗NAT老化问题，以确保UDP链接的套接字保活。NAT老化问题是指由于IP资源的有限以及路由器端口数量有限导致路由器会定期清理不活跃的连接记录。
Mobpush的心跳包体只有一个字节长度，能够很大的节省Client的流量，而且对于心跳时间也可以调整。根据不同网络环境和设备状态，Mobpush会动态调整心跳间隔，从而达到最佳的推送效果。