永続処理 Android Jetpack の一部。

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

永続処理の種類

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

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

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

図 1: 永続処理の種類

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

タイプ	周期	アクセス方法
即時	1 回限り	OneTimeWorkRequest と Worker。優先処理については、OneTimeWorkRequest で setExpedited() を呼び出します。
長時間実行	1 回限りまたは定期的	任意の WorkRequest または Worker。Worker で setForeground() を呼び出して通知を処理します。
延期可能	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 は 説明します。同様に、AlarmManager は時計またはカレンダーにのみ使用してください。

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

非推奨の API を置き換える

WorkManager API は、以前のすべての Android バックグラウンド スケジューリング API（FirebaseJobDispatcher など） GcmNetworkManager、JobScheduler。

注: yourFirebaseJobDispatcher と GcmNetworkManager の API 呼び出しは、 Android Marshmallow（6.0）以降を搭載しているデバイスで動作します。詳しくは、 FirebaseJobDispatcher および GcmNetworkManager の移行ガイド をご覧ください。また、バックグラウンド タスクのスケジュール設定の統合に関する Android のお知らせをご覧ください。

始める

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

参考情報

以降のセクションでは、その他の参考情報を紹介します。

動画

• Workmanager - MAD スキル、動画シリーズ
• WorkManager の操作（2018 年の Android Dev Summit）
• WorkManager: 基本を超えて（2019 年の Android Dev より） サミット

ブログ

• WorkManager の紹介

サンプル