设备向服务端发起一个连接, 并定时发送心跳包维持这个连接 通知到达后服务器通过这个连接向设备推送, 如果设备不在线就放进缓冲区等待设备上线 一般操作系统会提供一个统一的服务处理所有通知, 例如 Android 的谷歌 FCM 和 iOS 的苹果 APNS FCM 在国内可以直连, 但没有优化线路所以效果一般, 没有其他谷歌服务使用也麻烦, 所以国产都做了自己的推送服务, 但也因此出现了碎片化, App 需要给不同厂商单独接入 APNS 要求 App 把推送信息交给苹果, 苹果直接把通知推到手机, FCM 则支持让推送唤醒 App, App 去获取实际内容并生成通知; 前者更省电, 但功能有限, 例如 Signal 这种端到端加密聊天因为服务端无法解密而无法通过 APNS 推送消息内容 --- 客户端轮询也可以, 但想消除延迟就需要快速唤醒所以很耗电, 一般不建议使用 微信在国内会自己挂一个推送服务并将 FCM 作为备用推送渠道, 国外则会直接用 FCM
对于 iOS 设备： 使用 Apple Push Notification Service (APNs)：每个 iOS 应用在注册推送通知后会获得一个唯一的 Device Token 。服务器端将要推送的消息、目标设备的 Device Token 以及其它必要参数封装成推送请求，发送给 Apple 的 APNs 服务器。 APNs 与每台 iPhone 、iPad 等设备维持一个持久连接（长连接）。 当服务器端发送推送消息时，通过与 APNs 的连接将消息转发至对应的设备。 设备收到推送消息后，即使应用不在前台运行，也能显示通知并将消息存储，用户点击通知时可以唤醒对应的应用。 对于 Android 设备： Google Firebase Cloud Messaging (FCM) 或其他第三方推送服务：类似 iOS ，Android 设备也会通过相应的服务获取一个 Registration ID ，并将其发送给服务器。 服务器通过与 FCM 服务器接口交互，将消息和目标设备的 Registration ID 一起发送给 FCM 。 FCM 利用自身的长连接网络服务将消息分发到各个设备。 设备接收到消息后，根据消息类型显示通知，或者静默处理。
