MobTech MobPush|TCP 通道和共享链路通道

推送 SDK 为了适应不同的场景和需求，对于一些对消息及时性、可靠性、自定义性要求高的应用，如即时通讯、社交、游戏等，可能更倾向于使用 TCP 通道，对于一些对消息节省流量、耗电量、兼容性要求高的应用，如新闻、天气、股票等，可能更倾向于使用系统通道。当然，也有一些应用会同时使用两种通道，根据不同类型的消息选择合适的通道进行推送。

自有 TCP 通道

自有 TCP 通道是指推送 SDK 通过建立一个 TCP 长连接来与客户端设备通信，从而实现消息的下发和回执。这种通道的优点是可以自定义消息类型和样式，灵活度高，也可以避免 Google 服务在国内不可用的问题。但是这种通道的缺点是需要客户端和服务器保持一个长连接，会增加客户端的耗电量和流量，而且容易受到手机厂商和清理程序的限制，导致长连接不稳定，影响消息的到达率。

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

• 推送 SDK 为广大开发者提供稳定、实时的推送服务，需要能够承受极大的网络负担压力，会连接大量的客户端，并且要积极保障可快速响应；

• 对于推送服务来说消息内容却更多是短消息内容，并非短文，大多类似于短信长度的提醒、通知、营销内容，可以控制在 UDP 数据包长度内，不需要进行分包处理；

• 对于 PUSH 来说，对数据的到达顺序性要求比较低，不像 IM 这种交互需要保障消息的顺序。

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

共享链路通道

共享链路通道是指一些手机厂商提供的推送服务，如 iOS 的 APNs，Android 的 FCM 等。共享链路通道的优势是可以利用系统级别的权限和资源，保证推送消息的高效到达和低耗电。

推送 SDK 可以自动适配不同厂商的通道，实现多通道的智能推送。为什么需要对接厂商通道呢？其实这个也是和 APP 的保活有及大的关系。一般的保活方式包括：利用系统 Service 机制、设置进程优先级，降低被系统 kill 的概率。有以下几种方法：

• 利用前台服务提高进程优先级。前台服务是指在通知栏显示一个常驻的通知，让用户感知到服务的存在，从而提高进程的优先级，使其不容易被系统杀死。但是这种方法会占用通知栏的空间，影响用户体验，而且在 Android 8.0 以上需要创建一个 NotificationChannel，否则会报错。

• 利用系统广播唤醒进程。系统广播是指在发生特定系统事件时，系统会发出广播，通过在 AndroidManifest 中静态注册对应的广播监听器，即可在发生响应事件时唤醒进程。但是从 android 7.0 开始，对广播进行了限制，而且在 8.0 更加严格，只有少数几个广播可以静态注册。

• 利用双进程守护提高进程存活率。双进程守护是指创建两个服务分别运行在不同的进程中，通过 AIDL 进行跨进程通信，当一个服务被杀死时，另一个服务会重新启动它。这种方法可以有效地防止单个进程被杀死，但是如果系统同时杀死两个进程，就无法保活了。