モバイル開発におけるバックグラウンドタスク：概要、種類、仕組み

バックグラウンドタスクとは

バックグラウンドタスクとは、アプリがフォアグラウンド（アクティブ画面）にないときに実行されるコードのことです。これには、サーバーとの定期的なデータ同期、大容量ファイルのダウンロード、プッシュ通知の処理、位置情報追跡、ウィジェットの更新が含まれます。各プラットフォームにはバックグラウンド作業に関する独自の制限があります。iOSはより厳格（バックグラウンド時間10〜30分）、Androidはより寛容ですが、バージョン9以降ルールが厳しくなっています。

バックグラウンドタスクのアーキテクチャは3つのレベルで構成されます：（1）即時タスク — すぐに実行（Foreground Service）；（2）遅延タスク — 適切な条件で実行（WorkManager、BGTaskScheduler）；（3）定期タスク — 設定された間隔で繰り返し実行。適切なレベルの選択によって、タスクが時間通りに完了するかどうか、アプリストアでの拒否につながるかどうかが決まります。

両プラットフォームで、Google/Appleはバックグラウンドで直接スレッドを管理する代わりに宣言的APIの使用を強く推奨しています。AndroidのWorkManagerとiOSのBGTaskSchedulerは、システムがアプリ間でバックグラウンド作業を最適に分散し、エネルギー節約のためにタスクをグループ化することを可能にします。IT Sectrでは、常に更新の頻度と緊急度の要件を分析することからバックグラウンドアーキテクチャの設計を始めます。

iOSのバックグラウンドタスク（Background Fetch、BGTaskScheduler）

iOSはバックグラウンド作業にいくつかのメカニズムを提供しています。Background Fetch — システムが決定する間隔での定期的なコンテンツ更新（開発者ではなく）。アプリは新しいデータをダウンロードするために約30秒のウィンドウを得ます。Background FetchはCapabilities → Background Modes → Background Fetchから有効にし、AppDelegateで実装します：application(_:performFetchWithCompletionHandler:)。

BGTaskSchedulerはiOS 13+向けの最新APIで、Background Fetchを置き換えます。開発者が識別子でタスクを登録すると、システムが適切な条件で実行します。BGAppRefreshTask — 短いコンテンツ更新用。BGProcessingTask — 長時間タスク用（キャッシュクリア、データベース同期）。タスクはアプリ起動時に登録され、システムはバッテリー状態、ネットワーク、ユーザーアクティビティを考慮して実行をスケジュールします。

Background Modes — 特定のシナリオでバックグラウンド作業を許可するモードのリスト：Audio（バックグラウンド再生）、Location（GPS追跡）、VoIP（PushKit経由の通話）、BLE（Bluetoothデバイス接続）、Processing（BGTaskScheduler経由の長時間タスク）。各モードはApp Storeレビューでの正当性の説明が必要です。実際の必要性なくモードを使用することは、アプリ拒否の一般的な理由です。

Significant Location Change — 常時位置情報は不要だが、ユーザーの大きな移動（500メートル以上）を把握する必要があるアプリ向けのメカニズム。携帯電話基地局が変わるとシステムがアプリを起動します。このメカニズムは、常時GPS追跡と比較してバッテリーを大幅に節約します。

Androidのバックグラウンドタスク（WorkManager、JobScheduler、Foreground Service）

Androidはバックグラウンドタスクに最も豊富なAPIセットを提供していますが、バージョン8.0（API 26）以降、ルールはより厳しくなっています。WorkManagerは、あらゆるタイプのバックグラウンドタスクに対してGoogleが推奨するソリューションです。WorkManagerはデバイス再起動後でもタスク実行を保証し（BootReceiver経由）、タスクチェーン、監視可能なLiveData/Flow、API 14までの後方互換性をサポートします。

WorkManagerはWorker（doWork()メソッドを持つ基本クラス）を使用します。Constraintsが実行条件を定義します：NetworkType.CONNECTED、BatteryNotLow、StorageNotLow。PeriodicWorkRequest — 最小間隔15分の定期タスク用。WorkManagerはDoze ModeとApp Standbyに自動的に適応し、タスクをメンテナンスウィンドウにグループ化します。シンプルなWorkerの例：

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            val repository =
                Injection.provideRepository(applicationContext)
            repository.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

// Запланировать задачу
val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(constraints)
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

JobScheduler — より古いAPI（Android 5+、API 21）。指定された条件（ネットワーク、充電、アイドル）でタスクをスケジュールします。制限：デバイス再起動をサポートせず（BootReceiverが必要）、監視可能な状態がありません。JobSchedulerはレガシープロジェクトの単純なタスクに適しています。新しいプロジェクトではWorkManagerを使用してください。

Foreground Service — ユーザーが永続的通知（ongoing notification）を通じて見るサービス。音楽再生、GPS追跡、大容量ファイルのダウンロードに使用されます。Foreground Serviceは高い優先度を持ち、メモリ不足時にシステムが強制終了することはありません。Android 13以降、一部のタイプにはFOREGROUND_SERVICE_SPECIAL_USE許可が必要です。代替として、ForegroundServiceOption付きのWorkManager（長時間タスク）があります。

AlarmManager — 正確な時間に実行する必要があるタスク用（アラーム、リマインダー）。AlarmManagerはDoze Modeからデバイスを起こせます（setAlarmClock）。高い電力消費のため、通常の同期には推奨されません。定期タスクにはWorkManagerを使用し、正確な時間が重要な場合のみAlarmManagerを使用してください。

Doze ModeとApp Standby

Doze Modeは、バックグラウンドタスクの実行に影響を与えるAndroidの省電力モードです。Android 6.0（API 23）で導入されました。デバイスが充電されておらず、画面がオフで、デバイスが静止している場合、Doze Modeはネットワークリクエストをブロックし、JobSchedulerとWakeLockを延期します。定期的にDozeはメンテナンスウィンドウを開きます — アプリが遅延タスクを実行できる短い間隔です。Android 7.0（API 24）以降、Dozeは完全に静止している場合だけでなく、画面がオフの場合にアクティブになります。

App Standby — 使用されていないアプリをスタンバイ状態にするモード。アクティブな通知がなく、数日間開かれていないアプリは、Standby Bucketに配置されます：アクティブ（active）、working、frequent、rare。アプリの使用頻度が低いほど、制限が厳しくなります：ネットワークリクエストが延期され、同期がブロックされ、JobSchedulerが実行されません。

WakeLock — デバイスを起動状態に保つメカニズム（スリープを防ぐ）。重要な操作を完了するために使用されます。WakeLockはタスク完了後に必ず解放する必要があります（release）。そうしないと、数時間でバッテリーが消耗します。WakeLockはDoze Modeでは機能しません — システムが無視します。Android 8+でWakeLockを使用するには、WAKE_LOCK許可と適切なライフサイクル管理が必要です。

IT Sectrでは、設計段階でDoze ModeとApp Standbyを考慮します。WorkManagerはこれらのモードを自動的に処理しますが、Foreground ServiceではDozeへの移行を適切に処理する計画が必要です。実際のデバイスで省電力モードを有効にし、長時間のアイドル状態の後にバックグラウンド作業をテストすることを推奨します。

実践的なヒント

バックグラウンドタスクを設計する際は、次のヒントに従ってください。1. 新しいAndroidプロジェクトでは常にWorkManagerを使用します。互換性の問題、Doze Mode、デバイス再起動の問題を解決します。2. iOSでは、iOS 13+の場合、Background FetchよりもBGTaskSchedulerを優先します。3. Foreground Serviceは、タスクが本当に可視的通知を必要とする場合のみ使用します。4. WakeLockを乱用しないでください — バッテリーを消耗し、アプリ拒否の原因になります。5. Doze Modeでバックグラウンドタスクをテスト：adb shell dumpsys deviceidle force-idle。6. ログと分析を通じてタスク完了を常に確認します。7. 制限を覚えておいてください：iOSはBackground Fetchに約30秒、BGProcessingTaskに約数分を提供します。Android WorkManagerは正確な実行時間を保証しません。