onStop — AndroidライフサイクルにおけるActivityの非表示

AndroidにおけるonStopとは？

onStop — AppCompatActivityクラス（およびその前身のActivity）のコールバックメソッドで、Androidオペレーティングシステムによって、Activityがユーザーに完全に表示されなくなったときに呼び出されます。この時点で、Activityは別のActivity、ダイアログウィンドウ、システムランチャー、またはロック画面によって隠されています。ライフサイクルの観点から見ると、onStopはonPauseの後に続き、Activityオブジェクトとその状態はメモリに残っているものの、Activityが画面上に表示されなくなったことを示します。

ActivityがStopped（停止）状態に移行すると、RAMに状態を保持します — すべてのフィールド、View階層、ViewModelがアクセス可能なままです。これにより、StoppedはActivityが完全に削除されるDestroyed（破棄）状態と区別されます。システムUIは、メモリ不足時にStopped状態のアプリケーションプロセスを強制終了することがあります — これはいわゆるプロセス強制終了です。開発者は、プロセス強制終了時の復元を保証するために、onStopの前に呼び出されるonSaveInstanceState()に重要なデータ（下書き、スクロール位置）を保存する必要があります。

Android互換性定義ドキュメント（CDD）バージョン14+によると、Stopped状態のプロセスはOOM Killerによる強制終了の優先度が低くなります — バックグラウンドフェーズのプロセスよりは低いが、キャッシュされたプロセスよりは高いです。Googleの統計によると、68%のプロセス強制終了は、ActivityがPaused状態ではなくStopped状態のときに発生します。

onStopが呼び出されるタイミング：シナリオと順序

onStopはActivityが完全に可視性を失ったときに呼び出されます。理由は問いません：現在の上に新しいActivityを起動する、アプリを最小化する（ホームボタン）、画面をロックする、着信、またはシステムダイアログを開くなど。これらすべての場合で、Activityは最初にonPause（部分的なフォーカス喪失）を受け取り、次にonStop（完全な可視性喪失）を受け取ります。

onStop呼び出しの主なシナリオ：

• 現在の上に新しいActivityを起動 — 現在のActivityはonPause、次にonStopを受け取ります。新しいActivityはonCreate → onStart → onResumeを経ます。
• アプリの最小化（ホーム） — Activityは200～300ミリ秒でonPause → onStopに移行し、Stopped状態でメモリに残ります。
• 画面のロック — ロック画面がActivityを完全に覆うため、システムはonPause → onStopを呼び出します。
• 着信 — 電話アプリ（ダイヤラー）が前面に起動し、現在のActivityはonStopに移行します。
• 別のアプリへの切り替え（最近のアプリ） — Activityは非表示になり、onStopを受け取りますが、プロセスキャッシュに残ります。

画面回転時にはonStopは呼び出されないことを理解することが重要です — この場合、Activityは破棄（onPause → onStop → onDestroy）され、再作成（onCreate → onStart → onResume）されます。例外はマニフェストのandroid:configChanges="orientation"フラグで、Activityの再作成を防ぎ、代わりにonConfigurationChanged()を呼び出します。

ActivityライフサイクルにおけるonStop

onStopは、Activityライフサイクルシーケンスの中で、可視状態と不可視状態の間の中心的な位置を占めます。完全なシーケンス：onCreate → onStart → onResume →（アクティブ状態）→ onPause → onStop → onDestroy（または復帰時にonRestart → onStart → onResume）。

*Stopped状態では、Activityはメモリに保持されますが、リソース不足時にシステムによって強制終了される可能性があります。Stoppedプロセスの強制終了優先度は最後から2番目で、キャッシュされた空のプロセスのみが下です。

onStopとonSaveInstanceState： システムは動的UI状態を保存するために、onStopの前にonSaveInstanceState(Bundle)を呼び出します。開発者はこのメソッドをオーバーライドして、入力フィールドの値、RecyclerViewの位置、選択されたアイテムをBundleに保存します。Activityが破棄されない場合でも（ユーザーが単に最小化して戻った場合）、Bundleは構成変更時にonCreateに渡されます。Googleは、Activityの外部に存在するリポジトリデータやViewModelではなく、一時的なUI状態のみを保存することを推奨しています。

onStopで解放すべきリソース

onStopでは、Activityが表示されていないときに不要なすべてのリソースを開発者が解放する必要があります。これにより、バッテリー、CPU、メモリの負荷が軽減され、アクティビティに戻る際のANRも防止されます。

onStopで解放するもの：

• アニメーションとトランジション — ObjectAnimator、ValueAnimator、ViewPropertyAnimatorを停止します。非表示のActivityで実行中のアニメーションはGPUサイクルを無駄にします。
• センサー — SensorManager（加速度計、ジャイロスコープ、磁力計）の登録を解除します。Activityが非表示でもセンサーは電力を消費します。
• カメラとマイク — Camera2またはCameraXを解放し、MediaRecorderを停止します。Activityが非表示の状態でカメラをアクティブにすることは、Google Playポリシーで禁止されています。
• LocationListener — FusedLocationProviderClientまたはLocationManagerの登録を解除します。位置情報は最も電力を消費するリソースです。
• ネットワークリスナー — WebSocketを閉じ、バックグラウンドで不要なHTTPリクエストをキャンセルします。
• MediaPlayerとExoPlayer — バックグラウンドで再生を続けるべきでない場合は、一時停止または停止します。

onStopでやってはいけないこと： 長時間の操作（データベースへの大量データ保存、ネットワークリクエスト、複雑な計算）は実行しないでください。onStopはメインスレッドで実行され、Activityへの復帰をブロックします。長時間の操作には、遅延付きのWorkManagerまたはviewModelScopeのコルーチンを使用してください。ViewModelのリソースは解放しないでください — ViewModelはonStopを生き残り、復帰時に使用されます。

onStopとonPauseの違い

onPauseとonStopは、可視性喪失の程度と必須アクションの範囲が異なります。onPauseは部分的なフォーカス喪失時（ダイアログウィンドウやシステムメニューを開くなど）に呼び出され、onStopは完全な可視性喪失時に呼び出されます。この違いは、各段階でどのリソースを解放するかを選択する上で重要です。

一般的なルール：onPauseでは、別のアプリのユーザーエクスペリエンスに即座に影響を与えるシステムリソース（カメラ、メディアプレーヤー）を解放します。onStopでは、Activityが非表示のときに不要なその他すべてのリソースを解放します。Googleは、素早い切り替え時にonStopが呼び出されない可能性があるため、onPauseで重要なユーザーデータ（メールの下書き、設定）を保存することを推奨しています。

onStop → onRestart：画面に戻る

ユーザーが非表示のActivityに戻ると、システムはonRestart → onStart → onResumeを呼び出します。onRestartメソッドは、ActivityがStopped状態から戻ってきていることを示します。これは、onStopで解放されたUIとリソースを復元するための重要な段階です。

復帰時の呼び出しシーケンス：

• onRestart() — Activityが再び表示されることが通知されます。典型的なアクション：データの再読み込み、リストの更新。
• onStart() — Activityは表示されますが、まだアクティブではありません。ここでonStopで解放されたリソースが再初期化されます。
• onResume() — Activityがフォーカスを取得し、操作の準備が整います。アニメーションが開始され、センサーが登録されます。

アプリケーションプロセスがStopped状態でシステムによって強制終了された場合、onRestartの代わりにonCreateが呼び出され、onSaveInstanceStateからのBundleが状態復元のために渡されます。このシナリオ（プロセス強制終了）はAndroidアプリのバグの最も一般的な原因の1つです。開発者はonRestartを実装しても、プロセス強制終了後のonCreateによる復元を考慮するのを忘れてしまいます。

KotlinでのonStopのコード例

例1：センサー解放を伴う基本的なonStop実装

Activity非表示時の正しいセンサー登録解除とアニメーション停止を示します。画面に戻ると、onStartでリソースが復元されます。

class MainActivity : AppCompatActivity() {
    private lateinit var sensorManager: SensorManager
    private var accelerometer: Sensor? = null
    private var rotationAnimator: ObjectAnimator? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        sensorManager = getSystemService(Context.SENSOR_SERVICE) as SensorManager
        accelerometer = sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    }

    override fun onStart() {
        super.onStart()
        accelerometer?.let {
            sensorManager.registerListener(sensorListener, it, SensorManager.SENSOR_DELAY_NORMAL)
        }
        rotationAnimator = ObjectAnimator.ofFloat(findViewById(R.id.icon), "rotation", 0f, 360f)
        rotationAnimator?.apply {
            duration = 3000
            repeatMode = ValueAnimator.RESTART
            repeatCount = ValueAnimator.INFINITE
            start()
        }
    }

    override fun onStop() {
        super.onStop()
        sensorManager.unregisterListener(sensorListener)
        rotationAnimator?.cancel()
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("MainActivity", "ActivityがStopped状態から復帰")
    }

    private val sensorListener = SensorEventListener { event, _ ->
        Log.d("MainActivity", "加速度: x=${event.values[0]}, y=${event.values[1]}, z=${event.values[2]}")
    }
}

コードはonStartで加速度計センサーを登録し、無限回転アニメーションを開始します。onStopでは、センサーが登録解除され、アニメーションがキャンセルされます — これにより、Activityが非表示のときのバッテリー消費を防ぎます。onRestart → onStartを経て戻った後、リソースが再作成されます。

例2：SavedStateHandleによる状態保存を伴うonStop

ViewModel + SavedStateHandleを使用する最新のアプローチ。手動のBundle操作なしで、onStop中にフォームデータが自動的に保存されます。

class FormViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    var email: String
        get() = savedStateHandle["email"] ?: ""
        set(value) { savedStateHandle["email"] = value }

    var message: String
        get() = savedStateHandle["message"] ?: ""
        set(value) { savedStateHandle["message"] = value }
}

class FormActivity : AppCompatActivity() {
    private val viewModel: FormViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_form)
        Log.d("FormActivity", "onCreate: email=${viewModel.email}")
    }

    override fun onStop() {
        super.onStop()
        Log.d("FormActivity", "onStop: データがSavedStateHandleに保存されました")
    }
}

SavedStateHandleは、onStopの前に呼び出されるonSaveInstanceStateの間に、自動的にBundleに値を保存します。画面回転やプロセス強制終了時も、データは損失なく復元されます。Googleは、直接のonSaveInstanceStateではなく、フォームや下書きにはSavedStateHandleを推奨しています。

例3：onStopでの操作のためのlifecycleScope

onStopへの移行中に非同期でデータを保存するための、コルーチンを使用したlifecycleScopeの利用。コルーチンはメインスレッドをブロックせずにIOディスパッチャで実行されます。

class NoteActivity : AppCompatActivity() {
    private val noteRepository = NoteRepository()

    override fun onStop() {
        lifecycleScope.launch(Dispatchers.IO) {
            val text = findViewById<EditText>(R.id.note_content).text.toString()
            noteRepository.saveDraft(text)
            withContext(Dispatchers.Main) {
                Log.d("NoteActivity", "下書きがonStopで保存されました")
            }
        }
        super.onStop()
    }
}

lifecycleScope.launchコルーチンは、Activityのライフサイクルが終了すると自動的にキャンセルされます。Dispatchers.IOを使用することで、データベースやファイルへの書き込みがActivityへの復帰をブロックしないことが保証されます。Googleによると、lifecycleScopeのコルーチンは、onStopで非同期操作を実行する推奨される方法です。