Composable收集StateFlow时类型转换异常的根因排查

在Composable函数中收集StateFlow时遇到类型转换异常，尽管已经做了类型检查，首次调用viewModel.fetchFixtures()时代码正常运行，但再次调用该方法就会抛出无法转换的异常。将代码修改为val uiState = fixtureStateFlow.collectAsState().value后，问题消失。想了解该问题的根本原因。

相关代码 #

Home Composable代码 #

@Composable
fun Home(
    ...
) {
    ...
    val uiState by viewModel.fixtureStateFlow.collectAsState()
    when (uiState) {
        is UiState.Loading -> Box(modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
            CircularProgressIndicator()
        }

        is UiState.Success<List<Fixture>> -> LazyColumn(
            modifier.fillMaxSize(),
            contentPadding = PaddingValues(16.dp)
        ) {
            items((uiState as UiState.Success<List<Fixture>>).data) { fixture -> // 异常抛出位置
                FixtureItem(fixture = fixture) {
                    println("Clicked")
                }
            }
        }
    }
}

ViewModel代码 #

@HiltViewModel
class HomeViewModel @Inject constructor(
    ...
) : ViewModel() {
    ...
    private val _fixturesUiState = MutableStateFlow<UiState<List<Fixture>>>(UiState.Loading)
    val fixturesUiState = _fixturesUiState.asStateFlow()

    fun fetchFixtures(date: LocalDate) {
        viewModelScope.launch(coroutineExceptionHandler) {
            _fixturesUiState.value = UiState.Loading
            _fixturesUiState.value = UiState.Success(GetFixtures(repository, date).execute())
        }
    }
}

sealed class UiState<out T> {
    object Loading : UiState<Nothing>()
    class Success<T>(
        val data: T
    ) : UiState<T>()
}

异常堆栈跟踪 #

FATAL EXCEPTION: main
Process: com.dainghia.brewfootball, PID: 21288
java.lang.ClassCastException: com.dainghia.brewfootball.ui.UiState$Loading cannot be cast to com.dainghia.brewfootball.ui.UiState$Success
at com.dainghia.brewfootball.ui.main.composable.FixtureListKt$FixtureList$2$1.invoke(FixtureList.kt:53)
at com.dainghia.brewfootball.ui.main.composable.FixtureListKt$FixtureList$2$1.invoke(FixtureList.kt:52)
at androidx.compose.foundation.lazy.LazyListItemProviderKt$rememberLazyListItemProvider$1$itemProviderState$1.invoke(LazyListItemProvider.kt:54)
at androidx.compose.foundation.lazy.LazyListItemProviderKt$rememberLazyListItemProvider$1$itemProviderState$1.invoke(LazyListItemProvider.kt:53)
at androidx.compose.runtime.snapshots.Snapshot$Companion.observe(Snapshot.kt:2200)
at androidx.compose.runtime.DerivedSnapshotState.currentRecord(DerivedState.kt:161)
at androidx.compose.runtime.DerivedSnapshotState.getCurrentValue(DerivedState.kt:231)
at androidx.compose.runtime.snapshots.SnapshotStateObserver$ObservedScopeMap.recordInvalidation(SnapshotStateObserver.kt:523)
at androidx.compose.runtime.snapshots.SnapshotStateObserver.drainChanges(SnapshotStateObserver.kt:66)
at androidx.compose.runtime.snapshots.SnapshotStateObserver.access$drainChanges(SnapshotStateObserver.kt:38)
at androidx.compose.runtime.snapshots.SnapshotStateObserver$applyObserver$1.invoke(SnapshotStateObserver.kt:45)
at androidx.compose.runtime.snapshots.SnapshotStateObserver$applyObserver$1.invoke(SnapshotStateObserver.kt:43)
at androidx.compose.runtime.snapshots.SnapshotKt.advanceGlobalSnapshot(Snapshot.kt:1768)
at androidx.compose.runtime.snapshots.SnapshotKt.advanceGlobalSnapshot(Snapshot.kt:1779)
at androidx.compose.runtime.snapshots.SnapshotKt.access$advanceGlobalSnapshot(Snapshot.kt:1)
at androidx.compose.runtime.snapshots.Snapshot$Companion.sendApplyNotifications(Snapshot.kt:568)
at androidx.compose.ui.platform.GlobalSnapshotManager$ensureStarted$1.invokeSuspend(GlobalSnapshotManager.android.kt:46)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at androidx.compose.ui.platform.AndroidUiDispatcher.performTrampolineDispatch(AndroidUiDispatcher.android.kt:81)
at androidx.compose.ui.platform.AndroidUiDispatcher.access$performTrampolineDispatch(AndroidUiDispatcher.android.kt:41)
at androidx.compose.ui.platform.AndroidUiDispatcher$dispatchCallback$1.run(AndroidUiDispatcher.android.kt:57)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7884)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Suppressed: kotlinx.coroutines.DiagnosticCoroutineContextException: [androidx.compose.ui.platform.AndroidUiFrameClock@b9756e1, StandaloneCoroutine{Cancelling}@eeebc06, AndroidUiDispatcher@b9412c7]

根本原因 #

问题出在Compose的快照状态机制与LazyColumn的内部状态订阅逻辑：

1. 使用val uiState by viewModel.fixtureStateFlow.collectAsState()时，uiState是一个Snapshot State，它会在Compose重组过程中跟踪状态变化，确保重组基于一致的状态快照。
2. 再次调用fetchFixtures()时，你在同一个协程中连续更新两次StateFlow：先设为Loading，立刻又设为Success。虽然这两个更新几乎同时发生，但Compose的快照机制可能延迟处理中间的Loading状态，或者LazyColumn内部创建的派生快照状态（用于跟踪数据源）会捕捉到状态变化的中间过程。
3. 当LazyColumn的内部状态还持有之前的Success类型判断时，实际的uiState可能已经回退到Loading状态，此时执行显式类型转换uiState as UiState.Success就会抛出类型转换异常。

而修改为val uiState = fixtureStateFlow.collectAsState().value时，你直接获取了当前快照的不可变值，每次重组都会拿到最新的状态快照，避免了LazyColumn内部状态与当前uiState不一致的情况。

正确实现方式 #

除了直接取.value，更规范的做法是利用Kotlin的智能转换，同时确保状态处理的一致性：

@Composable
fun Home(
    viewModel: HomeViewModel
) {
    val uiState by viewModel.fixturesUiState.collectAsState()
    when (uiState) {
        UiState.Loading -> Box(modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
            CircularProgressIndicator()
        }
        is UiState.Success<List<Fixture>> -> {
            // 利用智能转换，无需显式as
            val fixtureList = uiState.data
            LazyColumn(
                modifier.fillMaxSize(),
                contentPadding = PaddingValues(16.dp)
            ) {
                items(fixtureList) { fixture ->
                    FixtureItem(fixture = fixture) {
                        println("Clicked")
                    }
                }
            }
        }
    }
}

另外，也可以在ViewModel中确保状态更新的原子性，但由于Compose快照机制的特性，上述利用智能转换的方式已经能避免类型转换异常。

内容的提问来源于stack exchange，提问作者dainghia.tran