C2DM的可靠性
我在使用 C2DM 时遇到问题。有时效果很好，有时我的消息根本没有被推送。 有可靠的方法来强制执行此连接吗？拉取消息。我在某处读到，谷歌所做的就是始终保持与其服务器的低带宽 TCP 连接。所以我假设 当在网络类型之间切换时，TCP 连接会断开，Android 会尝试重新建立与 C2DM 服务器的连接。因此，在网络受限的 WiFi 上，这可能会失败。 这个假设是错误的吗？
我注意到 WhatsApp 在 WiFi 上有时收不到消息。当我切换到 3G 时，我通常会在切换时获取它们。 根据您的 C2DM 经验，您会提供哪些建议？
I am having issues with C2DM. Sometimes works perfectly, sometimes my messages simply do not get pushed. Is there reliable way to enforce this connection? To pull messages. I read somewhere that what google do is keep low bandwidth TCP connection to their server at all time. So I assume that
when switching between network types TCP connection falls down and Android tries to reestablish connection to C2DM servers. So that might fail on WiFi with restricted network. Is that wrong assumption?
I have noticed with WhatsApp that on WiFi sometimes I do not get messages. When I switch to 3G I usually get them at the moment of the switch. What tips from your experience with C2DM would you offer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
消息或您（发件人）意识到消息已成功接收的某种方式。
message or some way in which you (the sender) the realize the message was received successfully.
我自己也一直在为同样的问题而苦苦挣扎。您所描述的行为是准确的。我正在开发一个主要使用 c2dm 与 Wifi 连接的应用程序，我必须实现一个 AsyncTask 来定期（一分半钟）调用 WifiManager.reassociate() （关闭并再次打开 wifi 会触发所有待处理通知的到达，这就是这个解决方案的灵感来源），这样我就可以尽可能保持通知到达的准确性。不过，不太确定这种做法的正确性。
I've been struggling with the same problem myself. The behaviour you describe is accurate. I'm developing an app that uses c2dm mainly with Wifi connection, and I had to implement an AsyncTask to periodically (minute and a half) call WifiManager.reassociate() (turning wifi off and on again triggers the arrival of all pending notifications, that's what inspired this solution) so I can keep the notification arrival as accurate as possible. Not so sure about the correctness of this practice, though.
您是否每 15 分钟连接测试一次？我创建了一个计划任务来发送消息。我使用NotifyMyAndroid来推送它。 C2DM有时会在大约10分钟后推送消息，而不是立即推送。但是，有时你在一秒钟左右就能得到它。
Have you tested it every 15 minute connection? I created a schedule task to send the message. I use NotifyMyAndroid to push it. C2DM sometime pushes the message about 10 mninutes after not instantly. But, sometimes you get it in around a second.
做到这一点的最好方法是进行测试。我的应用程序中有一个机制，当我启用调试时，我会收到来自客户端的 HTTP 请求，表示他们收到了消息。
我发现这个数字大约是80%。幸运的是，这对于我的应用范围来说已经足够了。
Wifi 不应干扰 C2DM 接收消息的能力。至少在手机处于活动状态时是这样。
发生的情况是，手机待机一段时间后，android 会关闭 wifi。这些消息在该时间段内将不可用，因为没有可用的互联网连接。用户唤醒手机后，他们应该会立即收到消息。
The best way you can do this is by testing. I have a mechanism in my app that when I enable debugging I receive a HTTP request from the client saying that they received the message.
I find that this number is about 80%. Fortunately that's enough for the scope of my application.
Wifi shouldn't interfere in the C2DM ability of receive messages. At least while the phone is active.
What happens is that android turns the wifi OFF after the phone is in standby for a while. The messages won't be available at that period of time, simply because there's no internet connection available. Right after the user wakes the phone up, they should receive the messages.
经过长时间研究“所有互联网”的答案，我找到了它。正如我之前发布的，我自己也在努力解决这个问题，并发现这不是 C2DM 问题，甚至不是实施问题。这只是路由器或防火墙配置错误。 Android 使用带有心跳保持活动机制的持久 TCP 连接来确保连接保持正常状态。 Google 使用连接状态来确定您的设备是否处于空闲状态。但是，如果您的路由器具有检查“未使用”连接并终止它们的保护策略，那么这将不起作用。 Android 通知应该立即（接近）立即发送。我已经在我的学校网络和家庭网络中对此进行了测试，有两种不同的行为。
要恢复：请务必检查您的网络配置。
After a long time research pretty much "all the internet" for an answer, I've found it. As I posted before, I was struggling with the problem myself and found out it was not a C2DM problem, or even a implementation problem. It was simply a router or firewall misconfiguration. Android uses a persistent TCP connection with a heartbeat keep-alive mecanism to ensures that the connection stays up. Google uses the state of the connection to determine if your device is idle or not. But if your router has a protection policy that checks for "unused" connections and terminates them, that won't work. Android notifications should be delivered (close to) instantly. I've tested this in my school network and home network, with two diferrent behaviour.
To resume: be sure to check your network configurations.
某些 APN 与 C2DM 配合使用时效果比其他 APN 更好。例如，通过 Google“gtalk apn”查找有关 APN 对 C2DM 影响的论坛。
Some APNs work better than others with C2DM. Google "gtalk apn", for example, to find forums about the impact of the APN on C2DM.
C2DM 不适合应用程序的关键部分，因为 Google 目前不提供 SLA 或付费等级来保证您可靠的服务和吞吐量。
我自己考虑过几种替代方案：通过 asmack 的 XMPP、解析，执事，城市飞艇和MQTT >。
经过一些阅读和实验后，我决定使用 MQTT。它是 IBM 发明的一种非常轻量级的遥测协议，非常适合 Android 推送通知场景。我建议您尝试一下，这里有一篇很好的博客文章可以指导您：在 Android 移动设备中使用 MQTT应用程序。
希望这有帮助。
C2DM is not suitable for critical parts of your application, since Google currently does not offer an SLA or paid tiers that will guarantee you reliable service and throughput.
I've considered several alternatives myself: XMPP via asmack, Parse, Deacon, Urban Airship, and MQTT.
After some reading and experimenting I decided to go with MQTT. It is a very lightweight telemetry protocol invented at IBM that fits quite nicely in the Android push notifications scenario. I recommend you give it a try, here's a nice blog post to guide you: Using MQTT in Android mobile applications.
Hope this helps.
C2DM 不保证您的消息一定会被传递，并且您的应用程序不应该做出这样的假设才能正常工作。因此，您的 C2DM 消息不应包含数据本身，而应包含有可用数据的通知。换句话说，C2DM 消息的丢失绝不会导致您的应用程序丢失数据；它最多应该导致需要更长的时间才能注意到服务器上的某个数据可用。
典型的应用程序应该偶尔（很长一段时间）连接到其服务器来检索消息，即使在使用 C2DM 时也是如此，以应对 C2DM 消息可能无法传递的情况。
根据网络配置，设备可能无法接收 C2DM 消息；限制性防火墙或其他奇怪的 WiFi 配置可能会这样做。
C2DM does not guarantee that your message will be delivered, and your application should not assume that in order to work correctly. Therefore, your C2DM message should never contain the data itself but, rather, a notification that there is data available. In other words, the loss of a C2DM message should never cause your application to lose data; it should, at most, cause it to take longer to notice that a certain piece of data is available on your server.
A typical app should connect to its server once in a while (a long while) to retrieve messages, even when using C2DM, to cover the case where C2DM messages might not be delivered.
Depending on network configuration, the device might not be able to receive C2DM messages; restrictive firewalls or other strange WiFi configs might do that.