Android（Kotlin・Jetpack Compose）

Android の画面（Activity）は、表示や裏に回るたびに決まった順番で関数が呼ばれます。これがライフサイクルです。

構成変更

画面の回転、ダークモードの切り替え、言語の変更、折りたたみ端末を開くなどの構成変更が起きると、Activity は一度壊されて作り直されます。画面の中の変数はここで消えます。これを防ぐのが ViewModel で、構成変更の間も生き残るので、読み込んだデータや入力中の状態はここに置きます。

構成変更より見落とされやすいのが、裏に回っている間にプロセスごと終了される場合です。利用者から見ると「戻ったら入力が消えていた」になります。

裏に回ったアプリは、メモリが足りなくなるとプロセスごと終了されます。利用者が戻ってくると OS は最後の画面から作り直しますが、ViewModel もここで消えます。これに備えるのが保存済みの状態（SavedStateHandle、Compose なら rememberSaveable）で、OS が Bundle として預かって復元してくれます。

Bundle に入れるのは、検索語・選んだタブ・表示中の ID のような小さな値だけにします。大きな一覧や画像を入れると TransactionTooLargeException で落ちます。大きなデータは DB に保存し、ID だけを保存済みの状態に入れて、復元時に読み直します。

プロセスの終了は普段の操作では起きにくいので、わざと起こして確かめます。アプリをホームで裏に回してから adb shell am kill <パッケージ名> を流し、アプリに戻ると再現できます。

Jetpack Compose は Android の宣言的な UI の仕組みです。@Composable の関数が「状態から画面を作る」役で、状態が変わると関係する関数だけがもう一度呼ばれます。これを再コンポーズと呼びます。

状態の持ち上げ（state hoisting）

部品の中に状態を持たせず、呼び出し側に「値」と「変わったときの処理」を渡してもらう形を状態の持ち上げと言います。部品は表示に専念できるので、使い回しやテスト、プレビューがしやすくなります。

@Composable
fun SearchBox(query: String, onQueryChange: (String) -> Unit) {
  TextField(value = query, onValueChange = onQueryChange)
}
// 呼び出し側（画面）が状態を持つ。画面の状態は ViewModel の StateFlow から
val state by viewModel.uiState.collectAsStateWithLifecycle()

目安は「状態は、それを読む部品すべての一番近い共通の親に置く」です。画面全体の状態は ViewModel に置き、開閉やスクロール位置のような見た目だけの状態は部品の近くの remember に置きます。

Compose が遅くなる原因の多くは、必要のない再コンポーズです。状態が変わると、その状態を読んだ関数が呼び直されるので、読む場所と渡す型を工夫して範囲を狭くします。

落とし穴は、@Composable の中で直接通信や DB への書き込みを始めることです。何度呼ばれても困らないように、副作用は LaunchedEffect などの決まった場所か ViewModel で行います。Layout Inspector で再コンポーズの回数を見られるので、遅いと感じたらまず回数が多すぎる部品を探します。

Compose のアプリは、Activity を1つにして、その中で画面を切り替える形（シングルアクティビティ）が一般的です。画面の切り替えには Navigation Compose を使い、NavHost にルート（どの画面か）と画面の対応を書きます。Navigation 2.8 からは、ルートを @Serializable のクラスで型安全に書けます。

@Serializable data class Item(val id: Long)
NavHost(navController, startDestination = Home) {
  composable<Home> { HomeScreen(onOpen = { navController.navigate(Item(it)) }) }
  composable<Item> { ItemScreen() }  // ViewModel は SavedStateHandle から id を受け取る
}

より新しい Navigation 3 というライブラリも出ていて、バックスタックを自分の状態として持つ形になっています。新しく作るときは公式の案内を確かめて選びます。

Coroutines（コルーチン）は、Kotlin で「待つ処理」を普通の順番のコードで書ける仕組みです。suspend の付いた関数は、待っている間スレッドを手放すので、画面が固まりません。Flow は値が次々に流れてくるデータの流れで、DB の変更の通知や検索語の入力などに使います。

スコープとキャンセル

コルーチンは必ずスコープの中で動き、スコープが終わると中の処理はまとめてキャンセルされます（構造化された並行性）。

キャンセルは「お願い」で、止まるのは suspend 関数の呼び出しのところです。重いループの中では ensureActive() を呼びます。また catch (e: Exception) で CancellationException まで握りつぶすと、キャンセルが効かなくなるので、捕まえたら投げ直します。

コルーチンがどのスレッドで動くかは Dispatcher で決まります。画面の更新はメインスレッドでしかできず、メインスレッドで重い処理をすると画面が固まるので、処理の種類ごとに使い分けます。

切り替えは withContext(Dispatchers.IO) { } で、呼ばれる側の関数の中で行うのがよい形です（呼ぶ側がスレッドを気にしなくて済む）。Room や Retrofit の suspend 関数は自分で切り替えてくれるので、重ねて包む必要はありません。画面で Flow を集めるときは collectAsStateWithLifecycle や repeatOnLifecycle を使い、裏に回ったら集めるのを止めます。

Flow は値が次々に流れてくるデータの流れです。Room は表が変わるたびに新しい結果を Flow で流せるので、画面は DB を見ているだけで常に最新になります。Flow には、集めたときに動き出すもの（cold）と、集める人がいなくても値を持ち続けるもの（hot）があります。

val uiState: StateFlow<UiState> = repo.notes()
  .map { UiState.Success(it) }
  .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5_000), UiState.Loading)

画面で集めるときは collectAsStateWithLifecycle を使い、裏に回ったら集めるのを止めます。普通の collectAsState では、裏に回っても上流の処理が動き続けます。

Android は多くのメーカーが端末を出しているので、OS の版・画面の大きさ・メモリ・メーカー独自の設定がばらばらです。全部を確かめることはできないので、「どこまで対応するか」と「どれで確かめるか」を決めて運用します。

対応バージョンの決め方

• minSdk（動く最低の版）：自分のアプリの利用者の OS の分布を見て決めます。たとえば「利用者の 1〜2% 未満になった版は切る」のように基準を決めておき、切る前にはお知らせを出します。古い版を切ると、使える API が増えて分岐のコードが減ります。
• targetSdk（どの版の挙動に合わせるか）：Google Play には、新しいアプリや更新は最新に近い版を target にしなければならない決まりがあり、毎年引き上げられます。target を上げると権限や裏の処理の挙動が変わるので、毎年の作業として予定に入れておきます。
• compileSdk：新しい API を使うために、基本は最新にします。

iOS は新しい OS への更新が速いので、最新とその1〜2つ前の版までに対応するのが一般的です。

Android の端末はすべてを確かめられないので、利用者の多い機種と、問題が出やすい両端を選んで確かめます。

手元の実機は数台にとどめ、エミュレーターとクラウドの端末（Firebase Test Lab など）で幅を補います。リリース後は Play Console や Crashlytics で「特定の機種・版だけ落ちている」を見つけて、その機種を確かめる端末に加えていきます。

Android のビルドは Gradle で行い、設定は build.gradle.kts に書きます。リリースで大事なのは、ビルドの種類、コードの縮小（R8）、配る形式（AAB）、署名の4つです。

R8 を有効にしたら、リリース版で一通り動かして確かめるのが大事です。JSON の変換やリフレクションで使うクラスが消されて、リリース版だけで落ちることがよくあります。クラッシュの解析用に mapping ファイルも毎回アップロードします。