GCM 消息传递时间非常不稳定答案

【问题标题】：GCM msg delivery times are WILDLY erraticGCM 消息传递时间非常不稳定
【发布时间】：2012-10-12 12:59:33
【问题描述】：

我已经设置了一个支持 GCM 的 Android 应用，并且有一个小测试应用可以向该应用发送消息。当我在模拟器中运行应用程序时，我可以看到（通过日志消息）它向 GCM 注册并获得了一个 Token。

然后当我将令牌放入我的测试应用并让它发送一条消息时，结果显示发送了 1 条消息，0 失败，0 有 ID 更改。

有时消息几乎立即显示，有时需要 20 分钟。周五，我的 2 条测试消息用时 15 和 20 分钟。我今天早上发的前2个是立即的，下一个还没有出现-才10分钟...

我可以做些什么来使交货时间始终如一地加快？随机延迟 20 分钟几乎是不可接受的条件。

【问题讨论】：

我也注意到了这种行为，我认为通过 Wi-Fi 连接时会出现某种 10 分钟超时。我已经在 Google Group 上发布了关于它的信息，但到目前为止没有回复：groups.google.com/d/msg/android-gcm/Y33c9ib54jY/vmJRFv0SmKYJ

标签： android message google-cloud-messaging

【解决方案1】：

我们遇到了同样的问题，但它因网络而异。我们认为这是家庭集线器路由器（维珍超级集线器）在闲置五分钟后断开连接。您可以通过每两分钟发送一条空的 GCM 消息来确认连接以保持连接。

下面是对我们所做工作的更深入解释：https://groups.google.com/d/msg/android-gcm/Y33c9ib54jY/YxnCkaPRHRQJ

【讨论】：

Rupert Rawnsley，您对 GCM 延迟问题进行了一些出色的研究，并在上面的 Google Group 链接中发表了这些研究。这应该得到更多的支持

【解决方案2】：

您无法保证快速交付，因为正如 CommonsWare 所指出的那样，GCM 到设备的连接性可能很差。然而，传送列车有两种可能的延迟：1）GCM 连接到手机（如前所述）和 2）实际从 GCM 服务器发出的消息的延迟。如果您在发送应用程序中将“time_to_live”参数设置为 0 秒，那么您至少可以测试延迟发生的位置。

值为 0 秒表示消息将立即发送，如果发送不成功，消息将在 GCM 服务器上丢弃。对现实生活没有实际使用价值，但可以让您找出送货列车的哪个部分导致了延误。

【讨论】：

由于我已经登录了我们的服务器以将消息发送到 GCM 的调用，这主要是告诉我 GCM 是否在连接到设备时遇到问题，对吗？我得试试。
是的，TTL 为 0，如果手机没有立即收到消息，则 GCM 服务器与手机没有连接。然后它将放弃并且不再尝试发送消息。
使用 TTL=0 和 TTL=1day 进行测试没有任何区别。有时味精会立即出现，有时需要很长时间。（嗯，当 TTL=0 时，消息可能永远不会出现。）当设备在线并处于活动状态时，随机延迟 15-20 分钟会使 GCM 看起来相当不可靠，并且用户体验极差。（你认为发短信的人不会介意他的短信需要 20 分钟才能到达吗？）
我可以在数据连接良好的地方立即发货。上周末，当数据连接很差时（在与伦敦不同的位置），它花了很多时间。在我的设备上，如果我禁用数据包数据，然后立即重新启用它，那么所有消息都会立即通过。我把这归结为我的 Galaxy S2 切换协议从 H+ 到 H 到 3G 中的一个错误
除了 TTL 之外，另一件需要注意的事情是在发布到 GCM 服务器时在 GCM 通知上设置的参数“delay_while_idle”。这样一来，Google 只会在设备退出空闲状态后才发送通知。

【解决方案3】：

这确实是由 Google Cloud Messaging 中的不切实际的心跳间隔造成的。

这可能是 GCM 中最令人沮丧的错误。 GCM 的工作原理是维护从 Android 设备到 Google 服务器的空闲套接字连接。这很棒，因为它几乎不消耗电池电量（与轮询相反），并且它允许在消息到达时立即唤醒设备。为确保连接保持活动状态，Android 将在移动连接上每 28 分钟发送一次心跳，在 WiFi 上每 15 分钟发送一次。如果心跳失败，则连接已终止，GCM 将重新建立它并尝试检索任何未决的推送通知。心跳间隔越高，消耗的电池越少，设备从睡眠中唤醒的次数就越少。

但是，这是有代价的：心跳间隔越长，识别断开的套接字连接所需的时间就越长。在部署 GCM 之前，谷歌没有在现实生活中对这些间隔进行足够彻底的测试。这些间隔的问题是由网络路由器和移动运营商引起的，他们在几分钟不活动后断开空闲套接字连接。通常，这在廉价的家用路由器中更为常见，其制造商决定了空闲套接字连接的最大寿命，并终止它以节省资源。这些路由器只能处理有限数量的并发连接，因此采取这种措施是为了防止过载。这会导致 GCM 套接字终止，并且当传递 GCM 消息时，它不会到达设备。设备只会在发送心跳时才意识到连接已断开，即 0 到 28 分钟后，在某些情况下（例如，当消息对时间要求严格时），推送通知会变得无用。根据我的经验，大多数便宜的路由器会在大约 5 到 10 分钟不活动后终止空闲连接。

我写了一篇关于这个和其他 GCM 问题的完整帖子：

http://eladnava.com/google-cloud-messaging-extremely-unreliable/

Google 云消息传递的替代方案

Pushy (https://pushy.me/) 是一个独立的推送通知网关，完全独立于 GCM。它维护自己的后台套接字连接，就像 GCM 一样，以接收推送通知。底层协议是 MQTT，一种极其轻量级的发布/订阅协议，占用的网络带宽和电池非常少。

Pushy 的一个巨大优势在于，用于发送推送通知（从服务器）和注册设备以获取推送通知的代码实际上可以在 GCM 和 Pushy 之间互换。这使得在实施 GCM 之后切换到 Pushy 变得非常容易，并且由于它的不稳定性而不得不放弃它。

（完全披露：我为自己的项目创建了 Pushy，并意识到许多应用程序将从这样的服务中受益）

【讨论】：

【解决方案4】：

据报道，GCM 存在相当严重的问题，即保持活动的心跳不那么可靠。因此，由于它仅每 15 分钟（超过 3G）或 28 分钟（通过 Wifi）发送一次，如果由于某种原因导致服务器连接断开，可能需要很长时间才能恢复。

这些类型的恶作剧促使开发了一种不依赖第三方网络的解决方案，以向离线（后台）Android 应用提供可大规模扩展且可靠的推送通知。

https://help.pubnub.com/entries/21720011-Can-my-Android-App-Receive-Messages-While-Inactive

【讨论】：

【解决方案5】：

这件事对我很重要。

我已经在一个一秒计时器处理程序中设置了这段代码，以每 2 分钟发送一条 GCM 消息。希望它能让事物保持活力

            if ((mOneSecondTick %120) == 0){
            // q 1 minute check when we got last call....
            long lDiff = System.currentTimeMillis() - GCMlastCall;
            if (PushAndroidActivity.GCMAvailable){
                Log.d("pushAndroidActivity",String.format("(mOneSecondTick %d",lDiff));
                if (lDiff > 122 * 1000){ // more than a minute
                    Intent intent = new Intent(StayInTouch.this,PushAndroidActivity.class);
                    2startActivity(intent);
                }else{ // every 2 minutes send out a gcm message...
                    asyncWebCall(String.format(AgeingLib.GCMTICKLE,androidid),0);
                    return; // only if it sends a tickle and all is well...
                }
            }else{
                Log.d("pushAndroidActivity",String.format("(mOneSecondTick mod60 no GCM on this device"));
            }
        }

GCMlastCall 是最后一次收到消息，因此我们可以判断 gcm 是否停止。

工作了几天，感觉还可以

【讨论】：

如果您每 2 分钟发送一次 GCM，它会不会完成前端实例小时数？