GCM 之类的推送通知如何在内部工作？

Posted 2023-02-24

【中文标题】GCM 之类的推送通知如何在内部工作？

【英文标题】：How do push-notifications like GCM work internally?

【发布时间】：2015-07-01 16:59:49

【问题描述】：

Google Cloud Messaging (GCM) 等推送通知服务提供了一项特殊功能：它们能够唤醒处于空闲模式的设备。

关于电池寿命，使用哪种方式通过推送连接唤醒设备？我的第一个假设是，即使设备的处理器处于休眠状态，无线电的连接仍然处于活动状态。在传入推送消息的情况下，无线电会通过中断唤醒处理器并启动一个 android intent 来处理推送消息。

但是有像“OpenPush”这样的第三方推送服务提供相同的功能，这让我的假设看起来不完整或错误。还是这些服务只是对多个供应商（Google、Apple）的推送系统的抽象，并且是以本地方式集成的服务的桥梁？

【参考方案1】：

我的第一个假设是，即使设备的处理器处于休眠状态，无线电的连接仍然处于活动状态。

如果“无线电”是指“蜂窝无线电”，这是正确的。即使 CPU 处于睡眠模式，也可以通过移动数据（不是 WiFi）保持打开的套接字连接。该连接上的传入数据包可以唤醒 CPU。 Google 已经花费了相当多的时间对此进行调整，以尽量减少使套接字保持活动状态所使用的电量（例如，定期从设备到 GCM 服务器的“心跳”数据包）。

或者这些服务只是对多个供应商（Google、Apple）的推送系统的抽象，并且是以本地方式集成的服务的桥梁？

这是一种常见的方法。

应用完全有可能尝试通过移动数据维护自己的长寿命套接字。例如，SIP 客户端会执行此操作。做对是很棘手的，特别是考虑到低功耗。我还担心这种方法的可靠性，因为 Android M 中会发生一些变化。

由于 OpenPush 目前非常不开放，我无法具体评论他们在做什么。

【讨论】：

CommonsWare 你能引用任何关于为什么蜂窝调制解调器能够维护套接字和唤醒 CPU 而不是 Wi-Fi 的来源吗？我相信如果 CPU 在 Android 设备上休眠，Wi-Fi 通常保持连接并且不需要重新建立网络套接字连接，但我不知道传入的数据包是否会唤醒 CPU。似乎它会高度依赖 Wi-Fi 驱动程序？还有以太网呢？

@satur9nine：“你能引用任何来源吗？”——我可以告诉你，这就是谷歌所说的，比如在谷歌 I|O 会议上，他们讨论了 C2DM 的实施（前身为GCM 和 FCM）。 “我相信，如果 CPU 在 Android 设备上休眠，Wi-Fi 通常会保持连接状态”——在较新的设备上，这可能是一种选择，但即便如此，它也可能会受到用户配置或制造商更改的影响。 “还有以太网呢？” -- 我不知道，对不起。