我在我的应用程序中使用GCM，我遇到了问题。
大部分时间我都会立即收到消息，但有时消息会在5分钟之后一个接一个地发出，就像他们被困在路上一样。这是正常的吗？
答案 0 :(得分：8)
客户端电话上的GCM框架部分在端口5228上使用 TCP连接。此连接用于推送通知，但是作为每个tcp连接，它可以与某些路由器/运营商一起超时应用严格的策略来终止非活动的tcp连接（ tcp idle timeout ）。
大多数wifi路由器会在5分钟后杀死非活动连接，例如我的。
GCM框架使用 keep-alive 机制在wifi上每15分钟发送一次心跳网络数据包，在3G上每28分钟发送一次。对于所有用户而言，这种保持活力并不总是可靠的。
我在这里向谷歌打开了这个问题： https://productforums.google.com/forum/#!category-topic/nexus/connecting-to-networks-and-devices/fslYqYrULto 他们同意目前存在问题。
答案 1 :(得分：6)
我还没有注意到，到目前为止，在我极其有限的测试中，但是根据我对documentation的理解，这听起来并不令人惊讶：
GCM通常会在发送消息后立即发送消息。但是，这可能并非总是可行。例如，设备可能已关闭，脱机或以其他方式不可用。在其他情况下，发送方本身可能会通过使用delay_while_idle标志请求在设备变为活动状态之前不传递消息。最后，GCM可能会故意延迟消息，以防止应用程序消耗过多的资源并对电池寿命产生负面影响。
在本文和其他文档之间的语言之间，你所描述的内容听起来就像我期望的那样。不保证立即交货;你通常会立即发送消息，但有时你不会。
答案 2 :(得分：0)
我发现与原始海报相同的东西。似乎需要花费5分钟才能“醒来”，然后它会很快处理这些消息。
我的应用正在处理与聋人对话中的文字项目。呼叫者发起对话，聋人通过电话回应。延迟仅发生在第一步，新消息“突然出现”。一旦它完成了第一个（应用程序，设备，系统ID？），其他人很快就会快速完成。