このページは Cloud Translation API によって翻訳されました。

バックグラウンド処理に関するシステム制限

バックグラウンドプロセスは、メモリと電池を大量に消費することがあります。たとえば、非明示的ブロードキャストにより、それをリッスンするように登録されているバックグラウンドプロセスが、作業量が少ないにもかかわらず多数開始される可能性があります。これは、デバイスのパフォーマンスとユーザーエクスペリエンスの両方に大きな影響を与える可能性があります。

システムの制限を回避するには、バックグラウンドタスクに適した API を使用してください。ニーズに合った API を選択するには、バックグラウンドタスクの概要のドキュメントをご覧ください。

ユーザーが開始する制限

アプリが Android Vitals に記述されている好ましくない動作を行った場合、そのアプリのシステムリソースへのアクセスを制限するように、システムがユーザーに求めます。

システムは、アプリが過剰なリソースを消費していることを検出すると、ユーザーに通知し、アプリのアクションを制限するオプションをユーザーに提供します。この通知のきっかけとなる動作には、次のようなものがあります。

過度の wake lock: 画面がオフのときに、1 つの部分的な wake lock が 1 時間保持されている
過剰なバックグラウンドサービス: API レベルが 26 未満で、バックグラウンドサービスが過剰である場合

詳細な制限はデバイスメーカーが決定します。たとえば、AOSP ビルドでは、制限付きアプリは、アプリがフォアグラウンドにある場合を除き、ジョブの実行、アラームのトリガー、ネットワークの使用ができません。

ネットワークアクティビティのブロードキャストの受信に関する制限

アプリは、CONNECTIVITY_ACTION ブロードキャストを受信するようにマニフェストに登録しても受信せず、このブロードキャストに依存するプロセスは開始されません。これは、ネットワークの変更をリッスンする、またはデバイスが定額制のネットワークに接続したときに、一括ネットワークアクティビティを実行するアプリで問題を引き起こす可能性があります。この制限を回避する方法は、すでに Android フレームワークにいくつか存在しますが、どれを選択すべきかはアプリの目的によって異なります。

定額制の接続での作業のスケジュール設定

WorkRequest を作成する場合は、NetworkType.UNMETERED Constraint を追加します。

fun scheduleWork(context: Context) {
    val workManager = WorkManager.getInstance(context)
    val workRequest = OneTimeWorkRequestBuilder<MyWorker>()
       .setConstraints(
           Constraints.Builder()
               .setRequiredNetworkType(NetworkType.UNMETERED)
               .build()
           )
       .build()

    workManager.enqueue(workRequest)
}

処理の条件が満たされると、アプリはコールバックを受信して、指定された Worker クラスの doWork() メソッドを実行します。

アプリの実行中にネットワーク接続を監視する

実行中のアプリは、登録済みの BroadcastReceiver で CONNECTIVITY_CHANGE を引き続きリッスンできます。ただし、ConnectivityManager API は、指定されたネットワーク条件が満たされた場合にのみコールバックをリクエストする、より堅牢な方法を提供します。

NetworkRequest オブジェクトは、NetworkCapabilities の観点からネットワークコールバックのパラメータを定義します。NetworkRequest.Builder クラスを使用して NetworkRequest オブジェクトを作成します。その後、registerNetworkCallback は NetworkRequest オブジェクトをシステムに渡します。ネットワーク条件が満たされると、アプリはコールバックを受信し、ConnectivityManager.NetworkCallback クラスで定義された onAvailable() メソッドを実行します。

アプリは、終了するか unregisterNetworkCallback() を呼び出すまで、コールバックを受信し続けます。

画像や動画のブロードキャストの受信に関する制限

アプリは ACTION_NEW_PICTURE ブロードキャストと ACTION_NEW_VIDEO ブロードキャストを送受信できません。この制限により、新しい画像や動画を処理するために複数のアプリを復帰させる必要がある場合に、パフォーマンスとユーザーエクスペリエンスへの影響を軽減できます。

処理をトリガーしたコンテンツ認証局を特定する

WorkerParameters を使用すると、処理をトリガーしたコンテンツ認証局と URI に関する有用な情報を、アプリで受け取ることができます。

List<Uri> getTriggeredContentUris()

処理をトリガーした URI のリストを返します。処理をトリガーした URI がない場合（たとえば、デッドラインなどの理由で処理がトリガーされた場合）、または変更された URI の数が 50 を超える場合は、空になります。

List<String> getTriggeredContentAuthorities()

処理をトリガーしたコンテンツ認証局の文字列リストを返します。返されたリストが空でない場合は、getTriggeredContentUris() を使用して変更された URI の詳細を取得します。

次のサンプルコードは、CoroutineWorker.doWork() メソッドをオーバーライドし、ジョブをトリガーしたコンテンツ認証局と URI を記録します。

class MyWorker(
    appContext: Context,
    params: WorkerParameters
): CoroutineWorker(appContext, params)
    override suspend fun doWork(): Result {
        StringBuilder().apply {
            append("Media content has changed:\n")
            params.triggeredContentAuthorities
                .takeIf { it.isNotEmpty() }
                ?.let { authorities ->
                    append("Authorities: ${authorities.joinToString(", ")}\n")
                    append(params.triggeredContentUris.joinToString("\n"))
                } ?: append("(No content)")
            Log.i(TAG, toString())
        }
        return Result.success()
    }
}

システム制限でアプリをテストする

アプリをメモリの少ないデバイスやメモリ不足の状態で実行するように最適化すると、パフォーマンスとユーザーエクスペリエンスが向上します。バックグラウンドサービスとマニフェストに登録された非明示的ブロードキャストレシーバへの依存関係を削除すると、そのようなデバイスでのアプリの動作が改善されます。これらのバックグラウンドプロセスをまったく使用せずに、アプリを実行できるように最適化することをおすすめします。

その他の Android Debug Bridge（ADB）コマンドを使用すると、バックグラウンドプロセスを無効にしてアプリの動作をテストできます。

非明示的ブロードキャストとバックグラウンドサービスが使用できない状況をシミュレートするには、次のコマンドを入力します。

$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND ignore
非明示的ブロードキャストとバックグラウンドサービスを再度有効にするには、次のコマンドを入力します。

$ adb shell cmd appops set <package_name> RUN_IN_BACKGROUND allow

アプリをさらに最適化する

バックグラウンドタスクの動作を最適化するその他の有効な方法については、タスクスケジューリング API のバッテリー使用量を最適化するのドキュメントをご覧ください。