我在我的应用程序中使用 GCM，但我遇到了问题。
大多数情况下，我会立即收到消息，但有时消息会在 5 分钟后收到，一个接一个，就像卡在路上一样。这是正常的吗？
问问题
8047 次
3 回答
8
客户端电话上的 GCM 框架部分在端口 5228 上使用TCP 连接。此连接用于推送通知，但作为每个 tcp 连接，它可以与一些应用严格策略来终止非活动 tcp 连接的路由器/运营商超时（tcp 空闲超时）。
例如，大多数 wifi 路由器会在 5 分钟后终止非活动连接，例如我的。
GCM 框架使用保活机制，在 wifi 上每 15 分钟发送一个心跳网络数据包，在 3G 上每 28 分钟发送一个心跳网络数据包。这种保持活动对所有用户来说并不总是可靠的。
我在这里向谷歌打开了这个问题： https ://productforums.google.com/forum/#!category-topic/nexus/connecting-to-networks-and-devices/fslYqYrULto 他们同意目前存在问题。
于 2013-08-25T10:57:49.297 回答
6
到目前为止，我还没有注意到在我极其有限的测试中，但根据我对文档的理解，这听起来并不令人惊讶：
GCM 通常会在消息发送后立即传递消息。但是，这可能并不总是可能的。例如，设备可能已关闭、离线或不可用。在其他情况下，发送方本身可能会通过使用 delay_while_idle 标志请求在设备变为活动状态之前不传递消息。最后，GCM 可能会故意延迟消息，以防止应用程序消耗过多资源并对电池寿命产生负面影响。
在此和文档其余部分的语言之间，您所描述的内容听起来完全符合我的预期。不能保证立即交货；您通常会立即收到消息，但有时您不会。
于 2012-07-27T04:45:43.470 回答
0
我发现与原始海报相同的东西。“唤醒”似乎最多需要 5 分钟，然后它会非常快速地处理这些消息。
我的应用程序正在处理与聋人对话中的文本项。呼叫者发起对话，聋人通过电话响应。延迟仅发生在第一步，即“出乎意料”的新消息中。一旦完成了第一个（应用程序、设备、系统 ID？），其他的就会很快通过，几乎是瞬间完成。
于 2012-12-13T12:21:57.000 回答