我们是否仍然需要 Jetpack Compose 中的 LiveData，或者我们可以只使用 Compose State？

Question

我有一个如下所示的 ViewModel，它同时具有 LiveData 和 Compose State

@Suppress("UNCHECKED_CAST")
class SafeMutableLiveData<T: Any>(value: T) : LiveData<T>(value) {

    override fun getValue(): T = super.getValue() as T
    public override fun setValue(value: T) = super.setValue(value)
    public override fun postValue(value: T) = super.postValue(value)
}

class MainViewModel: ViewModel() {

    private val _liveData: SafeMutableLiveData<Int> = SafeMutableLiveData(0)
    val liveData: SafeMutableLiveData<Int> = _liveData

    var composeState: Int by mutableStateOf(0)

    fun triggerLiveData() {
        _liveData.value = _liveData.value + 1
        composeState++
    }
}

上面两者composeState都liveData做同样的事情，并由我的撰写视图使用，如下所示

    @Composable
    fun MyComposeView(viewModel: MainViewModel) {
        val liveDataResult = viewModel.liveData.observeAsState()
        Column {

            Button(onClick = { viewModel.triggerLiveData() }) {
                Text(text = "Click Me!")
            }

            Text(text = "${viewModel.number} ${liveDataResult.value}")
        }
    }

我注意到 LiveData 和 Compose State 值都是

• 方向改变时保留。
• OnRestoration 时销毁（应用程序被系统杀死）。
• 不要更新撰写视图，即当它的活动/片段容器不再存在时（例如，当片段/活动消失时，不会像 rxjava 回调那样使应用程序崩溃）。

看起来并LiveData没有比 增加更多的好处Compose State。它有更多的复杂性，比如我们需要添加.observeAsState()等等。

当我们仅在 Jetpack Compose 中编程时，是否有任何场景我们仍然应该在视图模型中使用变量LiveData而不是变量？Compose State

Answer 1

我看到接下来的情况仍然使用 LiveData：

1. 您将 ViewModel 与非 Compose 视图同时与 Compose 视图一起使用。在迁移到 Compose 的旧项目中可能会遇到这种情况，例如，如果您有旧视图和 Compose 视图的共享 ViewModel。
2. 您在项目的其他层中也有 LiveData。例如，您使用 LiveData 观察 Room 中的数据。
3. 您需要使用转换 API 来获得 LiveData map、switchMap或其他好处。

但 Google 对于使用哪种类型的 observable 并没有严格的要求，这主要取决于你的项目（需求、架构等）和偏好。Google 表示，除了 Compose State 之外，您还可以使用 LiveData、RxJava、Kotlin Flows，只需将其转换为 State https://developer.android.com/jetpack/compose/state#use-other-types-of-state-in -jetpack-compose

如果我们说的是您的示例，那么我相信您不需要在这种微不足道的情况下使用 LiveData。

在我看来，看看 Google 如何积极推广 JetPack Compose 和 Kotlin Flows，LiveData 很可能会在不久的将来的某个时候被弃用。