「process death」とは何?

Androidにおける Process Death (プロセス終了) とは、システムがメモリ不足（Memory Pressure）になった際に、バックグラウンドにあるアプリのプロセスを OS が強制的に終了させる仕組みのことです。

ユーザーがアプリを閉じたり明示的に終了させたりする「通常の終了」とは異なり、OS側の都合で実行されるため、適切な対策をしないとアプリに戻った際にデータが消えてしまう原因になります。

 

🤔 なぜ気ににする必要があるのか

長いお問い合わせフォームを入力中に、少し調べ物をして戻ったら全部消えていた。

ECサイトで商品を比較していたのに、トップ画面に戻された。

「このアプリは不安定だ」「使いにくい」と思われ、アンインストールや低評価に直結します。

 

🤔 予期せぬクラッシュを防ぐため

Process Death からの復帰時、OSは「最後に開いていた画面」をいきなり表示しようとします。

もし、その画面が 「前の画面から渡されたデータ（IDなど）」 に依存しているのに、それをメモリ上の変数（ViewModelのフィールドなど）にしか持っていなかった場合、復帰した瞬間にデータが null や空になり、アプリがクラッシュします。

 

🤔 「バックグラウンド＝一時停止」ではない

Androidの設計思想では、アプリがバックグラウンドに回った瞬間から、いつ消されても文句は言えないことになっています。

「メモリが潤沢にあるから大丈夫だろう」という想定は、現代のAndroid（特にバックグラウンドで動くサービスや重いゲームが多い環境）では通用しません。

「プロセスは必ずいつか死ぬ」という前提で設計することが、Android開発におけるプロフェッショナルな作法とされています。

 

🤔 開発時の確認方法

以下で開発時に確認しておくのがいいです。


1. アプリを起動したあと、ホーム画面に移動する。(終了させるのではなくて、バックグラウンドに移動する)

2. adb shell am kill <アプリのパッケージ名>

3. アプリの起動履歴から再度アプリを選択する。

注意: am force-stop とは異なり、am kill はバックグラウンドにいるアプリに対して「メモリが足りなくなったからシステムが回収した」という状態をシミュレートします。

起動履歴から再度アプリを起動したときに、バックグラウンドに移動する前の画面と同じものが表示されれば OK です。

 

🤔 まとめ

上記手順でやってみました。

これでOK!!

Jetpack Compose Navigation 3: ViewModel の生存期間を NavEntry 単位に変更する
Jetpack Navigation 3は、従来の Navigation Component と比較して非常にシンプルで「Action based」な設計になっ
android.benigumo.com

Jetpack Compose Navigation 3: ViewModel の生存期間を NavEntry 単位に変更する

Jetpack Navigation 3は、従来の Navigation Component と比較して非常にシンプルで「Action based」な設計になっています。しかし、デフォルト設定のまま ViewModel を利用すると、その生存期間に驚くかもしれません。

今回は、rememberViewModelStoreNavEntryDecorator() を使って NavEntry（画面）の破棄と同時に ViewModel をクリアする設定 について解説します。

 

🧑🏻‍💻 ViewModel のオーナーと生存期間

Nav3 で viewModel() を呼び出した際、そのオーナー（ViewModelStoreOwner）がどこにあるかを確認することは非常に重要です。

デフォルトの挙動：Activity スコープ

特に設定を行わない場合、ViewModel のオーナーは Activity (または Fragment) になります。

現状:
スクリーンが NavBackStack から消えても、ViewModel は破棄されません。

影響:
1 Activity で構成されたフル Jetpack Compose アプリの場合、一度生成された ViewModel はアプリが終了するまでメモリ上に生き続けます。

これは、画面を戻る（Pop back）たびに状態をリセットしたい場合には不都合な挙動となります。

 

🧑🏻‍💻 entryDecorators に ememberViewModelStoreNavEntryDecorator() を追加する

画面（NavEntry）ごとに独立した ViewModelStore を持たせるためのデコレータです。これを利用することで、NavEntry がスタックに積まれている間だけ ViewModel が生存するようになります。

設定方法：entryDecorators への追加

NavDisplay を呼び出す際、entryDecorators 引数にこのデコレータを渡します。


val backStack = rememberNavBackStack(initialBackStack)

NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
        rememberSaveableStateHolderNavEntryDecorator(),

        // これを追加することで NavEntry 単位の ViewModel スコープが有効になる
        rememberViewModelStoreNavEntryDecorator()
    )
) { entry ->
    // 各画面の Composable 呼び出し
    when (val key = entry.contentKey) {
        is ScreenA -> ScreenAContent()
        is ScreenB -> ScreenBContent()
    }
}

ViewModel の生存期間はどう変わるのか？

このデコレータを適用すると、内部的な構造は以下のように変化します。

適用前:
全ての NavEntry が Activity の ViewModelStore を参照。

適用後:
各 NavEntry が個別の ViewModelStore を保持。

これにより、NavBackStack から特定の NavEntry が取り除かれた（Pop された）タイミングで、紐づく ViewModelStore が clear() され、ViewModel も正しく破棄されるようになります。

 

🧑🏻‍💻 まとめ

Jetpack Navigation 3 で ViewModel を適切に管理するためのポイントは以下の通りです。

1. デフォルトでは Activity スコープ になり、画面を閉じても ViewModel は生き続ける。

2. rememberViewModelStoreNavEntryDecorator() を NavDisplay の entryDecorators に追加する。

3. これにより、Screen（NavEntry）の生存期間 = ViewModel の生存期間 となり、メモリ効率と状態管理の健全性が向上する。

Navigation 3 において、この設定は現代的な Android アプリ開発のスタンダードな構成と言えるでしょう。

【JetpackCompose Navigation3】rememberViewModelStoreNavEntryDecorator() とは何なのか
rememberViewModelStoreNavEntryDecorator()は、Google が開発を進めている次世代のナビゲーションライブラリ Navi
android.benigumo.com

Mastering Navigation 3: Managing Per-Screen ViewModels with NavBackStack | by chanzmao | Apr, 2026 | ProAndroidDev
The New Standard: NavBackStack-Driven ViewModels in Navigation 3
proandroiddev.com

【JetpackCompose Navigation3】rememberViewModelStoreNavEntryDecorator() とは何なのか

rememberViewModelStoreNavEntryDecorator()は、Google が開発を進めている次世代のナビゲーションライブラリ Navigation 3 (Android Jetpack) において、特定の画面（NavEntry）に ViewModelStore を提供するためのデコレーターを生成する関数です。


NavDisplay(
    backStack = backStack,
    onBack = { backStack.removeLastOrNull() },
    entryDecorators = listOf(
        rememberSaveableStateHolderNavEntryDecorator(),
        rememberViewModelStoreNavEntryDecorator() // *
    ),

一言でいうと、
「この画面で ViewModel を使えるようにする（ViewModel の器を用意する）」
ための設定項目の一つです。

 

🧑🏻‍💻 役割と仕組み

Navigation 3 では、画面の定義を「デコレーター」という仕組みで拡張します。

  • ViewModel の保持: 通常、ViewModel は ViewModelStore という場所に保存されます。この関数を使うことで、ナビゲーションの各エントリ（画面）が自分自身の ViewModelStore を持てるようになります。
  • ライフサイクルとの連動: これにより、画面が破棄されたときに、その画面に紐づく ViewModel も適切にクリアされるようになります。
  • Shared ViewModel の実現: 親のナビゲーショングラフでこのデコレーターを定義することで、複数の子画面間で同じ ViewModel インスタンスを共有（Shared ViewModel）することも可能になります。 


NavDisplay
 └─ NavBackStack
      ├─ NavEntry A
      │    ├─ contentKey = A
      │    └─ ViewModelStore A
      │         └─ ViewModel A
      │
      └─ NavEntry B
           ├─ contentKey = B
           └─ ViewModelStore B
                └─ ViewModel B

 

🧑🏻‍💻 なぜ必要なのか

従来の Navigation Compose では NavHost が内部で自動的に ViewModel の管理を行っていましたが、Navigation 3 はよりシンプルでカスタマイズしやすい設計を目指しています。

そのため、「どの画面が ViewModel の器（Store）を持つか」を明示的に指定する必要があり、そのためにこの関数が用意されています。

Apply logic or wrappers to destinations  |  App architecture  |  Android Developers
This document explains how to use NavEntryDecorator in Navigation 3 to add extra
developer.android.com

Jetpack Compose: Navigation3 rememberNavBackStack とは何なのか

 

🤔 説明

  • Jetpack Compose の Navigation3 における「ナビゲーション履歴（バックスタック）を状態として保持・復元する仕組み」
  • 画面遷移の履歴を Composable 内で安全に持てる
  • タブ切り替えや再構成でも状態を失わない

 

🤔 コードを見てみる


@Composable
public fun rememberNavBackStack(vararg elements: NavKey): NavBackStack<NavKey> {
    return rememberSerializable(
        serializer = NavBackStackSerializer(elementSerializer = NavKeySerializer())
    ) {
        NavBackStack(*elements)
    }
}

@Serializable(with = NavBackStackSerializer::class)
public class NavBackStack<T : NavKey> public constructor(internal val base: SnapshotStateList<T>) :
    MutableList<T> by base, StateObject by base, RandomAccess by base {

    public constructor() : this(base = mutableStateListOf())

    public constructor(vararg elements: T) : this(base = mutableStateListOf(*elements))
}

RememberNavBackStack.kt - Android Code Search
NavBackStack.kt - Android Code Search

👉️ rememberNavBackStack() は、rememberSerializavle + Serializer で rememberSerializable に渡している。


@Composable
public fun <T : Any> rememberSerializable(
    vararg inputs: Any?,
    serializer: KSerializer<T>,
    configuration: SavedStateConfiguration = DEFAULT,
    init: () -> T,
): T {
    val saver = serializableSaver(serializer, configuration)
    @Suppress("DEPRECATION")
    return rememberSaveable(*inputs, saver = saver, key = null, init = init)
}

RememberSerializable.kt - Android Code Search

👉️ rememberSeriarizable() は、@Serializable を rememberSavable + Saver で保存できるようにしている。

ということで、

UI (@Composable) にナビゲーションのスタック状態の保持を任すのなら
rememberNavBackStack()
を使うと便利。

ということのようです。

画面回転やライフサイクルなどありますしね。

 

🤔 参考

Jetpack Compose State Survival Guide: From remember to rememberNavBackStack | by chanzmao | Mar, 2026 | ProAndroidDev
One of the most critical decisions in Jetpack Compose development is choosing wh
proandroiddev.com

SavedInstanceState 不要!? Navigation3 の NavKey がもたらす Jetpack Compose 開発の変革
Android 開発者を長年悩ませてきた「画面回転」や「プロセス死」に伴う状態保存。SavedInstanceState や SavedStateHandle
android.benigumo.com

Navigation3 時代の Destination 設計：sealed interface による型安全な実装パターンと使い分け

モダンな Android 開発において、Navigation はもはや単なる「画面の切り替え機」ではありません。

Destinationは、UIの状態やラベル、アイコンといったメタ情報を内包した、純粋な「型」として定義されるべきです。

ここでは、最新の Navigation ライブラリが目指す方向性に沿った、sealed interface による Destination 設計を提案します。

「シンプルさと拡張性」

このトレードオフをどう乗り越えるか、具体的なコード例と共に見ていきましょう。

 

🤔 共通の考え方：Destination = 型 + UIメタ情報

これまでの Navigation では String ベースの Route 管理が主流でしたが、これからの設計は

「型そのものに UI のメタ情報（ラベルやアイコンなど）を持たせる」

のが基本スタイルになります。

 

🤔 パターン 1：ネストする sealed interface

すべての Destination を一つの親インターフェースの中に閉じ込めるスタイルです。

実装イメージ

NavHost では AppDestination.xxx という形で指定します。

特徴

  • ◎ 視認性： 全ての画面遷移先が 1 ファイルにまとまっており、全体像を把握しやすい。
  • ◎ シンプル： 小〜中規模のアプリであれば、管理コストが最小限で済みます。
  • △ 拡張性： 全てが AppDestination に依存するため、機能（Feature）ごとにモジュールを分割しようとすると、循環参照が発生しやすくなります。

 

🤔 パターン 2：ネストしない（トップレベル） sealed interface

インターフェースを定義しつつ、各 Destination は独立したクラスとして定義するスタイルです。

実装イメージ

NavHost での記述はよりフラットになります。

特徴

  • ◎ 疎結合： 各 Destination を別ファイルや別モジュールに切り出しやすいため、Feature 単位の分割に強い。
  • ◎ 大規模向き： チーム開発でコンフリクトを避けやすく、ビルド速度向上のためのマルチモジュール化にも適しています。
  • △ 記述量： クラス名が重複しないよう xxxDestination と命名する必要があり、少し冗長に感じることがあります。

 

🤔 どちらを選ぶべきか？

設計の選択基準は非常にシンプルです。

 

🤔 まとめ

Navigation3 時代の Destination 設計の肝は
「型自体にメタ情報を持たせること」
です。

  • とりあえず作り始めるなら「ネスト型」
  • 将来的な機能拡張やモジュール化を見越すなら「非ネスト型」

アプリの規模と、将来どこまで成長させるかに合わせて選んでみてください。