MVI 架构更佳实践：支持 LiveData 属性监听

如上所示，Mavericks 的使用流程主要包括几个核心模块：

1. Model 层：包括页面所有状态的 data class，其中的状态全都是不可变的，并且通常有默认值。
2. ViewModel 层：负责处理业务逻辑，在其中通过 setState 来更新页面状态。
3. View 层：必须实现 MavericksView 接口，每当状态刷新时都会回调 invalidate 函数，在这里统一渲染 UI。

可以看出，Mavericks 中 View 层与 Model 层的交互并没有强制包装成 Action，而是直接暴露的方法。这种设计减少了样板代码，具体是否使用 Action 层主要取决于个人开发习惯。

支持局部刷新

上面介绍了 Mavericks 的简单使用，下面我们来看下 Mavericks 是如何实现局部刷新的。

data class UserState(
    val score: Int = 0,
    val previousHighScore: Int = 150,
    val livesLeft: Int = 99,
) : MavericksState {
    // 计算属性，不需要存储在 State 中，但可被监听
    val pointsUntilHighScore = (previousHighScore - score).coerceAtLeast(0)
    val isHighScore = score >= previousHighScore
}

class GameFragment : Fragment(R.layout.game_fragment), MavericksView {

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        // 直接监听 State 的属性，并且支持设置监听模式
        viewModel.onEach(UserState::pointsUntilHighScore, deliveryMode = uniqueOnly()) {
            // 仅当 pointsUntilHighScore 变化时触发
            updatePointsDisplay(it)
        }

        // 监听另一个属性
        viewModel.onEach(UserState::score) { 
            updateScoreDisplay(it)
        }    
    }
}

1. 如上所示，Mavericks 可以只监听 State 的其中一个属性来实现局部刷新，只有当这个属性发生变化时才触发回调，避免了全量刷新。
2. onEach 也可以设置监听模式，主要是为了防止数据倒灌。例如 Toast 这些只需要弹一次，页面重建时不应该恢复的状态，就适合使用 uniqueOnly 的监听模式。

Mavericks 实现属性监听的原理也很简单，其核心源码逻辑如下：

fun <VM : MavericksViewModel<S>, S : MavericksState, A> VM._internal1(
    owner: LifecycleOwner?,
    prop1: KProperty1<S, A>,
    deliveryMode: DeliveryMode = RedeliverOnStart,
    action: suspend (A) -> Unit
) = stateFlow
    // 通过对象取出属性的值
    .map { MavericksTuple1(prop1.get(it)) }
    // 值发生变化了才会触发回调，利用 distinctUntilChanged 去重
    .distinctUntilChanged()
    .resolveSubscription(owner, deliveryMode.appendPropertiesToId(prop1)) { (a) ->
        action(a)
    }

1. 主要是通过 map 将 State 转化为它的属性值。
2. 通过 distinctUntilChanged 方法开启防抖，相同的值不会回调，只有值修改了才会回调。
3. 需要注意的是因为使用了 KProperty1 反射机制，因此 State 的承载数据类必须避免混淆，否则编译后的属性名可能改变导致无法正确获取值。

LiveData 实现属性监听

上面介绍了 Mavericks 是怎么实现局部刷新的，但直接使用它主要有两个问题：

1. 接入起来略微有点麻烦，例如 Fragment 必须实现 MavericksView，有一定接入成本。
2. Mavericks 的局部刷新是通过 Flow 实现的，但相信大多数人现有的项目还是用的 LiveData，有一定学习成本和迁移成本。

下面我们就来看下如何在不引入额外框架的情况下，使用原生 LiveData 实现属性监听。

// 监听一个属性
fun <T, A> LiveData<T>.observeState(
    lifecycleOwner: LifecycleOwner,
    prop1: KProperty1<T, A>,
    action: (A) -> Unit
) {
    this.map {
        StateTuple1(prop1.get(it))
    }.distinctUntilChanged().observe(lifecycleOwner) { (a) ->
        action.invoke(a)
    }
}

// 监听两个属性
fun <T, A, B> LiveData<T>.observeState(
    lifecycleOwner: LifecycleOwner,
    prop1: KProperty1<T, A>,
    prop2: KProperty1<T, B>,
    action: (A, B) -> Unit
) {
    this.map {
        StateTuple2(prop1.get(it), prop2.get(it))
    }.distinctUntilChanged().observe(lifecycleOwner) { (a, b) ->
        action.invoke(a, b)
    }
}

// 内部辅助类
internal data class StateTuple1<A>(val a: A)
internal data class StateTuple2<A, B>(val a: A, val b: B)

// 更新 State 的扩展方法
fun <T> MutableLiveData<T>.setState(reducer: T.() -> T) {
    this.value = this.value?.reducer()
}

1. 如上所示，主要是添加一个扩展方法，也是通过 distinctUntilChanged 来实现防抖。
2. 如果需要监听多个属性，例如两个属性有其中一个变化了就触发刷新，也支持传入两个属性。
3. 需要注意的是 LiveData 默认是不防抖的，这样改造后就是防抖的了，所以传入相同的值是不会回调的。
4. 同时需要注意下承载 State 的数据类需要防混淆。

注意事项：ProGuard 配置

由于上述实现依赖于 Kotlin 的 KProperty1 反射机制来获取属性值，如果在发布版本中开启了代码混淆（R8/ProGuard），可能会导致属性名称被修改，从而无法正确获取值或抛出异常。因此，必须在混淆规则中保留相关的属性引用。

建议在 proguard-rules.pro 中添加以下规则：

# 保留 State 类及其属性
-keepclassmembers class com.yourpackage.model.** {
    *; # 或者指定具体的属性
}

# 保留 KProperty1 相关反射调用
-keepattributes Signature
-dontwarn kotlin.reflect.KProperty1

确保你的 State 类不会被完全移除或属性名被混淆，以保证运行时反射能够正常工作。

简单使用

上面介绍了 LiveData 如何实现属性监听，下面看下简单的使用场景。

// 页面状态，需要避免混淆
data class MainViewState(
    val fetchStatus: FetchStatus = FetchStatus.NotFetched,
    val newsList: List<NewsItem> = emptyList()
)

// ViewModel
class MainViewModel : ViewModel() {
    private val _viewStates: MutableLiveData<MainViewState> = MutableLiveData(MainViewState())
    // 只需要暴露一个 LiveData，包括页面所有状态
    val viewStates = _viewStates.asLiveData()

    private fun fetchNews() {
        // 更新页面状态
        _viewStates.setState {
            copy(fetchStatus = FetchStatus.Fetching)
        }
        viewModelScope.launch {
            when (val result = repository.getMockApiResponse()) {
                is PageState.Success -> {
                    _viewStates.setState {
                        copy(fetchStatus = FetchStatus.Fetched, newsList = result.data)
                    }
                }
            }
        }
    }

}

// View 层
class MainActivity : AppCompatActivity() {
	private fun initViewModel() {
        viewModel.viewStates.run {
            // 监听 newsList，列表数据变化时只刷新 RecyclerView
            observeState(this@MainActivity, MainViewState::newsList) {
                newsRvAdapter.submitList(it)
            }
            // 监听网络状态，状态变化时只显示 Loading 或错误提示
            observeState(this@MainActivity, MainViewState::fetchStatus) {
                showLoading(it == FetchStatus.Fetching)
                showError(it == FetchStatus.Error)
            }
        }
    }
}

如上所示，其实使用起来也很简单方便：

1. ViewModel 只需对外暴露一个 ViewState，避免了定义多个可变不可变 LiveData 的问题。
2. View 层支持监听 LiveData 的一个属性或多个属性，支持局部刷新，提升了渲染效率。

总结

本文主要介绍了 MVI 架构下如何实现局部刷新，并重点介绍了 Mavericks 的基本使用与原理，并在其基础上使用 LiveData 实现了属性监听与局部刷新。

通过以上方式，解决了 MVI 架构的性能问题，实现了 MVI 架构的更佳实践。即使你的 ViewModel 中定义了多个可变与不可变的 LiveData，就算你不使用 MVI 架构，支持监听 LiveData 属性相信也可以帮助你精简一定的代码，提升应用的响应速度。

在实际项目中，建议根据项目的复杂度选择合适的方案。如果项目已经大量使用 Flow，可以直接参考 Mavericks 的实现；如果是传统的 LiveData 项目，则可以使用本文提供的扩展方法进行改造。无论哪种方式，核心目标都是减少不必要的 UI 重绘，提升用户体验。