Androidのアクティビティライフサイクル

なぜライフサイクルを正確に理解する必要があるのか

Androidのアプリは、開発者が思うほど自分のプロセスを制御できません。ユーザーが他のアプリに切り替えた瞬間、あるいはメモリが逼迫した瞬間、システムはバックグラウンドのActivityを予告なく終了させます。さらに画面回転やダークモード切り替えのような些細な操作でも、既定ではActivityそのものが一度破棄されて作り直されます。この「いつ何が起きるか分からない」環境で状態を失わないためのルールが、アクティビティライフサイクルです。単なるコールバックの暗記ではなく、OSがなぜこの設計を選んだのかを理解すると、状態管理の判断を誤らなくなります。

6つのコールバックが表す状態遷移

Activityのライフサイクルは、onCreate・onStart・onResume・onPause・onStop・onDestroy という6つのコールバックで区切られます。これらは3つの「生存期間」に対応します。

onCreateはActivityインスタンスが生成された直後に一度だけ呼ばれ、レイアウトの構築やViewModelの取得を行います。onStartで画面が可視になり、onResumeでフォーカスを得てユーザー操作を受け付け始めます。ここまでが起動側の遷移です。

終了側は逆順ではなく非対称です。他のActivityが前面に来る、あるいはユーザーがホームに戻るとonPauseが呼ばれ、続けて画面が完全に隠れるとonStopが呼ばれます。onPauseは非常に短時間で完了させる必要がある点が重要です。次のActivityのonResumeは、現在のActivityのonPauseが完了するまで開始されないため、ここで重い処理を行うとアプリ全体の応答性が落ちます。永続化やアニメーション停止など軽い処理に留め、重い保存処理はonStop側に置くのが原則です。

onDestroyは明示的なfinish()呼び出し、あるいはconfiguration changeによる再生成の際に最終的に呼ばれます。ただし後述の通り、プロセスキル時にはonDestroyすら呼ばれずにプロセスごと消えることがあります。

configuration changeによる再生成

画面回転、言語設定変更、ダークモード切り替え、キーボード種別の変化などは「configuration change」と呼ばれ、既定の挙動としてシステムは現在のActivityをonPause → onStop → onDestroyで破棄し、新しいConfigurationを持つ全く別のActivityインスタンスをonCreateから作り直します。

これは事故ではなく設計判断です。回転後のレイアウトは、文字列リソースやdpベースの寸法が異なる値セット（values-landなど）から再解決される必要があり、既存のViewツリーを微調整するより「作り直す」方が一貫性を保ちやすいという考え方に基づきます。

この挙動には重要な帰結があります。onCreate内でメンバ変数に代入しただけの状態は、再生成のたびに初期値へ戻ります。ネットワーク取得結果やユーザーが入力途中のフォーム内容をメンバ変数だけに置いていると、回転一つで消えます。

プロセスキルと onSaveInstanceState

configuration changeとは別に、より厳しい状況として「プロセスキル」があります。ユーザーがバックグラウンドに送ったActivityは、システムがメモリ確保のためにActivityインスタンスごとプロセスを終了させる対象になります。この場合onDestroyさえ呼ばれない可能性があり、メンバ変数もViewModelもプロセスと運命を共にして消えます。

この状況に備える仕組みがonSaveInstanceState(Bundle)です。呼び出しタイミングはAPIレベルで変わっており、Android 9（API 28）以降はonStopの後に呼ばれるよう変更されました（それ以前はonStopの前、onPauseの前後という順序でした）。渡されたBundleはシステムプロセスの外（ActivityManager側）に保持されます。ユーザーが「戻る」操作などでアプリに戻ってきた際、新しいActivityインスタンスのonCreateとonRestoreInstanceStateにこのBundleが渡され、UI状態を復元できます。

つまり両者は排他ではなく補完関係にあります。ViewModelは再生成のたびに走る重い初期化処理（APIコール、DB読み込み）を1回に減らす役割を担い、onSaveInstanceStateはViewModelごと消えるプロセスキルからでも最低限のUI状態（現在のタブ、スクロール位置、フォームの下書きなど）を復元する最後の砦として働きます。

ViewModelがライフサイクルを生き延びる仕組み

ViewModelが回転後も同一インスタンスであり続けるのは魔法ではなく、保持先が異なるためです。Activityが再生成される際、ViewModelProviderはまずViewModelStoreを探しに行きますが、このViewModelStore自体はonRetainNonConfigurationInstanceの仕組みを通じて、破棄される直前の古いActivityから新しいActivityへ引き継がれます。Activityインスタンス自体は毎回新しく作られても、ViewModelStoreという保管箱だけがすり替えられずに渡されるため、その中のViewModelインスタンスは同一のまま維持されます。

一方でこの保管箱はActivityが本当に終了するとき（finish()呼び出しやプロセスキル）には解放され、ViewModel.onCleared()が呼ばれます。この境界を区別するためにisChangingConfigurations()のようなAPIがあり、システムは「再生成のための破棄」と「本当の終了」を内部的に見分けています。

まとめ

Androidのライフサイクルは、限られたメモリの中で複数アプリを同時に生かすというOS側の都合を、開発者が受け入れるための契約です。onCreateからonDestroyまでの6コールバックは単なる通知ではなく、初期化・可視化・フォーカス取得それぞれの責任範囲を区切る境界線であり、onPauseを軽く保つことは前面アプリの応答性に直結します。configuration changeによる再生成とプロセスキルは似て非なる脅威で、前者はViewModelが、後者はonSaveInstanceState（およびSavedStateHandle）がそれぞれ異なる保存先を用いて対処します。この二層構造を正確に切り分けて設計することが、回転や中断に強いAndroidアプリの土台になります。