🚨 👐🏽 🛥️ JobSchedulerとIntentServiceを使用したAndroidでのタスクのスケジューリング 🧑🏾‍🤝‍🧑🏻 👨‍👧‍👦 🉑

Android OS向けに開発する場合、リソースを集中的に使用する操作を定期的、定期的、またはオンデマンドで実行することが必要になる場合があります。これらの操作では、たとえばインターネットを使用したり、デバイスを起動したままにすることが重要です。ほとんどの場合、このような問題を解決するには、AlarmManager、WakefulBroadcastReceiverを使用するか、一般にWakeLockを手動で制御します。これはすべてAndroidの開発者向けのドキュメントでは推奨されておらず、WakefulBroadcastReceiverは既にAPIレベル26.0.0で非推奨としてマークされています。

Googleの推奨事項に従い、省エネにますます注意を払うAndroid 5.0以降のバージョンで、より柔軟な動作をするアプリケーションを作成するにはどうすればよいですか？アプリケーションの最小APIレベル21.0.0を設定する準備ができている場合は、JobSchedulerをIntentServiceと組み合わせて使用して、労働集約的なタスクを順番に実行する例をお勧めします。

問題と提起された問題の本質

WakefulBroadcastReceiverクラスのドキュメントを開いて興味深い状況を確認するだけで十分です。クラスはAPIバージョン22.0.0で追加され、バージョン26.0.0で非推奨としてマークされました。 Android開発者は、最初にWakeLockを保持してタスクを実行するための便利なクラスを追加することを決めたと想定できますが、その後、アプリケーションがフォアグラウンドで動作することを保証するものではなく、実際にすべてのスマートアプリケーションがWakeLockを保持しようとするとデバイスはエネルギーを節約しますか？そして、 WakefulBroadcastReceiverの原理は、とりわけ、正しく閉じられなかったレシーバーがWakeLockのリークにつながる可能性があるため、バッテリー寿命を延長したいという欲求に逆らい始めました。

一方、普通の開発者は、新しい制限すべての下で、たとえばDozeモードがアクティブなときに定期的なタスクを実行するのが安全かどうかを尋ねるかもしれません。制限と機会のバランスをとるために、 JobSchedulerが作成されました。ジョブスケジューラは、タスクをいつ完了することができるか、実際に必要な場合にそれを受け入れる方法を提供する方法、省エネポリシーに違反せず、どこで失わないかという問題を引き受けます-WakeLockを絶対に離さないでください 。

この記事の準備中に、別の著者による記事がHabréに掲載されました。この記事では、もう少し理論が明らかになり、実践に少し注意が払われました。 JobSchedulerの既存の代替案をすばやく開始し、より深く理解するのに役立ちます。

JobSchedulerとIntentServiceを使用してプロジェクトを作成する例

簡単にするために、「Exercise」という単語をファイルに書き込むタスクがあるとします。ただし、ユーザーのモバイルトラフィックを無駄にすることはないため、インターネットが必要です。同時に、新しいタスクごとに、次々に実行される単語を書くようにします。メインスレッドをブロックすることはできず（ここではファイルと、場合によってはネットワークリクエストを処理できます）、タスクを並べることができるため、 IntentServiceが支援します。

この記事で説明されている手順を完全に再現するには、SDK 21の最小バージョンで、アクティビティのない新しいプロジェクトを作成する必要があります。また、すべてのアクションは、少なくとも21のSDKバージョンで既存のプロジェクトで実行できます。

バックグラウンドでタスクを処理するためのIntentServiceの追加

新しいIntentServiceをプロジェクトに追加し、それをExerciseIntentServiceと呼びます。自動的に生成されたメソッドに基づいて標準的なアプローチを使用し、余分なものをクリーンアップし、メソッドと定数を条件に合わせて名前を変更します。

簡単な操作の結果として、 ExerciseIntentServiceの次の本体を取得します。

private static final String ACTION_WRITE_EXERCISE = "com.github.ihandy.jobschedulerdemo.action.ACTION_WRITE_EXERCISE"; public ExerciseIntentService() { super("ExerciseIntentService"); } public static void startActionWriteExercise(Context context) { Intent intent = new Intent(context, ExerciseIntentService.class); intent.setAction(ACTION_WRITE_EXERCISE); context.startService(intent); } @Override protected void onHandleIntent(Intent intent) { if (intent != null) { final String action = intent.getAction(); if (ACTION_WRITE_EXERCISE.equals(action)) { handleActionWriteExercise(); } } } private void handleActionWriteExercise() { try { FileWriter fileWriter = new FileWriter(getFilesDir().getPath() + "exercise.txt"); fileWriter.write("Exercise"); fileWriter.close(); } catch (IOException e) { e.printStackTrace(); } }

したがって、1つのタイプの条件付き労働集約タスクを順番に直接実行するサービスの準備ができています。タスクを作成して計画するには、 BroadcastReceiverを使用できるエントリポイントが必要です。

BroadcastReceiverを追加してタスクを初期化する

標準のBroadcastRecieverツールをプロジェクトに追加し、 ExerciseRequestsReceiverと呼びます。将来的には、タスクをスケジュールするために、どこからでもブロードキャストをアプリケーションに送信できるようになります（たとえば、これは記事の終わり近くに表示されるインストルメンタルテストを使用して実行できます）。

最低限必要なExerciseRequestsReceiverコードは次のようになります。

 public static final String ACTION_PERFORM_EXERCISE = "ACTION_PERFORM_EXERCISE"; private static int sJobId = 1; @Override public void onReceive(Context context, Intent intent) { switch (intent.getAction()) { case ACTION_PERFORM_EXERCISE: scheduleJob(context); break; default: throw new IllegalArgumentException("Unknown action."); } }

String ACTION_PERFORM_EXERCISE

タスクスケジューリングプロセスを開始する必要性を識別するためのアクション。

int sJobId

タスクをスケジュールするときに使用されるタスク識別子の変数。

scheduleJob(context)

-タスクのスケジューリングに必要なすべてのロジックを含むメソッド呼び出し。

これで、ブロードキャストを受信するときに、 Intentを ExerciseIntentServiceに送信でき、すべてが問題なく、 WakeLockのみが必要になります。WakefulBroadcastReceiverを使用しないことに同意したため、 JobSchedulerの新しいタスクを作成およびスケジュールする必要があります。私たちにとって（ほぼ）。

ところで、 JobSchedulerを使用する場合、この問題を解決する他の方法とは異なり、 WakeLockに対する許可は必要ありません。

JobSchedulerからのイベントを処理するためのJobService相続人の実装

JobSchedulerには、 JobServiceから継承された別個のサービスが必要です。それをExerciseJobServiceと呼び、通常のサービスとして追加し、親クラスを置き換え、モジュールマニフェストにアクセス許可を追加します。

 <service android:name=".ExerciseJobService" android:enabled="true" android:exported="true" android:permission="android.permission.BIND_JOB_SERVICE"> </service>

このサービスがJobSchedule rと対話するにandroid.permission.BIND_JOB_SERVICE

権限android.permission.BIND_JOB_SERVICE

必要です。

また、実装には2つのメソッドonStartJob()

およびonStopJob()

が必須です。

onStartJob()

は、スケジュールされたタスクを完了する時間（条件）になると呼び出されます。このメソッドはメインスレッドで呼び出され、開発者は重い操作を個別のスレッドに個別に送信する必要があります（この場合、これは既に提供されています-IntentServiceを使用します）。 onStartJob()

からタスクの実行を他のスレッドに委任する場合、 trueを返す必要があり、必要なすべてのアクションがこのメソッドの本体で既に実行されている場合、 falseを返す必要があります。
onStopJob()

は、タスクに必要な条件が満たされなくなったとき、またはタスクに割り当てられた時間が使い果たされたときに呼び出されます。このメソッドの呼び出しは、すべてのバックグラウンドタスクの実行を直ちに停止する必要があることをサービスに通知します。データの整合性を確保するために、安全なストップランロジックを提供することが最善です。

onStopJob()

状況を適切に処理するために、静的フラグ、いくつかの追加のブロードキャストを実装できます。また、サービス間の対話の他の手段を使用することもできます。現在の記事では、これは省略され、 IntentServiceがタスクを完了できなかった場合、アプリケーションロジックとデータの整合性にとってひどいものは何も起こらないと仮定されます。

onStopJob

も戻り値があり、 trueの場合onStopJob

は中断されたタスクを再び実行キューに入れますonStopJob

タスクは完了したと見なされ、周期的でない場合はキューから削除されます。

緊急事態の処理が省略されているため、このメソッドからtrueを返し、タスクのスケジュールを変更します;同時に、これにより再試行基準の使用を検討することができます。

したがって、2つのメインメソッドの戻り値を設定し、 ExerciseIntentServiceの起動をonStartJob()

に追加することにより、次の十分に容量のあるサービスを取得します。

 public class ExerciseJobService extends JobService { public ExerciseJobService() { } @Override public boolean onStartJob(JobParameters params) { ExerciseIntentService.startActionWriteExercise(getApplicationContext()); return true; } @Override public boolean onStopJob(JobParameters params) { return true; } }

現時点では、 IntentServiceのJobSchedulerを介してタスクを実装するための最小限のクラスセットがすでに準備されています。つまり、 ExerciseIntentService-個別のスレッドでタスクに必要な操作を実行します。外部からブロードキャストをキャッチし、次に行うことであるJobSchedulerのタスクを初期化する必要がある複合体の作業。

JobSchedulerの新しいタスクを作成する

JobSchedulerのタスクを作成するには、 JobInfo.Builderが必要です。そのコンストラクターは2つのパラメーターを受け入れます： ExerciseJobServiceの タスクIDとComponentNameです 。

タスクIDとComponentName

識別子があれば、すべてが単純です（ただし、ニュアンスがないわけではありません）-任意の整数値：

既に計画されているタスクを更新する場合、または定期的なタスクの一意性を制御する場合、永続的。
個々のタスクのキューを作成する場合は一意の値。

UIDの使用上の注意

突然アプリケーションがシステミックである場合、または1つのsharedUserIdを持つ複数のアプリケーションがある場合、追加の条件を考慮する必要があります。idは1つのuidを持つすべてのアプリケーション間で交差してはなりません。したがって、アプリケーションがandroid.uid.systemを使用する場合、一部のシステムタスクもJobSchedulerを使用し、IDの一意性を独立して維持する必要があることに留意する必要があります。

ところで、 removeAll()

ようなJobSchedulerのメソッドを使用する場合、同じuidを持つ他の人のタスクも削除できます。

この状況を制御する方法に関する英語の記事。

この例では、UIDについて心配する必要はなく、増分値sJobIdを識別子として使用します。

sJobIdは次のように定義されます。

 private static int sJobId = 1;

ComponentNameを使用すると、すべてがはるかに単純になり、 ExerciseJobService.classが渡されるコンストラクターへのオブジェクトになります。

 ComponentName jobService = new ComponentName(context, ExerciseJobService.class); JobInfo.Builder exerciseJobBuilder = new JobInfo.Builder(sJobId++, jobService);

JobInfo.Builderを使用したパラメーターの初期化

以下では、JobInfo.Builderメソッドの主要なセットを検討します。

 exerciseJobBuilder.setMinimumLatency(TimeUnit.SECONDS.toMillis(1));

タスクが完了する前に経過する最小時間、つまり遅延開始時間。

```
 exerciseJobBuilder.setOverrideDeadline(TimeUnit.SECONDS.toMillis(5));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
タスクがキュー/スケジュール状態にあることができる最大時間。 5秒後に（この場合）良好な条件がまだ到着していない場合、タスクは何があっても実行され始めます（これが他のJobSchedulerポリシーと矛盾しない場合）。使用しない場合、タスクは必要な条件が満たされた場合にのみ完了します。
```
 exerciseJobBuilder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     
```
接続のタイプが設定されます。たとえば、インターネットが必要ですが、無料のWIFi（ホットスポットではない）またはイーサネットであるため、 NETWORK_TYPE_UNMETERED

を選択します。

 exerciseJobBuilder.setRequiresDeviceIdle(false);

ユーザーがデバイスと対話しないときの状態を決定します。この場合、これは重要ではありません。

 exerciseJobBuilder.setRequiresCharging(false);

この例では、デバイスが充電中であるかどうかにかかわらず、私たちに違いはないと仮定します。

タスクの繰り返し基準を設定できます（これについては以下で詳しく説明します）。

 exerciseJobBuilder.setBackoffCriteria(TimeUnit.SECONDS.toMillis(10), JobInfo.BACKOFF_POLICY_LINEAR);

さらに、タスクを定期的にすることができます：

 exerciseJobBuilder.setPeriodic();

定期的なタスク

タスクの周期を設定すると、論理的な制限に直面します。

setMinimumLatency()

およびsetOverrideDeadline()

は意味をなさないため使用できません。指定された間隔内でタスクを何らかの方法で1回実行する必要があり、上または下からの追加の制限は受け入れられません。一方、何かを待ってから定期的なタスクを開始する必要がある場合があります。このような条件を追加することはできません。待機する必要がある場合は、実行するタスクを追加する前に待機する必要があります。
onStopJob()

JobServiceでtrue

返すことはできません-中断された定期タスクは、次回のスケジュール時にキューから削除されません。
特定の間隔の後にタスクが正確に完了することを保証する人はいません。この間隔の間にタスクが完了するのは1回までです。

これらは、定期的なタスクと通常のタスクの主な違いです。現在の例では、タスクを定期的にしません。

繰り返し基準

setBackoffCriteria()

使用すると、必要に応じてタスクを完了するために2回目の試行を行うルールを設定できます（たとえば、 onStopJob()

trueを返しました）。

JobSchedulerは、線形と指数の2つのポリシーを提供します。

線形ポリシーの式は次のとおりです。

 retry_time(current_time, num_failures) = current_time + initial_backoff_millis * num_failures, num_failures >= 1

つまり現在の時点から、次の試行は、指定された時間に失敗の回数を掛けた後に行われます。

指数ポリシー式：

 retry_time(current_time, num_failures) = current_time + initial_backoff_millis * 2 ^ (num_failures - 1), num_failures >= 1

ここでは、次の試行の時間が大幅に大きくなります。

すべてが非常にシンプルで透過的ですが、タスクを何度も正常に完了できない場合はどうなりますか？最初の再試行時間が1分の場合、10回試行するのに1時間近くかかります。このような状況を把握するのは簡単ではありません。1時間以内に何が起こるか予測できないからです。 JobSchedulerは、このような繰り返しを5時間に制限しています。

したがって、 setBackoffCriteria()

パラメーターは、タスクセットに従ってポリシーの初期時間とタイプを慎重に考慮して、非常に慎重に処理する必要があります。また、繰り返しの回数などの追加の処理を実行し、 JobSchedulerからタスクを削除する必要がある場合もあります。

完了のためのタスクの送信

したがって、必要なすべてのパラメーターを備えたJobBuilderの準備ができました。実行キューにタスクを追加するには、システムからJobSchedulerインスタンスを取得する必要があります。

 JobScheduler jobScheduler = (JobScheduler) context.getSystemService(Context.JOB_SCHEDULER_SERVICE);

そして、メソッドを呼び出してビルダーからJobInfoを追加します。

 jobScheduler.schedule(exerciseJobBuilder.build());

信頼性のために、最後のメソッドの戻り値を確認できます。これにより、キューへのタスクの追加が成功したか失敗したかがわかります。

さらに、 JobSchedulerがタスクの条件が最適であることをonStartJob()

と、 ExerciseJobServiceの onStartJob()

メソッドが呼び出されます。これは既に上記で解析されています。

検証とデバッグ

要約すると、結果は、 IntentServiceで条件付きで重い操作を実行する1回限りのタスクを計画できるテストアプリケーションです。

パフォーマンスをテストするために、次のような小さなインストルメントテストを追加することをお勧めします。

  @Test public void sendDemoBroadcast() throws Exception { Context appContext = InstrumentationRegistry.getTargetContext(); Intent demoIntentForBroadcast = new Intent(appContext, ExerciseRequestsReceiver.class); demoIntentForBroadcast .setAction(ExerciseRequestsReceiver.ACTION_PERFORM_EXERCISE); appContext.sendBroadcast(demoIntentForBroadcast); }

また、例の動作を確認するために、一部のログがソースコードに追加されましたが、上記の抜粋では示されていません。

テストを実行すると、「id：1」のタスクが開始および終了、開始および終了することがわかります...より正確には、 JobSchedulerが強制的に完了させます。

個別のスレッドでのタスク実行とサービス完了の通知

この例では、 onStartJob()

メソッドからtrueを返しました。これは、タスクの実行がサイドストリームのどこかで継続することをJobSchedulerに伝えたことを意味します。タスクの完了を通知しないため、 JobSchedulerは強制的にタスクを完了します。また、 onStopJob()

からtrueを返すため、再試行ポリシーがトリガーされ、タスクが再スケジュールされて再起動されます。

これを防ぐには、 ExerciseJobServiceサービスクラスのjobFinished()

メソッドを呼び出す必要があります。次の記事で、その使用とIntentServiceからタスクの完了に関する情報を送信するためのさまざまなオプションについて説明します。

これでテストケースの作成が完了し、タスクプランニング用の作業プロジェクトで使用および適用する準備が整いました。ここでは、バックグラウンドでタスクを実行するためにIntentServiceが使用されましたが、他の方法、たとえばThreadPoolExecutorまたはHandlerThreadを使用することもできます。また、Android O以降専用の開発の場合、 JobIntentServiceに注意することもお勧めします。

この例の完全なコードはGitHubにあります。

developer.android.comのActivityからJobSchedulerの公式実装例を確認することもできます。

イラスト： Anni ART （著者の同意を得た場合のみコピーおよび複製）。

JobSchedulerとIntentServiceを使用したAndroidでのタスクのスケジューリング