これは実際、Google Cloud Messaging の非現実的なハートビート間隔が原因です。
これはおそらく、GCM で最も苛立たしいバグです。GCM は、Android デバイスから Google のサーバーへのアイドル ソケット接続を維持することで機能します。これは、(ポーリングとは対照的に) バッテリー電力をほとんど消費せず、メッセージが到着するとすぐにデバイスを起動できるため、優れています。接続がアクティブなままであることを確認するために、Android はモバイル接続では 28 分ごと、WiFi では 15 分ごとにハートビートを送信します。ハートビートが失敗した場合、接続は終了しており、GCM は接続を再確立し、保留中のプッシュ通知を取得しようとします。ハートビート間隔が長いほど、バッテリーの消費が少なくなり、デバイスがスリープから復帰する回数が少なくなります。
ただし、これには大きな代償が伴います。ハートビート間隔が長くなるほど、切断されたソケット接続を特定するのに時間がかかります。Google は、GCM をデプロイする前に、実際の状況でこれらの間隔を十分にテストしていません。これらの間隔の問題は、ネットワーク ルーターとモバイル キャリアが原因で発生します。これらは、アイドル状態のソケット接続が数分間非アクティブになると切断されます。通常、これは安価な家庭用ルーターでより一般的です。ルーターのメーカーは、アイドル状態のソケット接続の最大寿命を決定し、それを終了してリソースを節約します。これらのルーターは限られた数の同時接続しか処理できないため、過負荷を防ぐためにこの手段が取られます。これにより、GCM ソケットが終了し、GCM メッセージを配信するときが来ても、デバイスに到達しません。デバイスは、0 ~ 28 分後にハートビートを送信する時間になったときにのみ接続が切断されたことを認識し、状況によってはプッシュ通知が役に立たなくなることがあります (たとえば、メッセージがタイム クリティカルである場合)。私の経験では、ほとんどの安価なルーターは、非アクティブ状態が約 5 ~ 10 分続くと、アイドル状態の接続を終了します。
これと他の GCM の問題について、記事全体を書きました。
http://eladnava.com/google-cloud-messaging-extremely-unreliable/
Google クラウド メッセージングの代替手段
Pushy ( https://pushy.me/ ) は、GCM から完全に独立したスタンドアロンのプッシュ通知ゲートウェイです。プッシュ通知を受信するために、GCM と同様に独自のバックグラウンド ソケット接続を維持します。基礎となるプロトコルは MQTT です。これは非常に軽量な pub/sub プロトコルであり、ネットワーク帯域幅とバッテリーをほとんど使用しません。
Pushy の大きな利点は、(サーバーから) プッシュ通知を送信し、プッシュ通知用にデバイスを登録するためのコードが、実際には GCM と Pushy の間で交換可能であることです。これにより、GCM を実装し、不安定性のために GCM を捨てなければならなかった後で、Pushy に切り替えるのが非常に簡単になります。
(完全な開示: 私は自分のプロジェクトのために Pushy を設立し、多くのアプリがそのようなサービスから恩恵を受けることに気付きました)