プロセス死と状態復元

プロセス死は例外ではなく通常運転である

モバイルOSにとって、バックグラウンドのアプリを終了させることはエラー処理ではなく日常的なメモリ管理です。ユーザーが他アプリに切り替えた瞬間から、あなたのプロセスは「回収可能なメモリの塊」として扱われ、フォアグラウンドのアプリがメモリを必要とすればいつでも殺されます。このときプロセス空間ごと消えるため、ヒープ上のオブジェクト、シングルトン、静的フィールドはすべて失われます。それでもユーザーが戻ってきたとき、あたかも継続していたかのように同じ画面・同じ入力内容を見せる——この一貫した体験を成立させる仕組みが状態復元です。ライフサイクルのコールバックがいつ呼ばれるかは /mobile-development/android-activity-lifecycle/ や /mobile-development/ios-app-lifecycle-states/ で扱いました。本稿はその一段下、「消えた状態をどう物理的に退避し、どう再構築するか」に踏み込みます。

横にスクロール

二つの「状態が消える」を分離する

まず対策を誤らないために、状態が失われる二つの原因を切り分けます。両者は見た目が似ていても、生き残る保存先がまったく異なります。

Configuration changeはプロセスが生きているため、AndroidではViewModelが同一インスタンスとして残り対処できます。しかしプロセス死ではViewModelもろとも消えるため、頼れるのは「事前にシステムプロセスへ書き出しておいた直列化済みのバイト列」だけです。この差を意識せずに ViewModel だけで状態を持つと、回転には強いのにバックグラウンド長時間放置には弱いアプリになります。

Androidのsaved instance stateはどこへ保存されるのか

AndroidのonSaveInstanceState(Bundle)に書き込んだデータは、アプリのプロセス内には留まりません。BundleはParcel化（直列化）され、Binder IPCを通じて別プロセスであるsystem_server（ActivityManagerService）に渡されて保持されます。だからこそ、アプリのプロセスが殺されても内容が生き残るのです。復元時は逆の経路で、新規プロセスのonCreate(savedInstanceState)とonRestoreInstanceStateに同じBundleが届きます。

この「別プロセスへIPCで運ぶ」という実装が、そのまま制約を生みます。

Viewにはandroid:idが振られていればonSaveInstanceStateが自動で走り、EditTextのテキストやRecyclerViewのスクロール位置は標準で保存・復元されます。逆に言えば、IDのないViewや動的生成したViewの状態は自動保存の対象外になり、明示的な退避が必要です。

SavedStateHandleがプロセス死とViewModelを橋渡しする

ViewModelはconfiguration changeには強い一方、プロセス死には無力でした。この穴を埋めるのがSavedStateHandleです。これはViewModelのコンストラクタに注入されるキー・バリューストアで、内部的にはSavedStateRegistryという仕組みを通じて、ActivityのonSaveInstanceStateが保存するBundleの一部として同じ経路で退避されます。

class SearchViewModel(
    private val state: SavedStateHandle
) : ViewModel() {
    // プロセス死をまたいでも "query" キーで復元される
    val query: StateFlow<String> =
        state.getStateFlow("query", "")

    fun onQueryChanged(text: String) {
        state["query"] = text   // Bundleに退避される値を更新
    }
}

ここで保存できる値はBundleに載る型（プリミティブ、String、Parcelableなど）に限られます。これは制約ではなく、「プロセス死をまたぐ状態は直列化可能でなければならない」という物理的要請の表れです。関数の途中結果や進行中のコルーチンは直列化できないため、これらはプロセス死をまたいで保持できず、復元後に再実行する設計にします。宣言的UIであるJetpack Composeでも、rememberSaveableが内部で同じSavedStateRegistryに接続され、コンポーズ関数のローカル状態をプロセス死から守ります（/mobile-development/jetpack-compose-declarative-ui/ 参照）。

iOSの状態復元：識別子つきスナップショットの符号化

iOSも思想は同じで、プロセス死に備えてUI階層のスナップショットをディスクへ書き出しておきます。UIKitのState Restorationは、アプリがバックグラウンドへ入る際にビューコントローラ階層を走査し、restorationIdentifierが設定されたものだけをエンコード対象にします。ナビゲーションスタックの構成（どの画面が何階層積まれているか）と、各コントローラがencodeRestorableStateで書き出したアプリ固有データが、一つのアーカイブとして保存されます。

再起動時はこのアーカイブを即座に画面へ貼り付けるのではなく、二段構えで復元します。まずストーリーボードやコードで通常どおりビュー階層を生成し、次に保存済みスナップショットをdecodeRestorableStateで流し込みます。この順序により、「最後の画面のスクリーンショットを見せるだけ」ではなく、スクロール位置や入力途中のテキストまで含めて論理的に再構築できます。

SwiftUIでは@SceneStorageプロパティラッパーがこの仕組みを簡潔に包みます。@Stateがプロセス死で消えるのに対し、@SceneStorageに置いた値はシーン単位で永続化され、再起動後も復元されます。状態プロパティラッパーの所有・生存の違いは /mobile-development/swiftui-state-data-flow/ に詳しく、@SceneStorageはそこに「プロセス死耐性」という軸を加えたものと位置づけられます。

低メモリ時の終了は「クラッシュ」ではない

プロセス死の直接の引き金は多くがメモリ逼迫です。AndroidのLow Memory Killer（LMK、現在はlmkdデーモン）は、プロセスに割り当てられたoom_adjスコアを見て、フォアグラウンドから遠いプロセスほど優先的に殺します。iOSも同様に、Suspended中でメモリ使用量の大きいプロセスから回収します。重要なのは、この終了が正常なOS運用であって、クラッシュログには残らない点です。したがってデバッガで動かしているだけでは再現せず、検証には意図的なメモリ圧迫やDeveloper Optionの「アクティビティを保持しない」といった手段が要ります。

まとめ

プロセス死はモバイルOSの通常運転であり、アプリはヒープ上の状態がいつでも消える前提で設計する必要があります。Androidはsaved instance stateのBundleをBinder経由でsystem_serverに退避し、SavedStateHandleがその経路をViewModel層まで引き込むことで、論理状態をプロセス死からも守ります。iOSはrestorationIdentifierつきのUI階層とナビゲーションスタックをアーカイブし、再起動時に二段構えで再構築します。両プラットフォームに共通するのは、「プロセスをまたぐ状態は直列化可能な少量に絞り、本体は再取得可能にする」という原則です。configuration changeとプロセス死を明確に分離し、それぞれに正しい保存先を割り当てることが、中断に強いアプリの土台になります。