不安定なGoogle C2DMに対処する方法

職場で、同じ志を持つ小さなチームで、スマートフォン、特にiPhoneとAndroid向けのアプリケーションを作成しました。



私たちはiPhoneの開発から始めました。すべてがスムーズに機能するはずでした。

何がうまくいきましたか？ アプリケーションの主なタスクは、「Where are you？」というリクエストを送信することでした-複雑なことは何もありません。 しかし、私は本当にこのリクエストを可能な限り迅速に受信者に届けたいと思っています。 ここでは、iPhone向けの開発の経験がある読者は、 APNサービスがあり、絶対に正しいと言います。 それを使用したのは私たちであり、悲しみを知りませんでした。これらの通知は1秒よりも早く配信されたためです。



その後、いくつかの内部的な理由により、Android開発に切り替えて、すべてをすばやく移植しました。 特に、何も考えずに、 APNモジュールはC2DMを備えた同様のモジュールに置き換えられました。



開発者のすべての電話での通知の配信に問題はありませんでした。 しかし、新しいユーザーはすぐに大きな問題に直面しました。通知の配信時間は保証されておらず、数時間で届く人もいました。 そして、同じデバイスで、数秒で到達しました。



この問題を調査しているときに、Googleからのこれらの通知の操作に関する多くの奇妙な機能に出会いました。





スマートフォンとサーバーとの実装された低レベルの対話に無関心に興味がある人は、これらの前提条件をスキップしてセクション「4。 Google C2DMの代替品ですが、代替品ではありません。」

1.通知を使用するスキーム

まず第一に、シェムカ（指定はGOSTによるものではなく、明確にするために選択されています）：



問題を研究するには、化合物1、2、および3がどのように機能するかを理解する必要があります。

1. これは、リクエストを送信するオープンHTTP接続です。 アプリケーションはサーバーに200 OKのみを期待し、残りは重要ではありません。 ボトルの広い部分があります-これまでのところユーザーはほとんどなく、リクエストを送信しません（アクティブな作業中に60-100メッセージ/秒）。
2. サーバーは、 HTTPを介してこの接続をGoogleのサーバーに開きます。 この場合、2つの連続した接続を作成する必要があります。最初に、推奨されるメソッドであるClientLoginによる認証、次にandroid.clients.google.com/c2dm/sendへのリクエストです。 彼らが最初に問題を探し始めたのはここです。
3. 最後に、この接続はGoogle自体とAndroidスマートフォンを保持します。

2. C2DMへのリクエストに関する問題を探しています

私は主にサーバー側を開発しているので、最初の石は接続番号2で起こりうる問題のために飛び込んできました。 何がされましたか？



私の謙虚な意見では、アプリケーションでC2DMを接続する方法の最良の説明はhabratopicにあります。Cloudto Device Messaging（C2DM）をサポートするAndroidアプリケーションを作成しています。



この接続自体は、この記事の推奨事項に従って実装されます。



Googleサーバーに接続するときにConnectionがタイムアウトすることがあり、同時接続の数を制限するという考えに至りました。 考えは間違っているかもしれませんが、適用されたソリューションは有用であることが判明しました。

サーバー側はJavaで記述され、Jettyが組み込まれた別個のJARとして実行されます。 Spring Frameworkはセットアップと実行を担当します。つまり、 C2DMサーバーとのやり取りを非常に簡単に再構成できました。

ステップ1

クエリの実行に非同期性を追加します。

public class C2DMServer implements IPushNotificator, IPushChecker { ... @Override @Async //     public void sendData(String deviceId, String c2dmID, String jsonObject) { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このステップにより、ストリームがGoogle通知サーバーからの応答を待たないため、要求クライアントへの200 OK応答がさらに高速になりました。

ステップ2

制限に合わせて、Googleへの同時リクエストの数を設定します。

多くのテストと係数の選択があり、結果はそのようなSpring設定になりました。

 <task:annotation-driven executor="asyncExecutor" /> <task:executor id="asyncExecutor" pool-size="15" queue-capacity="300" rejection-policy="CALLER_RUNS" />
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

pool-sizeが15を超える値に設定されている場合、この同時接続数により、あらゆる種類のネットワークエラーが発生します。

まとめ

嬉しいこと ：Googleサーバーへの接続中にエラーはもうありませんでした。

動揺 ：配信速度の問題が残りました。

3. AndroidでGoogleの仕事を探る

Androidにインストールすると、どのアプリケーションでも、通知の送信に使用する特別なサービスから識別子を要求できます。



これは、基本クラスC2DMBaseReceiverから継承することにより行われます。

同じhabtopopでそのような継承の例を見ることができます.Cloud to Device Messaging（C2DM）をサポートするAndroidアプリケーションを作成しています 。 これは私のために修正された実装です：

 import com.google.android.c2dm.C2DMBaseReceiver; public class C2DMReceiver extends C2DMBaseReceiver { private static final String DATA = "data"; public C2DMReceiver() { super(Settings.C2DM_ACCOUNT); } @Override public void onDestroy() { super.onDestroy(); } @Override public void onError(Context context, String errorId) { Settings.Init(context, false); Settings.updateC2DM(null); } @Override protected void onMessage(Context context, Intent receiveIntent) { Settings.Init(context, false); String data = receiveIntent.getStringExtra(DATA); JSONUtils.processJSON(context, data); } @Override public void onRegistered(Context context, String registrationId) { Settings.Init(context, false); if (!registrationId.equals(Settings.getC2dm_id())) Settings.updateC2DM(registrationId); } @Override public void onUnregistered(Context context) { } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、設定は、アプリケーションの状態を格納するための静的フィールドとメソッドの束を持つヘルパークラスです。 JSONUtilsは、JSONを解析し、すべてのデータを設定に保存する別のヘルパークラスです。



理解することが重要なのは、識別子を受け取った瞬間が定義されていないことです。 実際、このクラスでは、 C2DM識別子を受信するイベントをただ待っているだけであり、理論的には、トリガーされたときに、すぐに識別子をサーバーに転送する必要があります。

このような識別子の例：«APA91bF8hral5wCq_E7HPD1wq29aSIEYyY2g_P4BOue_CaBTJvTHKFPplmp2MHxFgn3c1ysNjTHyXmsp8OejRSc809ZiOYqNcXoJWiWfvarCayT6ar3RyZwRRV0CrgQNaPjLxTrYqXXcQfcxjB07xmjeNtUzc6UlGQ»。



その後、この識別子を持つC2DMサーバーへのメッセージは、目的のデバイスとアプリケーションに配信される必要があります。



これらのメッセージがどのように配信されるかを見てみましょう







すべての中心にあるのは、クラウドからデバイスへのメッセージングです。

興味深いことに、問題のあるデバイスでは、このサービスがメモリからアンロードされることがありました。 これは、 OSロックを取得せず、Androidがリソースを必要とするときにオフになる可能性があることを意味します。 このサービスは、GTalkも依存するGoogleメッセージングサービスを交換プロトコルのコアとして使用します。 これは、 C2DMプロトコルがGTalkが交換するXMPPプロトコルにカプセル化されているためです。 このチャネルでは、300秒ごとに1回、 C2DMサービスはPingをGoogleサーバーに送信し、Ackを待機して、接続が正常であることを確認します。 詳細については、このビデオのソースを参照してください。

もちろんサービスでは、すべてがそれほど悲しくありません。 通知サービスは、常にではありませんが、ネットワークの状態が変化したとき、および画面がオンになったときに回復できます。

接続の状態を確認するには、 *#*#8255#*#*



をダイヤルし、開いたGTalkサービスモニターで、Googleメッセージングを介して交換されたアプリケーションを確認します。



そのため、問題の一部が特定されましたが、解決策はありませんでした。

なぜ正確に部品なのか？ とにかく、サービスを実行しても通知が届かないためです。 ある時間（20〜40分）後に、すべてのデバイスが同時に異なる時間に送信された通知を受信したときに、通知の波が時々あった。



その結果、ドキュメント、多くのフォーラム、Q＆Aを読んで考えた後、すべてが1つのことに同意しました。代わりの通知チャネルを作成します。

4. Google C2DMの代替 、ただし代替ではない

主な質問：安定したサーバー/クライアントチャネルを構築する方法は？

副次的な質問：このチャンネルでユーザーのバッテリー全体を食べないようにする方法は？



インスピレーションの源はhttp://code.google.com/p/android-random/の例でした。

特に、例はKeepAliveServiceです。



最初のアイデアは、正面からのソリューションです。n秒に1回、サーバーへの接続を開き、通知を確認します。

「頻繁にサーバーを照会する」というこの正面からのソリューションの代わりに、著者はより合理的なオプションを提案しますが、それは一種のハックのように見えます。



提案されたソリューションのチップ：

• サーバーへの接続は常に維持する必要があり、間隔を置いて再接続しないでください。
• n秒（n> 60）ごとに、何かを送信して接続の状態を確認し、壊れている場合にのみ再接続します。
• サーバー接続でブロッキング読み取りを使用します。

クライアント通知サーバーを操作するためのさまざまなオプションをテストしました。

2つのクライアントが作成されました。

1. n秒に1回開き、何かが現れたかどうかを読みました。 テストで変化したのはnでした
2. 永続的な接続を開き、60秒ごとに確認しました。 ライフタイムの違いを知るために、デバイスはさまざまでした。

最初のクライアントを独立して実装することは難しくありません。 2番目のすべての微妙な点は、アーカイブで見ることができます 。 これには、2番目のタイプのAndroidクライアントと接続をサポートするサーバーが含まれ、クライアントのすべてのキープアライブメッセージをログに表示し、ランダムな理解に従って1分に1回クライアントに通知を送信します。 android-maven-pluginが接続された状態で、すべてがMavenによって収集されます。

	顧客1				クライアント2
装置	欲望	欲望	欲望	欲望	欲望	山火事	欲望s
テスト期間（分）	540	1273	845	962	1117	1180	1121
ユニット消費	82	87	31	9	39	80	49
数秒でキープアライブ	10	30	60	60	60	60	60
インターネット接続	3G	3G	3G	Wifi	3G	3G	3G
計算された放電率（e.z./h）	10	4.28	2.22	0.56	2.22	4.28	3

いくつかの結果がすぐに明らかになります。

1. 少なくとも接続を開いたままにして、接続を再開しますが、バッテリーの観点からは問題ではありません。
2. 3GはWiFiよりも何倍も速くバッテリーを燃やします。
3. 最適なポーリング時間は60秒です。

私たちにとって最も重要なのは最初の結果です。 このことから、機能に応じて2つのクライアントから選択する必要があります。 再接続クライアント（No. 1）の場合、通知は指定された検証間隔で1回だけ送信されます。 接続をサポートするクライアント（No. 2）は、サーバーが開いている接続に書き込むときに通知を受け取ります。 さらに、将来を見据えて、サーバーからのメッセージが開いている接続に到達すると、眠いデバイスでさえ起動すると言います。



TCP接続の流入に耐えるために、次のアーキテクチャを構築しました。





通知サーバーは、2つのコンポーネントで構成されています。

• ルーター-接続されたデバイスを登録し、接続を維持するサーバーのアドレスとポートを提供します。 さらに、彼は通知を送信するためのすべての要求を目的の通知サーバーにルーティングします。
• 通知サーバー自体-接続を維持し、デバイスからキープアライブを正常に受信したことをルーターに通知し、ルーターが呼び出した場合に通知を送信します。

クライアントとのすべての対話は、純粋なTCPで行われます 。 通知自体のサイズと内容は任意ですが、アプリケーションの負荷を軽減するために、正確に1バイトの「1」を送信します。

サーバーコンポーネント間で、Spring Remotingを使用すると、 RMI接続が増加します。



クライアント側のロジックを段階的に見てみましょう。

1. 通知サーバーに接続すると、クライアントは一意の識別子を報告します 。私の場合は、単なるGUIDです。
2. それに応じて、彼は接続を開いて維持するアドレスとポートを受け取ります。
3. ソケットを開いた後、クライアントは読み取りタイムアウトを設定せずに読み取りをブロックします。
4. AlarmManagerを使用して、クライアントは60秒ごとに起動し、 GUIDを使用してメッセージを開いている接続に送信します。 そのため、サーバーはどの種類のクライアントがまだ生きているかを見つけます。
5. 接続が切断されると、クライアントはインターネットへのアクセスを確認し、可能な場合は再接続します。
6. readがデータを返した場合、通知が到着し、アプリケーションロジックの残りに報告され、クライアントは再び読み込みをブロックします。

AlarmManagerの操作は非常に簡単です。

 //  ,       Intent i = new Intent(this, NotificationService.class).setAction(ACTION_KEEPALIVE); PendingIntent pi = PendingIntent.getService(this, 0, i, 0); //      AlarmManager- AlarmManager alarmMgr = (AlarmManager) getSystemService(ALARM_SERVICE); alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + KEEP_ALIVE_INTERVAL, KEEP_ALIVE_INTERVAL, pi);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ドキュメントの詳細。

実装の結果と問題、またはC2DMを完全に放棄することが不可能な理由

• 明るさを最大にするために、すべての通知サーバーはファイルまたはデータベースのいずれとも機能しません。 したがって、最初の結果：通知が届かなかった場合、届きません。
• 通知サーバーは、ルーター内のデータについて何も知りません。 2番目の結果：クライアントはルーターに従う必要がなく、指定されたアドレスとポートに正確に移動する必要がありません。つまり、クライアントは1つの通知サーバーに攻撃を仕掛け、他のサーバーはアイドル状態になります。
• ルータは、キープアライブがクライアントからいつ来たかを記憶します。 有用な3番目の結果：ルーターはこの情報を外部システムに伝えることができ、この情報は基本的に誰が現在オンラインになっているかの記録です。
• ルーターは、クライアントがキープアライブを送信した通知サーバーを記憶しています。 4番目の結果：クライアントが間違ったサーバーに接続した場合でも、ルーターはすべてのサーバーにこのパケットを送信する代わりに、どの通知サーバーを介してパケットを送信するかを認識します。

5.結論

「自尊心のあるスマートフォンプログラマは、通知サービスの独自の実装を作成する必要があります」-これは、私の仕事の結果を冗談で説明する方法です。

しかし、ジョークにもかかわらず、上記の通知サービスはAppleと同じ速度とほぼ同じ安定性で動作しますが、これは喜ばしいことであり、開発者が非常に心配するデバイスの寿命はそれほど短縮されません。

6.便利なリンク

適切な通知配信を実装する方法についての考え

Google C2DM接続ドキュメント

Habratopik「Cloud to Device Messaging（C2DM）をサポートするAndroid用アプリケーションを作成しています」

C2DMやその他の 速度に関する苦情 -いつか、彼らの中に「万歳！ すべてうまくいきました！」