GCMをサポートするAndroidアプリをセットアップし、アプリにメッセージを送信するための小さなテストアプリがあります。エミュレーターでアプリを実行すると、（logging msgsを介して）アプリがGCMに登録され、トークンを取得していることがわかります。
次に、トークンをテストアプリに入れてメッセージを送信させると、結果は1つのメッセージが送信され、0が失敗し、0でIDが変更されたことを示しています。
メッセージがすぐに表示されることもあれば、20分かかることもあります。金曜日に、私の2つのテストメッセージは15分と20分かかりました。私が今朝送った最初の2つはすぐでした、次のものはまだ現れていません-それはたった10分です...
納期を一貫して速くするためにできることはありますか？ランダムな20分の遅延は、ほとんど許容できない状態になります。
同じ問題がありましたが、ネットワークごとに異なりました。ホーム ハブ ルーター (Virgin スーパー ハブ) が 5 分間非アクティブの後に接続を切断したと考えられます。空の GCM メッセージを 2 分ごとに送信して接続を維持することで確認できます。
私たちが行ったことの詳細な説明は次のとおりです: https://groups.google.com/d/msg/android-gcm/Y33c9ib54jY/YxnCkaPRHRQJ
CommonsWare が指摘したように、GCM からデバイスへの接続が不十分な可能性があるため、迅速な配信を保証することはできません。ただし、配信トレインには 2 つの遅延が考えられます。1) 電話に接続する GCM (前述のとおり) および 2) GCM サーバーから実際に送信されるメッセージの遅延。送信アプリケーションで「time_to_live」パラメーターを 0 秒に設定すると、少なくともどこで遅延が発生しているかをテストできます。
0 秒の値は、メッセージがすぐに送信され、配信に失敗した場合、メッセージは GCM サーバーで破棄されることを意味します。これは実際に使用する実用的な値ではありませんが、配達列車のどの部分が遅延を引き起こしているかを調べることができます。
これは実際、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 を設立し、多くのアプリがそのようなサービスから恩恵を受けることに気付きました)
GCM は、キープアライブ ハートビートの信頼性が低いというかなり深刻な問題を抱えていると報告されています。そのため、15 分 (3G 経由) または 28 分 (Wifi 経由) に 1 回しか送信されないため、何らかの理由でサーバー接続が切断された場合、数分間復元されない可能性があります。
この種の悪ふざけは、サードパーティのネットワークに依存しないソリューションの開発を促し、大規模にスケーラブルで信頼性の高いプッシュ通知をオフライン (バックグラウンド) の Android アプリに配信します。
https://help.pubnub.com/entries/21720011-Can-my-Android-App-Receive-Messages-While-Inactive
この問題は私にとって重要です。
このコードを1秒のタイマーハンドラー内に設定して、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が停止したかどうかを確認できます。
数日間働いていたので今は大丈夫そうです