モバイルOSのバックグラウンド実行制限

なぜバックグラウンド実行が「制限される前提」なのか

デスクトップOSでは常駐プロセスが常識ですが、モバイルOSはこれを原則禁止に近い形へ倒しています。理由は単純で、CPU・無線・GPSを動かし続けるアプリが1つでもあれば、バッテリ駆動時間という共有資源が一部のアプリに独占されるからです。さらにモバイル端末は物理メモリが小さく、複数アプリを同時に生かしたままにするとメモリ不足で強制終了（OOM Kill）が多発します。つまり「バックグラウンドで自由に動けるアプリがある」こと自体が、他アプリの体験とバッテリ持ちを悪化させる負の外部性を生みます。iOSとAndroidは方式こそ異なりますが、どちらも「基本は止める、必要な処理だけOSの管理下で機会的に動かす」という同じ思想に収束しています。

iOS: サスペンドが既定状態

iOSアプリはフォアグラウンドを失うと数秒でサスペンド（実行停止・メモリ上には残存）に入ります。CPU時間は原則ゼロで、コード実行が必要な処理は事前に宣言した種類（Background Modes）だけがOSに許可されます。

この設計の狙いは、アプリ側の都合ではなくOS側の都合（電力・熱・利用状況）で実行タイミングを一元管理することです。個々のアプリが「自分は重要だから今すぐ動きたい」と主張しても、OSが全アプリの要求を集約し、システム全体の電力予算内に収まるようスケジューリングします。即時性が必須な用途（メッセージ着信など）は、アプリ自身を起こすのではなくPush通知（APNs）でOS側に処理させ、必要なら通知配信と同時にNotification Service Extensionという別プロセスを短時間だけ起動する形で解決します。

Android: DozeとApp Standbyによる段階的休眠

Androidは6.0（API 23）以降、Dozeという端末全体の休眠モードを導入しました。画面が消灯し、充電されておらず、一定時間動きがないと判定されると、段階的にネットワークアクセスとCPUウェイクロックを制限します。

画面OFF + 未充電 + 静止状態が継続
        ↓
[軽度Doze] メンテナンスウィンドウを一定間隔で開き、
           その間だけネットワーク・ジョブ実行を許可
        ↓
[深度Doze] メンテナンスウィンドウの間隔が指数的に延長
           （最初は短く、時間が経つほど間隔が長くなる）

メンテナンスウィンドウの外では、通常のネットワークアクセスは保留され、AlarmManagerの通常アラームも遅延し、JobSchedulerのジョブも実行されません。さらにApp Standbyは、Doze中かどうかに関わらず「最近使われていないアプリ」を個別にバケット分類し、使用頻度が低いアプリほどジョブ実行の機会を絞ります。

Android 8.0（Oreo）以降はさらに踏み込み、アプリがバックグラウンドに回った後は原則としてバックグラウンドサービスの開始自体を禁止し、常駐が必要なら通知を伴うフォアグラウンドサービスとして明示的に扱う必要があります。通知バーに常時表示される「音楽再生中」「経路案内中」のような表示は、ユーザーに見える形にすることで初めて継続実行を許すという設計判断の現れです。暗黙のブロードキャスト受信も同様に制限され、任意のアプリがシステムイベントをトリガーに一斉起床することができなくなりました。

常駐サービスが成立しない理由

かつてのデスクトップ的発想である「サービスを一つ立ち上げておいて、いつでも即座に反応する」という常駐モデルは、モバイルOSの制約下では前提から崩れます。

この2つの制約があるため、両OSとも「即時性が必要な通知はOSのプッシュ基盤に委任し、アプリ自身は基本サスペンド・休眠させる」というアーキテクチャに統一されました。アプリを常時起こしておく代わりに、サーバー側からOSのプッシュサービス（APNs、Firebase Cloud Messaging相当の基盤）へ通知を送り、OSが受け取った時点でアプリを必要なだけ短時間起床させる。起床の主導権をアプリからOSへ移すことで、電力とメモリの配分をシステム全体で最適化できるわけです。開発者にとっての実務的な帰結は明確で、定期実行が必要な処理は「いつ動くか」を諦めてOSのスケジューラに委ね、即時性が必要な処理はプッシュ通知を起点に設計する、という発想の転換が求められます。

まとめ

iOSはBackground Modesで許可された種別のみを機会的に実行し、定期処理はBGTaskSchedulerを通じてOSの裁量に委ねます。AndroidはDozeとApp Standbyによって画面消灯後の端末とアプリ単位の双方から実行機会を段階的に絞り込み、バックグラウンドサービスの起動そのものを制限します。根底にあるのはバッテリと物理メモリという有限資源をOS全体で公平に配分するという設計思想で、アプリ主導の常駐モデルはこの制約と根本的に相容れません。実行の主導権をアプリからOSのスケジューラやプッシュ基盤へ委ねる設計へ転換したことが、現代のモバイルOSがバックグラウンド実行を厳しく制限する最大の理由です。より広いOSのプロセス管理やスケジューリングの原理は/os/、電力・熱の制約が絡む組込み設計の視点は/embedded/と合わせて理解すると見通しが良くなります。