Android 11 デベロッパー プレビュー 2 が公開されました。ぜひお試しのうえ、フィードバックをお寄せください

バックグラウンド処理ガイド

Android アプリごとにメインスレッドが 1 つ存在します。メインスレッドは UI の処理(ビューの測定、描画など)、ユーザー操作の調整、ライフサイクル イベントの受信を行います。このスレッド上に過度に多くの処理が生じると、アプリはハングまたは処理速度が低下しているように見え、ユーザー エクスペリエンスを損ねます。ビットマップのデコード、ディスクへのアクセス、ネットワーク リクエストなどの長時間実行の計算は、別のバックグラウンド スレッドで行う必要があります。一般的に、数ミリ秒以上かかるものはバックグラウンド スレッドに委任します。タスクによっては、ユーザーがアプリを操作している間に実行する必要があります。アプリの操作中にバックグラウンド スレッドとメイン UI スレッドからタスクを実行する方法については、スレッド ソリューション ガイドをご覧ください。

ユーザーがアプリを頻繁に使用していないときでも、アプリケーションで一部のタスクを実行する必要がある場合もあります(バックエンド サーバーとの定期的な同期やアプリ内での新しいコンテンツの定期的な取得など)。ユーザーがアプリの操作を完了した後でも、サービスがすぐに完全に処理する必要がある場合もあります。このガイドでは、こうした使用例のニーズに最適なソリューションについて説明します。

バックグラウンド処理における課題

バックグラウンド タスクは、RAM や電池などデバイスの限られたリソースを消費します。正しく処理しないと、ユーザーの利便性が低下する可能性があります。

電池を最大限に活用してアプリの動作を強化するため、Android はアプリ(またはフォアグラウンド サービス通知)がユーザーに表示されない場合、バックグラウンド処理を制限します。

  • Android 6.0(API レベル 23)では Doze モードとアプリ スタンバイが導入されました。Doze モードでは、画面がオフで、デバイスが静止状態の場合、アプリの動作が制限されます。アプリ スタンバイでは、未使用のアプリケーションをネットワーク アクセス、ジョブ、同期が制限される特殊な状態に移行します。
  • Android 7.0(API レベル 24)では暗黙的なブロードキャストが制限され、Doze-on-the-Go が導入されました。
  • Android 8.0(API レベル 26)ではさらに、バックグラウンドでの位置の取得やキャッシュされたウェイクロックの解放など、バックグラウンド動作が制限されています。
  • Android 9(API レベル 28)では、アプリ スタンバイ バケットが導入されました。アプリの使用パターンに基づいてリソースのアプリ リクエストが動的に優先されます。

タスクのニーズを理解し、バックグラウンド ジョブをスケジュールする際にシステムでのおすすめ方法に合った適切なソリューションを選択することが重要です。

処理に合ったソリューションを選ぶ

  • 処理を延期できるか、それともすぐに行う必要があるか。たとえば、ユーザーによるボタンのクリックに応じてネットワークからデータを取得する必要がある場合、その処理はすぐに行う必要があります。ただし、ログをサーバーにアップロードする場合は、アプリのパフォーマンスやユーザーの期待に影響を与えずに、その処理を延期できます。

  • 処理はシステムの状態に依存するか。デバイスが電源に接続されている、インターネットに接続されているなどの特定の条件を満たす場合にのみ、ジョブを実行できます。たとえば、アプリで定期的に保存データを圧縮することが必要になる場合があります。ユーザーへの影響を避けるために、デバイスが充電中でアイドル状態のときにのみ、このジョブを実行するようにします。

  • ジョブは正確な時間に実行する必要があるか。カレンダー アプリで、特定の時間にイベントのリマインダーを設定できる機能を提供しているとします。ユーザーは、正しい時間にリマインダー通知が表示されるものと想定します。それ以外の場合、ジョブがいつ実行されるかをアプリが厳密に重視するとは限りません。アプリには「最初にジョブ A、次にジョブ B、その後にジョブ C を実行」のような一般的な要件がありますが、特定の時間にジョブを実行する必要はありません。

図 1. バックグラウンドでの処理に最適な方法はどれか。

WorkManager

遅延可能であり、デバイスまたはアプリが再起動しても実行が想定される処理の場合は、WorkManager を使用します。WorkManager は Android ライブラリです。処理の条件(ネットワークの可用性や電力など)が満たされると、遅延可能なバックグラウンド処理を適切に実行します。

WorkManager は、下位互換性のある API レベル 14 以上の API を提供します。また、JobScheduler API(API レベル 23 以上)以降の API を利用して、電池寿命とバッチジョブ、下位デバイスでの AlarmManagerBroadcastReceiver の組み合わせを最適化します。

フォアグラウンド サービス

ユーザーが開始した処理で、すぐに実行して完了まで行う必要がある場合、フォアグラウンド サービスを使用します。フォアグラウンド サービスを使用すると、アプリは重要な処理を行っているため強制終了しないように、システムに指示できます。フォアグラウンド サービスは、通知トレイの非表示にできない通知を介してユーザーに表示されます。

AlarmManager

正確な時間にジョブを実行する必要がある場合は、AlarmManager を使用します。AlarmManager は、必要に応じてアプリを起動して、指定した時間にジョブを実行します。ただし、ジョブを正確な時間に実行する必要がない場合は、WorkManager をおすすめします。WorkManager の場合、システム リソースのバランスをとることができます。たとえば、1 時間ごとにジョブを実行する必要があるが、特定の時間に実行する必要がない場合は、WorkManager を使用して定期的なジョブを設定します。

DownloadManager

実行時間が長い HTTP ダウンロードをアプリが実行している場合は、DownloadManager を使用することを検討してください。クライアントは、アプリプロセスの外部にある特定の宛先ファイルに URI をダウンロードするようリクエストできます。ダウンロード マネージャーはバックグラウンドでダウンロードを行い、HTTP インタラクションを処理して、障害解消後、または接続変更およびシステム再起動後にダウンロードを再試行します。