push-notification - 推送通知(如 GCM)为何以及如何高效?

标签 push-notification google-cloud-messaging android-c2dm mqtt

想要了解 Google Cloud Messaging(以前称为 Google Cloud to Device Messaging)等推送通知对于云 <--> 设备通信而言更加电池友好的根本原因吗?

在我看来,替代技术涉及“轮询”(通过 TCP/IP),同时使用 keep-alives 将连接保持在 CONNECTED 状态。或者有更好的吗?

我对 GCM 的有限理解是,它也使用 TCP/IP 和 keepalive,但客户端从不轮询服务器的状态。相反,服务器会通知客户端有关传入消息的信息,并且订阅特定类型消息的应用程序会异步收到该消息的通知。此外,公共(public) GCM 连接在多个应用程序之间共享,从而允许设备电子设备在“协调”时间 sleep /休眠,而无需多个应用程序使电子设备保持比其需要的更多“开启”(电事件)。这是正确的理解吗?还是还有更多内容?

最后,这与带有 keepalives 的 TCP/IP 上的 MQTT 相比到底如何? MQTT 的电池效率(显然)低于 GCM 的原因是什么?

最佳答案

其高效的主要原因之一是其可扩展性良好。 Android 设备保持对 GCM 服务器开放的单个连接,以监听设备上所有应用程序的通知,然后将消息路由到它们所针对的适当应用程序。这比为每个想要某种推送通知的应用程序保持网络连接打开更具可扩展性和效率。

连接本身可能是一个处于打开状态的 TCP 连接,即使手机处于空闲状态也是如此。当接收到数据时它可以唤醒设备。我想如果有必要的话,也会有某种心跳 ping 来重新建立连接。

套接字的东西可能是你可以自己做的事情,但是就像我之前所说的,效率的主要原因是所有应用程序的单一连接。非常具有可扩展性。

关于push-notification - 推送通知(如 GCM)为何以及如何高效?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22663778/

相关文章:

android - 自己的 Android 应用中的 Google+ 推送通知

ios - 首次注册该服务时,iOS 上的 IBM-Bluemix 推送服务使应用程序崩溃

android - 为 'Package Name' 重置退避

android - 在不启动 Activity 的情况下将 Intent 从 GcmIntentService 发送到当前 Activity

android - 无法在 Google App Engine 上部署 Android App Engine 项目

Android - 无法接收 C2DM 注册意向

ios - 代码 : why launchOptions in didFinishLaunchingWithOptions always nil?

push-notification - 为什么我尝试在 Google 上的 Actions 上推送通知时收到 404 'App [my-project-id] was not found. The app preview may have expired.'?

php - Apple 不保证推送的交付?

php - GCM 服务器出现 401 错误