如果我可以将服务器中发生的重要事件通知给应用程序用户，我正在研究。所以，我尝试了 Google-Cloud-Messaging 来实现推送通知。不幸的是，我可以看到消息延迟传递，没有确切的延迟传递时间。我什至尝试在 gmail 中发送邮件，而 gmail 本身的推送通知迟到了，没有时间限制。因此，我发现我无法使用 google-cloud-messaging 服务向用户传递重要事件。有没有其他方法可以通知用户重要事件？
注意：我不想使用短信。而且我也不想退出应用程序，因为它会消耗电池寿命。
提前感谢您的帮助。
实际上，这是由于 5228、5229、5230 端口在我的服务器中被阻塞。因此，它需要由网络管理员解除阻止。同样，如果其他接收器（如 facebook 应用程序、gmail 等）处于活动状态并说它们被您的服务器管理员阻止，它们同步不会成功，并且稍后在同步您的应用程序时需要时间。
可能是由于其他问题，也可能是由于发送服务器的地理位置和接收方的 IP 地址。
GCM 用于尽快将消息推送给用户。您可以在消息中指定何时需要发送 - 可能是 gmail 使用 delay_while_idle 标志来节省电池电量。根据我的经验，GCM 非常非常快。如果您在很短的时间内将许多更新推送到同一设备，您应该只会遇到限制。
这可能是由Google Cloud Messaging 中不切实际的心跳间隔引起的。
GCM 的工作原理是维护从 Android 设备到 Google 服务器的空闲套接字连接。这很棒，因为它几乎不消耗电池电量（与轮询相反），并且它允许在消息到达时立即唤醒设备。
为确保连接保持活动状态，Android 将在移动连接上每 28 分钟发送一次心跳，在 WiFi 上每 15 分钟发送一次。如果心跳失败，则连接已终止，GCM 将重新建立它并尝试检索任何未决的推送通知。心跳间隔越高，消耗的电池越少，设备从睡眠中唤醒的次数就越少。
然而，这是有代价的：心跳间隔越长，识别断开的套接字连接所需的时间就越长。在部署 GCM 之前，谷歌没有在现实生活中对这些间隔进行足够彻底的测试。这些间隔的问题是由网络路由器和移动运营商引起的，他们在几分钟不活动后断开空闲套接字连接。
更多信息可在我的博客上找到：
http://eladnava.com/google-cloud-messaging-extremely-unreliable/
作为一种解决方法，请考虑 Pushy ( https://pushy.me )，它是 GCM/FCM 的直接替代品，它极大地提高了通知速度和可靠性（完全披露 - 我创立了 Pushy）。