Androidアプリケーションが実装されているフレームワーク内のサービスは、プッシュ通知の操作に関してかなり厳しい要件を提示します。 ユーザーに何らかのアクションを通知するのに30〜60秒以内に必要です。 正常に通知されると、ユーザーのデバイスからサーバーに、対応するステータスでリクエストが送信されます。 ドキュメントから、GCMサービス（Google Cloud Messaging）はデバイスへのPUSH通知の配信を保証しないことがわかっているため、バックドアオプションとして、これらの時間枠に違反した場合、当社のサービスはSMSを介してユーザーに通知します。 SMSメッセージのコストはPUSH通知よりもかなり高いため、クライアントデバイスへのSMSメッセージのフローを最小限に抑える必要があります。
ドキュメントを調べてプッシュ通知を台無しにした後、テスト用のアプリケーションの最初のビルドを複数のクライアントに送信し、待ち始めました。 結果はおよそ次のとおりです。
- アクティブなWifi接続により、すべてが完璧に機能します。通知が配信され、顧客は満足します。
- アクティブなモバイルインターネットで、楽しみが始まりました。
一部のクライアントは、プッシュの配信で遅延が発生したか、PUSHとSMSの両方を受信したと書きましたが、これは実用的ではありません。 他の人は、通知をまったく受け取らず、SMSだけを受け取ったと書いています。 3番目のテストデバイスでは、すべてが大丈夫でした。 不満のある顧客から最大限の情報を収集すると、彼らは問題を理解し始め、次の制限リストを推測し始めました（このリストは後に完全なFAQに変わりました）。
- 含まれている省エネモード（たとえば、Sonyデバイスのスタミナ）は、プッシュ通知の操作に影響します。
- ユーザーは、デバイス上に少なくとも1つのアクティブなGoogleアカウントを持っている必要があります。
- Google Play Servicesアプリケーションの最新バージョンがデバイスにインストールされていることを確認する必要があります。
- アプリケーションの通知が無効になっているかどうかを確認します（電話設定のアプリケーションページのチェックマーク）。
- バックグラウンドモードがアプリケーションに対して制限されているかどうかを確認します（設定は[データ使用法]メニューにあります）。
- GCMのドキュメントでは、通知は特定のポートにのみ送信されるため、ルーター、ファイアウォール、およびウイルス対策の設定も考慮する必要があると記載されています。
このメモをすべての顧客に送信した後、再び結果を待ち始めました。 そして、彼らは再び「それほどではない」ことが判明しました。 彼らはさらに掘り始めました。
この段階では 、Mail.ruのメンバーが書いた記事が大いに役立ちました。 クライアント側でGCMを実装することの微妙な点と、モバイルネットワークでのプッシュ通知が機能しなくなる瞬間について詳しく説明します。 最終的に、GCMとともにサーバーへの接続を維持することが決定されました。
決定を進める前に、潜在的に「機能しない」デバイスの範囲を絞り込むことができるいくつかの非常に重要なポイントを強調する価値があります。
- この問題は、モバイルインターネットに接続している場合にのみ発生します。
- 顧客によると、問題はandroid 4以降のバージョンで発生します。
それでは、実装に移りましょう。
経験豊富なAndroid開発者は、問題に対して少なくとも2つの解決策があるとすぐに言います：ServiceまたはAlarmManagerを使用します。 両方のオプションを試しました。 最初のものを検討してください。
バックグラウンドで絶えずハングし、タスクを実行するシステムで壊れないサービスを作成するために、次のメソッドを使用しました。
startForeground(int notificationID, Notification notification);
どこで
- notificationId-ステータスバーと移動カーテンに表示される一意の通知識別子。
- 通知-通知自体。
この場合、前提条件はステータスバーに通知を表示することです。 このアプローチにより、デバイスのメモリ不足時にサービスの優先度が高くなり（システムのUI部分と対話するため）、システムは最後の1つをアンロードします。 この通知は必要ないため、次の自転車を使用しました。最初のサービスと同時に2番目のサービスを実行し、両方のサービスでnotificationIDと同じ値を使用するだけで十分です。 次に、2番目のサービスを強制終了します。 この場合、通知はステータスバーから消えますが、最初のサービスの機能および優先機能は残ります。
このアプローチを実装したら、アセンブリをテストに送りました。 結果によると、システムはまだサービスをアンロードしていることが判明し、ログによると、サーバーからバックグラウンドでデータを要求する際に一時的なギャップがどのように発生したかがわかりました。 そのため、2番目のオプションであるAlarmManagerの実装を開始しました。
AlarmManagerは、大まかに言って「目覚まし時計」で作業を提供するクラスです。 これにより、システムがブロードキャスト通知を送信する時間を指定できます。ブロードキャスト通知により、アプリケーションを起動し、必要なアクションを実行できるようになります。 このメソッドの操作にはいくつかの制限があり、それらを処理する必要があります。
- アラームに関するデータは、デバイスの再起動後に消去されます。
- アラームに関するデータは、アプリケーションの更新後に消去されます。
最初に踏んだレーキはメソッドでした
setRepeating()
これにより、一定の間隔で繰り返し目覚まし時計を設定できます。 この方法を台無しにして、彼らはテストを始めました、そして、テストは反対を示しました-「アラーム」は繰り返されませんでした。 彼らは何が起こっているのかを理解し始め、文書を見ました。 そして、19 API lvl（Kitkat）から始まって、システムのすべての「アラーム」が一度きりになりました。 結論-常にドキュメントをお読みください。
このレーキはフラストレーションの原因ではありませんでした。問題の解決策は非常に単純であるためです。1回限りの「アラームクロック」を開始し、操作後にリセットするためです。 このアプローチを実装すると、次のレーキに出くわしました。APIの異なるレベルでは、ドキュメントには何も記載されていないものの、アラームを異なるように設定する必要があることがわかりました。 しかし、この問題は非常に簡単に解決されました-「タイピング」と「グーグル」の方法によって。 以下は、「アラーム」を正しく設定できるようにするコードの例です。
private static void setUpAlarm(final Context context, final Intent intent, final int timeInterval) { final AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE); final PendingIntent pi = PendingIntent.getBroadcast(context, timeInterval, intent, 0); am.cancel(pi); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { final AlarmManager.AlarmClockInfo alarmClockInfo = new AlarmManager.AlarmClockInfo(System.currentTimeMillis() + timeInterval, pi); am.setAlarmClock(alarmClockInfo, pi); } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) am.setExact(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + timeInterval, pi); else am.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + timeInterval, pi); }
AlarmManager.RTC_WAKEUPフラグに注意を払いたいです。画面が非アクティブなとき、デバイスがロックされた状態のときに、システムがアプリケーションを「ウェイクアップ」できるようにするのは、それの助けを借りてです。
「アラーム」を使用したこのアプローチにより、望ましい結果が得られました。バックグラウンドのアプリケーションは、新しいデータを求めてサーバーを正しくポーリングします。 現在、アルゴリズムを完成させています。 現在、次の最適化を実装およびテストしています。これにより、デバイスの範囲が狭まり、サーバーの負荷が軽減されます。
- GCMからデバイスに送信されるメッセージには、一意のIDが含まれています。
- バックグラウンドでGETデータを受信すると、このIDを持つレコードがデバイス上にすでに存在するかどうかを確認します。
- そのようなデータがデバイス上にローカルにない場合、このIDと受信時刻T1を覚えています。
- 受信時に同じIDのPUSHを待ち、時間T2を覚えて、T2とT1の違いを確認します。
- 差が特定の時間基準（値）よりも大きい場合、デバイスでの通知の配信に問題があり、サービスの正しい動作のために、サーバーからバックグラウンドでデータを常に要求する必要があります（解決する問題に基づいて基準を選択することをお勧めします。この場合、基準は5分）;
- この差は数回、たとえば5〜10回計算する必要があります。その後、デバイスに実際にプッシュ通知の受信に関する問題があると結論付けます（これにより、通常の切断、タイムアウトなどの状況がなくなります）。
- このアルゴリズムを定期的に実行する必要があります（たとえば、週に1回、またはデバイスのOSを更新した後）。
すべてに良い。 そして、そのような松葉杖が少なくなります。
PS
テストプロセスでは、 ツールが非常に役立ちました。これにより、送信されたプッシュに関する情報を見ることができます。 このツールは、開発者が無料で利用できます。 誰もが使用することをお勧めします。
Pss
私はおそらくコメントにバッテリー消費に関する質問があるだろうと予測しています。 私はいくつかのテストを実施しましたが、モバイルインターネットをオンにして、夜は個人の電話を残しました。 結果は、8〜9時間で充電の20〜25％程度でした。 また、テストアセンブリを送信したクライアントは、バッテリー消費の増加に伴う問題について不満はありませんでした。