「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

Mac Book の 日本語 JIS キーボードを 英語 US キーボードになるべく違和感なく変える方法

日本語 JIS キーボードが馴染めない場合とか

ストレスすぎますよね。

逆もしかり。

様々なキーボードマッピングカスタマイズアプリなどありますが、

強引にレイアウトを変更したとて、

そもそもキーそれぞれ一つ一つのサイズが違う。

この方法がベストだと思われます。

 

🧑🏻‍💻 Magic Keyboard を手に入れる

少し高いですが。

👉 Magic Keyboard - 英語（US） - Apple（日本）

これを買うなりして手に入れるのが一番操作感は一番近いです。

日本語 JIS と 英語 US。

指紋センサー付きとなし。

Mac Bookのキーボード。

すべてサイズ同じです。

上に乗せればそれが一番良い感じです。

以上です。

知らなかったわ。

【DIY】700円でつくる Magic Keyboard/Trackpad2 向け Mac Book Pro 13インチ型縦配置の枠
横に並べて置くことを想定して設計されていますよね、Magic Keyboard/Trackpad2。 Magic Keyboard - 英語（US) - App
android.benigumo.com

Navigation3 entryProvider DSLの使い方と設計

「手動マッピング（命令型）」か、「DSLマッピング（宣言型・型安全）か」

ということなります。

これまで:
when 式などを使って、ルートごとに手動でインスタンスを生成・紐付けするスタイル。自由度は高いですが、記述量が増えやすく、型の不整合も起きがちです。

DSL形式:
entry() のように、型を渡すだけで自動的にマッピングを完結させるスタイル。ボイラープレートが排除され、型安全性が保証されます。

 

🤔 比較してみる


entryProvider = { key ->
    when (key) {
        is RouteA -> NavEntry(key) { ... }
        is RouteB -> NavEntry(key) { ... }
        else -> error()
    }
}

  • key は Any
  • Any → is チェック必須
  • 毎回 is RouteB などの分岐が必要


entryProvider = entryProvider {
    entry<RouteA> { ... }
    entry<RouteB> { key ->
        Text(key.id)
    }
}

  • key は 型付き (RouteB)
  • 分岐不要
  • entry → コンパイル時保証

 

🤔 まとめ


NavDisplay
  └ entryProvider (lambda)
       └ when(key)
            ├ RouteA → NavEntry + UI
            ├ RouteB → NavEntry + UI
            └ else → error




NavDisplay
  └ entryProvider (DSL)
       ├ entry<RouteA> { UI }
       └ entry<RouteB> { key -> UI(key.id) }

DSLは便利だが、抽象化が増えるため「内部の仕組み」が見えにくい感じに思います。

Jetpack Compose における State と Effect の境界線：ワンショットイベントに Channel を採用する理由

Jetpack Compose で開発をしていると、必ず直面する問いがあります。

「これは State として保持すべきか、それとも Effect（副作用）として処理すべきか？」

という問題です。

Compose の宣言的 UI パラダイムにおいて、この境界線を曖昧にすると、画面回転時の二重トーストや、意図しない画面遷移といったバグを招きます。

本記事では、その明確な使い分けと、イベント制御における Kotlin Channel の有効性について解説します。

 

🧑🏻‍💻 1. 「状態 (State)」と「副作用 (Effect)」の本質的な違い

使い分けの基準はシンプルです。

「そのデータは、UI のスナップショットの一部か？」

と自問してください。

State：UI の「今」を表すもの

State は、再構成（Recomposition）によって何度読み込まれても同じ結果を示すべきものです。

  • 例: テキストフィールドの入力値、読み込み中フラグ、リストデータ
  • 性質: 保持（Retention）

Effect：UI の「外」で起きる一回きりのこと

Effect は、Compose のレンダリングサイクルとは独立して実行される処理です。

  • 例: ログ出力、アナリティクス送信、タイマーの開始
  • 性質: 実行（Execution）

 

🧑🏻‍💻 2. ワンショットイベントの罠：StateFlow vs Channel

ここで問題になるのが、トースト表示や画面遷移のような「一度だけ実行したいアクション」です。

これらを StateFlow で管理しようとすると、Android 特有のライフサイクル問題にぶつかります。

StateFlow の限界

StateFlow は常に「最新の状態」を保持します。

1. エラーが発生し、State を ErrorMessage("Failed") に更新。
2. UI がそれを検知してトーストを表示。
3. ここで画面を回転させる。
4. 新しい Activity が StateFlow を購読し、最新の "Failed" を再び受け取ってしまう。
5. トーストが二重に表示される。

これを防ぐために「フラグを戻す」処理を挟むのは、シンプルではありません。

 

🧑🏻‍💻 3. Channel は「消費されるイベント」に最適である

そこで登場するのが Channel です。Channel は、「土管」のような振る舞いをします。

  • 一度きりの配送: 誰かがイベントを受け取った（消費した）瞬間、そのイベントは Channel から消えます。
  • 画面回転に強い: 新しい Activity が再購読しても、古いイベントは既に消費されているため、二重実行は発生しません。
  • バッファの活用: Channel.BUFFERED を使うことで、アプリがバックグラウンドにいる間に発生したイベントも、フォアグラウンドに戻った瞬間に安全に処理できます。

 

🧑🏻‍💻 4. 実装のベストプラクティス

私のプロジェクトでは、以下のような棲み分けを徹底しています。


// ViewModel

// UI の状態（表示データ）
private val _uiState = MutableStateFlow(UiState())
val uiState = _uiState.asStateFlow()

// UI へのイベント（ワンショット）
private val _eventChannel = Channel<UiEvent>(Channel.BUFFERED)
val events = _eventChannel.receiveAsFlow()




// UI (Compose)

LaunchedEffect(Unit) {
    viewModel.events.collect { event ->
        when (event) {
            is UiEvent.ShowSnackbar -> snackbarHostState.showSnackbar(event.message)
            is UiEvent.NavigateToDetail -> navController.navigate("detail")
        }
    }
}

 

🧑🏻‍💻 まとめ

  • 永続的な見た目に関わるなら State (StateFlow)。
  • 一過性の挙動に関わるなら Effect (Channel)。

複雑なフラグ管理でコードを汚す前に、ツールが持つ「自然な性質」を利用しましょう。

Channel を使うことは、Compose におけるイベントハンドリングを最もシンプルにする考え方の一つです。

Android アーキテクチャはイベント駆動型 UI からステート駆動型 UI へ移行している
Google の公式 Android ガイダンスは 2026年5月18日に更新され、ViewModel のイベ
android.benigumo.com

The State of Android Architecture: Google’s UDF vs. the Real-World “MVI-flavored MVVM” | by chanzmao | Mar, 2026 | ProAndroidDev
When discussing which architecture to adopt in modern Android development, the d
medium.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