永続処理 Android Jetpack の一部。

アプリの再起動やシステムの再起動後もスケジュールが維持されている場合、処理は永続的です。永続処理に推奨されるソリューションは WorkManager です。ほとんどのバックグラウンド処理は永続処理によって行うのが最適であるため、WorkManager は、一般的にバックグラウンド処理に推奨される主要な API でもあります。

永続処理の種類

WorkManager は、次の 3 種類の永続処理を扱います。

  • 即時: すぐに開始してすぐに完了する必要があるタスク。優先されることがあります。
  • 長時間実行: 10 分以上(場合によっては 10 分以上)実行される可能性のあるタスク。
  • 延期可能: 後で開始して定期的に実行できる、スケジュール設定されたタスク。

図 1 に、種々の永続処理の間の関係を示します。

永続処理には、即時、長時間実行、延期可能がある
図 1: 永続処理の種類

同様に、次の表にさまざまな処理の概要を示します。

タイプ 周期性 アクセス方法
即時 1 回限り OneTimeWorkRequestWorker優先処理が必要な場合は、OneTimeWorkRequest で setExpedited() を呼び出します。
長時間稼働 1 回限りまたは定期的 任意の WorkRequest または Worker。Worker で setForeground() を呼び出して通知を処理します。
延期可能 1 回限りまたは定期的 PeriodicWorkRequestWorker

WorkManager の設定方法について詳しくは、WorkRequest の定義ガイドをご覧ください。

WorkManager の機能

WorkManager には、よりシンプルで一貫性のある API を提供するという点だけでなく、次のような重要なメリットがあります。

処理の制約

処理の制約を使用して、処理の実行に最適な条件を宣言的に定義します。たとえば、デバイスが定額制ネットワークにつながっているとき、アイドル状態のとき、バッテリー残量が十分であるときにのみ実行します。

強力なスケジュール設定

WorkManager では、柔軟なスケジューリング ウィンドウを使用して、1 回限りまたは繰り返し実行するように処理のスケジュールを設定できます。処理にタグや名前を付けて、一意で置き換え可能な処理のスケジュール設定、処理グループのモニタリングやキャンセルをまとめて行うことができます。

スケジュール設定された処理は、内部で管理されている SQLite データベースに保存されます。WorkManager により、デバイスの再起動後もこの処理が確実に保持され、スケジュールの再設定が行われます。

また、WorkManager は Doze モードなどの省電力機能やベスト プラクティスに従うため、電力消費を気にする必要はありません。

優先処理

WorkManager を使用すると、バックグラウンドでの実行の即時処理をスケジュール設定できます。ユーザーにとって重要な、数分以内に完了するタスクには、優先処理を使用する必要があります。

柔軟な再試行ポリシー

処理は失敗することもあります。WorkManager には、設定可能な指数バックオフ ポリシーなど、柔軟な再試行ポリシーが用意されています。

処理の連結

複雑な作業の場合は、直感的なインターフェースを使用して個々の処理タスクを連結することにより、どの部分を順次実行し、どの部分を並列実行するかを制御できます。

Kotlin


val continuation = WorkManager.getInstance(context)
    .beginUniqueWork(
        Constants.IMAGE_MANIPULATION_WORK_NAME,
        ExistingWorkPolicy.REPLACE,
        OneTimeWorkRequest.from(CleanupWorker::class.java)
    ).then(OneTimeWorkRequest.from(WaterColorFilterWorker::class.java))
    .then(OneTimeWorkRequest.from(GrayScaleFilterWorker::class.java))
    .then(OneTimeWorkRequest.from(BlurEffectFilterWorker::class.java))
    .then(
        if (save) {
            workRequest<SaveImageToGalleryWorker>(tag = Constants.TAG_OUTPUT)
        } else /* upload */ {
            workRequest<UploadWorker>(tag = Constants.TAG_OUTPUT)
        }
    )

Java


WorkManager.getInstance(...)
.beginWith(Arrays.asList(workA, workB))
.then(workC)
.enqueue();

処理タスクには、それぞれ入出力データを定義できます。処理を連結すると、WorkManager により、ある処理タスクの出力データが自動的に次の処理タスクに渡されます。

組み込みのスレッド化の相互運用性

WorkManager はコルーチンRxJavaシームレスに統合し、独自の非同期 API に接続するための柔軟性を提供します。

処理の信頼性を高めるために WorkManager を使用する

WorkManager は、ユーザーが画面から移動した場合、アプリが終了した場合、デバイスが再起動された場合でも、確実に実行する必要がある処理を対象としています。次に例を示します。

  • ログやアナリティクスをバックエンド サービスに送信する
  • アプリデータをサーバーと定期的に同期する

WorkManager は、アプリプロセスが終了しても安全に終了できるインプロセス バックグラウンド処理を対象としていません。また、直ちに実行する必要があるすべての処理を対象とした一般的なソリューションでもありません。バックグラウンド処理ガイドでニーズを満たすソリューションを見つけてください。

他の API との関係性

コルーチンは特定のユースケースで推奨されるソリューションですが、永続的な処理には使用しないでください。コルーチンは同時実行フレームワークであるのに対し、WorkManager は永続処理のためのライブラリであることに注意してください。同様に、AlarmManager は時計またはカレンダーにのみ使用してください。

API 対象 WorkManager との関係
コルーチン 永続的である必要のない非同期処理。 コルーチンは、Kotlin でメインスレッドを離れる標準的な方法です。ただし、アプリが閉じられるとメモリを離れます。永続処理には WorkManager を使用します。
AlarmManager アラームのみ。 WorkManager とは異なり、AlarmManager はデバイスを Doze モードから復帰させます。そのため、電源とリソースの管理という点では効率的ではありません。バックグラウンド処理ではなく、正確なアラームやカレンダーの予定などの通知にのみ使用します。

非推奨の API を置き換える

WorkManager API は、以前の Android バックグラウンド スケジューリング API のすべて(FirebaseJobDispatcherGcmNetworkManagerJobScheduler など)の代替として推奨される API です。

始める

アプリで WorkManager の使用を開始するには、スタートガイドをご覧ください。

参考情報

以下のセクションでは、その他のリソースをいくつか紹介します。

動画

ブログ

サンプル