再Composeのスケジューリング（mutableStateOf）はアプリのパフォーマンスに直結する動作です。
状態の保持（remember）に並び、Jetpack Composeの重要な技術の一つです。
今回は「再Composeのスケジューリング」について、まとめます。
※環境：Android Studio Giraffe | 2022.3.1 Patch 1
Kotlin 1.8.10
Compose Compiler 1.4.3
目次
UI要素の役割
UI要素の役割は、時々刻々と変化する「状態」を表示して、ユーザーへ伝えることです。
「状態」とは、UI要素が主題とするコンテンツや、UI要素の形状・装飾などです。UI要素ごとに、表示すべき状態は異なります。
例えばTextは図のような状態を持ちます。※状態の一部を紹介
@Preview(showBackground = true)
@Composable
fun ClockPreview() {
MyApplicationTheme {
val _hour = 10 // 状態（コンテンツ）
val _min = 15
val _sec = 22
val _color = Color.Red // 状態（文字色）
val _fontSize = 24.sp // 状態（文字サイズ）
ClockPanel(
hour = _hour, min = _min, sec = _sec,
color = _color, fontSize = _fontSize
)
}
}
@Composable
fun ClockPanel(
hour: Int, min: Int, sec: Int,
color: Color, fontSize: TextUnit
) {
Text(
text = "%02d:%02d:%02d".format(hour, min, sec),
color = color, fontSize = fontSize
)
}
UI要素は関数
UI要素はComposable関数で表現されます。そして、UI要素が子UI要素を呼び出し、ツリー構造を作ることで、アプリの画面が構成されます。
Composable関数はKotlinの一般的な関数です。
関数は実行の枠を超えて、変数にデータを保持することが出来ません。関数内で宣言した変数の有効範囲は関数の中のみであり、有効期間は実行中のみです。実行の終了とともに、変数は破棄されます。
従って、UI要素が状態を表示するには、Composable関数が実行される毎に、状態を入力しなければなりません。なぜなら、状態を変数へ保持できないからです。入力は引数で行われます。
UI要素で構成されるUIツリー（最上位は関数）も同様です。
スケジューリング
状態が変更されて表示を更新したい時、UIツリーをトップからすべて再Composeすることは、無駄であり非効率です。
mutableStateOfは「状態が更新された関数を再Composeの対象として登録する仕組み」です。
状態が変更された関数をツリーの階層に関係なく登録できます。登録された関数は「直ちに再Compose」ではなく「次回の描画処理で再Compose」されます。
これにより、状態が変更されたUI要素のみを、再Composeできます。
この「再Composeの対象として登録する」ことを、ドキュメントは「Composeのスケジューリング」と表現しています。
※描画処理は「Jetpack Compose：Composeによるアプリ画面の描画」を参照
mutableStateOfの動作
mutableStateOfの動作を、次のようなサンプルを用いて説明します。
@Composable
fun Sample(...) {
val state = mutableStateOf(100) // state.valueのアクセスを監視
//
// state.valueを更新
//
}
状態の監視
mutableStateOfが実行されると、MutableStateクラスのオブジェクトを返します。
MutableStateクラスは引数と同じデータ型（Int）のvalueプロパティを持ち、状態が代入されます。初期値は引数の値です。
そして、valueに対するアクセスの監視を始めます。
更新の検出
valueが更新されると、valueを参照しているComposable関数が再Composeの対象へ登録されます。
その後、実行される描画処理により、登録された関数は再Composeされます。
※描画処理は「Jetpack Compose：Composeによるアプリ画面の描画」を参照
NGケースとOKケース
再Composeのスケジューリングを記述する場合、mutableStateOfの位置に注意が必要です。
NGケース
状態の監視を定義したmutableStateOfが、再Composeの範囲（Surface階層）に含まれています。
再Composeにより、再びmutableStateOfが実行されて、状態は初期値に戻されます。
setContent {
MyApplicationTheme {
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
Column {
val _counter = mutableStateOf(100)
Text(text = "Click count = %3d".format(_counter.value))
Button(onClick = { _counter.value++ }) {
Text(text = "Click")
}
}
}
}
}
以上により、表示が変化しません
OKケース
状態の監視を定義したmutableStateOfが、再Composeの範囲の上位（MyApplicationTheme）にあります。
再Composeにより、再びmutableStateOfが実行されることはありません。
setContent {
MyApplicationTheme {
val _counter = mutableStateOf(100)
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
Column {
Text(text = "Click count = %3d".format(_counter.value))
Button(onClick = { _counter.value++ }) {
Text(text = "Click")
}
}
}
}
}
以上により、表示が変化します。
しかし、別の要因により、MyApplicationThemeの再Composeが発生すれば、初期値に戻されます。
実用的な使い方
mutableStateOfの最も実用的な使い方は、状態を保持するrememberと合わせて使うことです。
setContent {
MyApplicationTheme {
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
Column {
val _counter = remember { mutableStateOf(100) }
Text(text = "Click count = %3d".format(_counter.value))
Button(onClick = { _counter.value++ }) {
Text(text = "Click")
}
}
}
}
}
rememberの働きにより、MutableStateオブジェクト（_counter）は再Composeを超えて保持されるようになります。再ComposeによりmutableStateOfが再実行されて、状態が初期化されることはありません。
先に挙げたNGケースが回避できます。
※remenberの働きは「Jetpack Compose：再Composeを超えて状態の保持（remenber）」を参照
関連記事：