誰もがGoogle Cloud Messaging（GCM）サービスを知っているため、アプリケーションは常に最新のデータをユーザーに表示します。 サービスのスキームには3つのコンポーネントが含まれます。







GCMサーバー、プッシュサーバー、およびアプリケーションがインストールされているデバイスに直接接続します。 操作アルゴリズムは簡単です。デバイスはGCMに登録し、 registrationId（将来使用されるトークン）を受信します。これはローカルに保存され、サーバーに送信されます。 次に、プッシュサーバーはこのregistrationIdを使用して、デバイス上のアプリケーションにメッセージを送信します。



この記事では、図に示されている2つの領域の問題について説明します。プッシュサーバー-GCMおよびGCM-デバイスです。

GCMサーバーからのエラー処理

メッセージが正常に送信されると、プッシュサーバーはGCMからステータスコード200およびゼロ以外のmessage_idを含む応答を受信します。







エラーは、200のステータスコードで応答本文に含まれます。したがって、200のステータスコードのみに依存するだけでは十分ではありません。 ここでは、最も重要なエラーの1つであるNotRegisteredの例を示しますが、他のエラーはそれほど重要ではありません。 ほとんどの場合、プッシュサーバーがメッセージを送信するアプリケーションが削除されたか、アプリケーションが既に別のregistrationIdを使用しており、何らかの理由でプッシュサーバーがそれを認識していないことを意味します。 GCMからこのような応答を受け取ったプッシュサーバーは、このregistrationIdをリポジトリからすぐに削除する必要があります。

エラーを監視するには、開発者コンソールでGCM統計を接続します。

クライアントとプッシュサーバーでのRegistrationId同期

RegistrationIdは、GCMインフラストラクチャの最も重要な部分の1つです。 クライアントとプッシュサーバー間のdescription registrationIdは悲しい結果をもたらします。 ユーザーがプッシュ通知なしで永久に放置される可能性があります。 GCMは、何らかの理由でデバイス上でregistrationIdが更新されたときの状況を監視し、 canonical_idsパラメーターを使用してこれをプッシュサーバーに報告します。







canonical_idsの場合は、次のように再現できます。

1. アプリケーションをインストールする
2. 彼にメッセージを送る
3. アプリケーションをアンインストールする
4. アプリケーションをインストールする
5. 彼にメッセージを送る

手順5でメッセージを送信した後、 canonical_idsパラメーターが1で、すぐに新しいregistrationIdが GCMから返され、クライアントで既に完全に使用されています。







このような回答を受け取ったプッシュサーバーは、単にregistrationIdを応答からの値に更新する必要があります。 これを行わないと、しばらくの間メッセージがクライアントに届き、古いregistrationIdは有効になりますが、遅かれ早かれGCMはNotRegisteredエラーで応答し、その後プッシュサーバーはregistrationIdを削除し、ユーザーはアプリケーションのプッシュ通知を永久に忘れます。 。 したがって、 canonical_idsパラメーターを処理し、罪を犯さないでください。

GCMを使用する2つの主なアプローチ

最初はペイロードのあるメッセージです。 その本質は、メッセージ自体でいくつかの有用な情報を送信することです。 たとえば、メッセンジャーではメッセージのテキスト、ニュースアプリケーションではニュース自体になります。 2番目のメカニズムはSend-to-Syncです。 次のように、トラフィック消費に対してより最適化されています メッセージ自体は大量のデータをパックしません。 このメッセージは、アプリケーションがサーバーから最新のデータを収集する必要があるというシグナルとして機能します。 2番目のアプローチは、 collapse_keyパラメーターに直接関連しています。

ペイロードを含むメッセージ

理想的な状況は、デバイスがGCMサーバーに接続しているときに、メッセージが送信され、デバイスに正常に配信されることです。 接続がなく（たとえば、身動きが取れない、または地下鉄に入った）、この時点でメッセージを受信して​​いる場合、それらはGCMストレージの特定のキューで形になり始めます。 このキューは無限ではなく、制限は100メッセージです。 101個のメッセージが到着するとすぐに、それらはすべて削除され、蓄積されなくなります。 デバイスがネットワークをキャッチし、GCMとの接続を確立すると、345個のメッセージなど、削除されたという情報がアプリケーションに送られます。







そのような意図を受け取ったので、あなたは怠けすぎて、新鮮なデータのためにサーバーに行く必要はありません。 それ以外の場合、ユーザーは次のプッシュ通知が到着したときにのみそれらを表示し、それが到着したときには誰も知りません。 これは、「ペイロードのあるメッセージ」アプローチを実装する際に留意すべき非常に重要なポイントです。

同期に送信

collapse_keyを使用するとしましょう。 これは特定の定数であり、そのうち1つのregistrationIdには4つまでしか指定できません。 アプリケーションの1つのインスタンス。 たとえば、ニュースアプリケーションはさまざまなサービスからいくつかのデータを収集します。 1台のサーバーでスポーツニュース、もう1台のサーバー-文化、3台目-政治、4台目-車を紹介しましょう。 もちろん、5番目のサービスが表示されるときに問題が発生しますが、これはポイントではありません。 適切なセクションにメッセージを送信する際に、 collapse_keyを使用できます：sport、culture、policy、auto。



次のメッセージが同じcollapse_keyで到着すると、 GCMは古いメッセージを新しいメッセージに置き換えます。 原則として、それは論理的です、なぜなら Send-to-Syncアプローチのメッセージは、新しいデータを取得するためにサーバーにアクセスする必要があるというアプリケーションへの単なるシグナルであることを覚えています。 しかし、ここで1つの不快な瞬間に直面しました。そのため、Send-to-Syncアプローチを放棄しなければなりませんでした-速歩。 GCMサーバーは、同じcollapse_keyを使用してできるだけ多くのメッセージを収集するためにしばらく待つことができます。 すべては問題ありませんが、これにより、メッセージのクライアントへの配信に遅延が生じ（30分から1分の遅延に気付く）、メッセンジャーなどの一部のタイプのアプリケーションでは受け入れられません。







この遅延のため、 collapse_keyの使用を停止しました 。 アプリケーションでメッセージ配信のわずかな遅延が重要でない場合は、Send-to-Syncアプローチが適切な選択です。



時間が経つにつれて、プッシュサーバーの実装で上記のすべての詳細を考慮しました。 しかし、まだ次の内容のレビューが多数ありました。「新しいメッセージは、アプリケーションにアクセスしたときにのみ表示されます。 実行されていないときは、メッセージが届きません!!!” 最初は、主要な仮説は、デバイスとプッシュサーバーに保存されているdesync registrationIdでした。 それを確認するために、デバイスのチェックを行いました。その本質は、アプリケーションがプッシュサーバーに定期的に尋ねることでした：「私のregistratioinIdを持っていますか？」 答え「はい」は、registrationIdが関連する可能性が高いことを保証します。







統計によると、答えは「はい」99.7％です。 これにより、すべてがregistrationId同期で正常であると結論付けることができました。 デバイスとGCMの間の領域で問題を探し始めました。 Samsung S4で、Samsungを許して、画面をオフにして、メッセージが長い遅延（約10〜15分）で到着し始める状況を繰り返し見ました。 同僚であるネットワーク管理者の助けを借りて、デバイスとGCM間のTCP接続がアイドル状態になり、パケットの送信が停止することがわかりました。 このすべての理由は、いわゆる「ハートビート」です。 「ハートビート」は、デバイスとGCMの間のTCP接続を「復活」させるために、一定の時間間隔で1回システムから送信されるpingです（詳細については、 こちらをご覧ください ）。







そして、ハートビートが送信される間隔は非常に長いです。 2014年8月には8分に短縮されたようですが、情報は不正確かもしれません。 インターネットは、いわゆる「プッシュフィクサー」で使用されるソリューションを提供します。 その本質は、ハートビートパケットの送信を手動で開始することです。 しかし、残念ながら、このソリューションはルートデバイスでのみ機能します。







GCMでサポートされているすべてのデバイス（Android上の中国のiPhoneを除く）でインスタントメッセージ配信を実現する楽観的手段は、ますます少なくなっています。 そして、メッセージ配信の遅延に関する問題を解決する必要があります。 ほぼ安定したメッセージ配信を保証できる唯一のことは、サーバーへの独自の接続を維持することです。 しかし、まず、プッシュメッセージの遅延に問題があるデバイスを特定する方法を学びたいと思います。 この目的のために、統計を撮影しました。その本質は、プッシュ到着の時間と、サーバー上のクライアントがデータを準備できる時間（プッシュが送信された時間）の差を比較することです。 また、統計によると、ユーザーの約20％がメッセージの配信に遅れをとっています。 しかし、それはむしろ失礼です、なぜなら ネットワークの損失などのケースは考慮されません。 現在、次のアルゴリズムの実装を検討しています。

1. このデバイスに遅延があるかどうかを判断します。
2. はいの場合、バックエンドサーバーとの一定の接続を維持し始めます、いいえ-GCMのみを使用し続けます（バッテリーを節約するため）。

私の頭から10分かかりました。 デルタがしきい値よりも大きい場合、独自の接続を使用してアプリケーションを動作モードに切り替えます。







実験目的で、httpロングポーリング接続によって独自の接続が実装されました。 それは「試す」ための最速の方法でした。 このようなアセンブリは、メッセージの配信とバッテリーの消費を監視する要求とともに、ベータユーザーの一部に送信されました。 一般に、奇妙なことに、バッテリー消費の増加に急激な変化はなく、ユーザーはメッセージ配信の速度に満足しています。 バックエンドサーバーへの独自の接続を実装するトピックは、別の記事に値するものであり、実装自体については引き続き検討します。



この記事が有用であり、GCMサービスを使用する際の時間を短縮することを望みます。また、アプリケーションでクライアントへのメッセージ配信速度の問題を解決する私の経験を共有できることを嬉しく思います。



PSデバッグのために、テストプッシュサーバーを作成しました。誰かが役に立つかもしれません。 ソースコードはこちらです。