タスクのスケジュール設定

アプリが可視状態を離れても実行し続けるタスクを実行する場合は、Jetpack ライブラリの WorkManager を使用することをおすすめします。WorkManager には、アプリの再起動やデバイスの再起動後もタスクを保持できる堅牢なスケジューリング メカニズムが備わっています。

著作物の種類

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

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

図 1 に、さまざまなタイプのタスク間の関係を示します。

図 1: 処理の種類。

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

タイプ	周期性	アクセス方法
即時	1 回限り	OneTimeWorkRequest と Worker。優先処理の場合、OneTimeWorkRequest で setExpedited() を呼び出します。
長時間実行	1 回限りまたは定期的	任意の WorkRequest または Worker。ワーカーで setForeground() を呼び出して通知を処理します。
Deferrable	1 回限りまたは定期的	PeriodicWorkRequest、Worker。

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 を使用する

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

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

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

他の API との関係性

次の表に、WorkManager と類似の API の関係を示します。この情報は、アプリの要件に適した API を選択する際に役立ちます。

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

非推奨 API を置き換える

WorkManager API は、FirebaseJobDispatcher や GcmNetworkManager など、以前の Android バックグラウンド スケジューリング API の代替策として推奨されています。

注: FirebaseJobDispatcher と GcmNetworkManager の API 呼び出しは、Android Marshmallow（6.0）以降を搭載したデバイスでは機能しなくなります。移行方法については、FirebaseJobDispatcher と GcmNetworkManager の移行ガイドをご覧ください。

始める

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

参考情報

以降のセクションでは、その他のリソースについて説明します。

動画

• Workmanager - MAD スキル、動画シリーズ
• WorkManager の操作（2018 年の Android Dev Summit）
• WorkManager: 基本から応用へ（2019 年の Android Dev Summit）

ブログ

• WorkManager の紹介

サンプル