推送 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 进行跨过程通信，当一个服务被杀死时，另一个服务会重新启动它。这种办法能够无效地避免单个过程被杀死，然而如果零碎同时杀死两个过程，就无奈保活了。