我遇到了 C2DM 问题。有时效果很好，有时我的消息根本没有被推送。 是否有可靠的方法来强制执行此连接？拉消息。 我在某处读到谷歌所做的是始终保持与服务器的低带宽 TCP 连接。所以我假设 当在网络类型之间切换时，TCP 连接中断并且 Android 尝试重新建立与 C2DM 服务器的连接。因此，在受限网络的 WiFi 上可能会失败。 这是错误的假设吗？
我注意到 WhatsApp 有时在 WiFi 上收不到消息。当我切换到 3G 时，我通常会在切换的那一刻得到它们。 您会根据您的 C2DM 经验提供哪些建议？
【问题讨论】：
标签： android push-notification android-c2dm
C2DM 不适合您应用程序的关键部分，因为 Google 目前不提供 SLA 或付费层来保证您可靠的服务和吞吐量。
我自己考虑过几种替代方案：XMPP via asmack、Parse、Deacon、Urban Airship 和 MQTT。
经过一些阅读和实验后，我决定使用 MQTT。它是 IBM 发明的一种非常轻量级的遥测协议，非常适合 Android 推送通知场景。我建议你试一试，这里有一篇很好的博文可以指导你：Using MQTT in Android mobile applications。
希望这会有所帮助。
【讨论】：
C2DM 不保证您的消息将被传递，并且您的应用程序不应该假设这样才能正常工作。因此，您的 C2DM 消息不应该包含数据本身，而是包含可用数据的通知。换句话说，C2DM 消息的丢失绝不会导致您的应用程序丢失数据；它最多应该会导致需要更长的时间才能注意到您的服务器上的某条数据可用。
即使在使用 C2DM 时，典型的应用程序也应偶尔（很长一段时间）连接到其服务器以检索消息，以涵盖 C2DM 消息可能无法传递的情况。
根据网络配置，设备可能无法接收 C2DM 消息；限制性防火墙或其他奇怪的 WiFi 配置可能会这样做。
【讨论】：
【讨论】：
我自己也一直在努力解决同样的问题。你描述的行为是准确的。我正在开发一个主要使用 Wifi 连接的 c2dm 应用程序，我必须实现一个 AsyncTask 来定期（一分半钟）调用 WifiManager.reassociate() （关闭然后再次打开 wifi 会触发所有待处理通知的到来，这就是启发这个解决方案的原因）所以我可以尽可能准确地保持通知到达。不过，不太确定这种做法的正确性。
【讨论】：
您是否每 15 分钟连接一次对其进行测试？我创建了一个计划任务来发送消息。我使用 NotifyMyAndroid 推送它。 C2DM 有时会在大约 10 分钟后推送消息，而不是立即推送。但是，有时您会在大约一秒钟内完成。
【讨论】：
您可以做到这一点的最佳方法是通过测试。我的应用程序中有一个机制，当我启用调试时，我会收到来自客户端的 HTTP 请求，说他们收到了消息。
我发现这个数字大约是 80%。幸运的是，这对于我的应用范围来说已经足够了。
Wifi 不应干扰 C2DM 接收消息的能力。至少在电话处于活动状态时。
手机待机一段时间后，android会关闭wifi。这些消息在那个时间段内将不可用，仅仅是因为没有可用的互联网连接。用户唤醒手机后，他们应该会立即收到消息。
【讨论】：
经过很长时间几乎“所有互联网”的研究，我找到了答案。正如我之前发布的那样，我自己也在努力解决这个问题，发现这不是 C2DM 问题，甚至不是实施问题。这只是路由器或防火墙配置错误。 Android 使用具有心跳保持活动机制的持久 TCP 连接来确保连接保持正常。 Google 使用连接状态来确定您的设备是否处于空闲状态。但是，如果您的路由器具有检查“未使用”连接并终止它们的保护策略，那将无法正常工作。 Android 通知应立即发送（接近）。我已经在我的学校网络和家庭网络中对此进行了测试，有两种不同的行为。
要恢复：请务必检查您的网络配置。
【讨论】：
在 C2DM 中，一些 APN 比其他 APN 更有效。例如，谷歌“gtalk apn”可以找到有关 APN 对 C2DM 影响的论坛。
【讨论】：