引子
MVI 是Model-View-Intent的简称，它们分别表示。。。。。
我并不打算逐个字母介绍它们代表的意思。因为这样一点也不能增进对 MVI 的理解，反而会对它的认识蒙上厚厚的一层迷雾。
奥古斯都在《忏悔录》里面问我这样一个问题：“时间到底是什么？你不问我的时候，我是知道的；你一问我，我就不知道了。”
把“时间”换成“MVI”，这个问题同样困扰着我：“MVI 到底是什么？你不问我的时候，我是知道的；你一问我，我就不知道了。”
维特根斯坦会说，上面是一个非法的问题，源于错误地使用了语言。
正确的问题应该是这样问的：人们在什么场景下使用 MVI，他们是怎么使用 MVI 的？他们为什么会使用 MVI？
唯一可信数据源
请原谅我，还是使用了这么拗口的一个名词作为本节的开始。
会试着从日常开发中熟悉的场景出发，一步步演绎出什么叫“唯一”，什么叫“可信”。
假唯一数据源
假设下面这个场景： “一个可以发帖的社区界面，未加入社区时发帖按钮是置灰不能点击的，当以版主身份进入社区时发帖按钮是红色，当被禁言后按钮变黑。”
最初我是这样实现的：
class CommunityActivity : AppCompatActivity() { private val postBtn: Button override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val userInfo = viewModel.getUserInfo() // 从服务器获取的用户身份状态信息 postBtn.apply {...} // 初始化发帖按钮 } override fun onEnter(identity: Identity) { postBtn.apply {...} // 加入社区后刷新发帖按钮（依赖 Identity） } override fun onExit() { postBtn.apply {...} // 退出社区后刷新发帖按钮 } override fun onMute(mute: Mute) { postBtn.apply {...} // 禁言后刷新发帖按钮 （依赖 Mute） } }
这样写对于功能实现来说没毛病，但维护起来会很头痛，因为一个控件的更新逻辑散落在 Activity 的各个地方，并且更新控件所依赖的数据是五花八门的，即未做到依赖单一数据源。界面简单还好，若复杂界面中有十几个这样的控件，Activity 的代码没法看。
这样实现还会增加 bug 数。假设发布按钮置灰的样式更改了，就需要改两个地方，分别是初始化和退出社区的回调中。这是一个潜规则，容易出错，当代码中隐匿着众多这样的潜规则时，且之前还不是你维护的，那就等着和测试小姐姐相约在午夜吧~。
迭代总是赶的，重构总是被提上议程（且它一直在议程上），每次迭代只能无可奈何地按照原先的写法，把坑挖的更深一点。若干次迭代后，这个模块已经不堪入目。在产品会上，它的迭代估时总是会更长一些。。。
稍好一点的写法是将发布按钮的更新逻辑封装在一个方法内：
class CommunityActivity : AppCompatActivity() { private val postBtn: Button override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val userInfo = viewModel.getUserInfo() updatePostBtn() } override fun onEnter(identity: Identity) { updatePostBtn(identity) } override fun onExit() { updatePostBtn() } override fun onMute(mute: Mute) { updatePostBtn(mute) } private fun updatePostBtn(mute: Mute?, identity: Identity?, userInfo: UserInfo?){ postBtn.apply {...} } }
这为代码维护提供了极大的便利，因为可以实现改一处，多处联动。
但美中不足的是，发布按钮的更新需要依赖三个数据源，分别是禁言、身份信息、用户信息。
只要它们中的任何一个发生变动，都会影响到发布按钮的显示状态，这样的写法是耦合的。这使得界面展示和业务逻辑耦合在一起，若业务变化，比如新增了一种触发按钮样式变更的情况，则 updatePostBtn() 得跟着改。
按钮其实不关心禁言、身份信息、用户信息。它只关心应该展示什么背景色、是否可以点击。所以这些信息应该抽象成一个按钮的界面状态：
data class PostBtnState( var clickable: Boolean, // 是否可点击 var backgroundColor: Int, // 背景色 var text: String, // 按钮名称 )
然后按钮更新方法就得以解耦，简化：
private fun updataPostBtn(state: PostBtnState){ postBtn.apply {...} }
Flutter 就是这样做的，每一个控件都会对应一个“数据”。并且数据在按钮构建时就和它绑定了
关于 Flutter 的介绍及应用，可以关注我的专栏：Flutter 关键概念解析 - 唐子玄的专栏
现在代码进化成如下状态：
class CommunityActivity : AppCompatActivity() { private val postBtn: Button private val state: PostBtnState override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val userInfo = viewModel.getUserInfo() updateState() updatePostBtn(state) } override fun onEnter(identity: Identity) { updateState() updatePostBtn(state) } override fun onExit() { updateState() updatePostBtn(state) } override fun onMute(mute: Mute) { updateState() updatePostBtn(state) } private fun updateState(){ state.apply {...} } private fun updatePostBtn(state: PostBtnState){ postBtn.apply {...} } }
这就完成了唯一数据源，即控件刷新所依赖的数据只有一个。（不过这里的唯一是假的，真的在下下节）
解耦 & 唯一刷新点
现在 Activity 持有了一个按钮对应的状态实例，更新操作只依赖该状态。但更新按钮的触发还是散落在 Activity 中不同的地方，对按钮来说依然有多个刷新点，这容易出错。
而且此时“界面状态”和“界面元素”混在了一起，界面简单还好，对于复杂界面就会形成上帝 Activity。从另一个角度看，界面展示和业务逻辑耦合在一起，使得抽取共用逻辑成为不可能。
比如另外一个版本的社区，按钮的交互逻辑完全一样，只是样式不同，当前 CommunityActivity 的代码就无法复用，只能复制粘贴，改界面。交互逻辑统一变动时，得改两个 Activity 的代码。
谷歌给出第一版的解决方案是 MVP，即将界面状态抽离到 Presenter 中，实现了界面元素和界面状态的分离。
但 Presenter 有两个缺点：
- Presenter 通过接口方式和 Activity 耦合，且通信接口膨胀。
- Presenter 在界面翻转时数据重新加载。
所以就有了 MVP 的升级版 MVVM。数据驱动是 MVVM 的关键词，ViewModel 不再主动调用方法去更新界面，而是主动更新数据，同时界面采用观察数据的方式，等待被更新。
关于 MVP 和 MVVM 的详尽分析可以点击我是怎么把业务代码越写越复杂的 | MVP - MVVM - Clean Architecture
“多个刷新点”的问题就迎刃而解了：用一个集线器把多个更新源约束为一个更新源。这个集线器就是带数据驱动的 ViewModel：
class CommunityViewModel : ViewModel() { // 将按钮 Model 组织成私有的可变 LiveData private val _postBtnLiveData = MutableLiveData<PostBtnState>() // 公开的不可变 LiveData val postBtnLiveData: LiveData<PostBtnState> = _postBtnLiveData // 唯一的更新按钮 Model 的入口 fun updatePostBtnState(state: PostBtnState) { _postBtnLiveData.value = state } }
首先，ViewModel 是一个数据持有者，界面状态被存储在 LiveData 中，这样就和界面元素分离了，生命周期更长了，而且还能感知生命周期。
其次，更新状态有了唯一入口 updatePostBtnModel()，可变的 LiveData 被定义为私有的，只公开不可变的版本。这些都暂时保证了更新状态的唯一数据源。
然后界面只需观察唯一数据源即可：
class CommunityActivity : AppCompatActivity() { private val viewModel: CommunityViewModel by activityViewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val userInfo = viewModel.getUserInfo() viewModel.updatePostBtnState() // 观察唯一数据源 viewModel.postBtnLiveData.observer(this) { updatePostBtn(it)// 唯一刷新点 } } override fun onEnter(identity: Identity) { viewModel.updatePostBtnState(identity.toPostState()) } override fun onExit() { viewModel.updatePostBtnState() } override fun onMute(mute: Mute) { viewModel.updatePostBtnState(mute.toPostState()) } private fun updatePostBtn(state: PostBtnState){ postBtn.apply {...} } } fun Mute.toPostState(): PostBtnState {...} fun Identity.toPostState(): PostBtnState {...}
通过数据驱动的方式实现了界面展示和界面状态分离，实现了解耦以及界面层的唯一刷新点。
真唯一数据源
故事还没讲完：点击发帖会展示一个全屏置灰的 loading，发帖按钮展示“发送中...”。若网络不好，则常驻显示“发帖失败请检查网络”（类微信聊天列表顶部效果）。若帖子包含敏感词，则会弹出警告。若发帖成功，则展示一个打钩动画。
按照之前的思路，很容易写出如下的 ViewModel：
class CommunityViewModel : ViewModel() { // 按钮状态数据源 private val _postBtnLiveData = MutableLiveData<PostBtnState>() val postBtnLiveData: LiveData<PostBtnState> = _postBtnLiveData // loading 数据源 private val _postingLiveData = MutableLiveData<Boolean>() val postingLiveData: LiveData<Boolean> = _postingLiveData // 弱网数据源 private val _poorNetworkLiveData = MutableLiveData<Boolean>() val poorNetworkLiveData: LiveData<Boolean> = _poorNetworkLiveData // 敏感词数据源 private val _badWordLiveData = MutableLiveData<String>() val badWordLiveData: LiveData<String> = _badWordLiveData // 发帖成功数据源 private val _successLiveData = MutableLiveData<Boolean>() val successLiveData: LiveData<Boolean> = _successLiveData // 发帖 fun post(){ _postingLiveData.value = true _postBtnLiveData.value = PostBtnState(text = "发送中..", clickable = false) viewModelScope.launch(Dispatchers.IO) { val response = api.post() // 你猜这样写会有什么问题吗？ if(response.isFailed){ _poorNetworkLiveData.postValue(true) } else { when(response.code) { CODE_BAD_WORD -> _badWordLiveData.postValue("敏感词") else -> _successLiveData.postValue(true) } } _postingLiveData.postValue(false) _postBtnLiveData.postValue(PostBtnModel(text = "发送", clickable = true)) } } }
对应地，界面需要观察新增的数据源：
class CommunityActivity : AppCompatActivity() { private val viewModel: CommunityViewModel by activityViewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 1. 观察按钮状态 viewModel.postBtnLiveData.observer(this) { updatePostBtn(it) } // 2. 观察 loading 状态 viewModel.postingLiveData.observer(this) { showLoading(it) } // 3. 观察弱网状态 viewModel.poorNetworkLiveData.observer(this) { showPoorNetwork(it) } // 4. 观察敏感词状态 viewModel.badWordLiveData.observer(this) { showBadword(it) } // 5. 观察发帖成功状态 viewModel.successLiveData.observer(this) { showPostSuccess(it) } } }
“发帖”这个业务逻辑的整个生命周期中，用了 5 个数据源来表达。（这仅是社区界面的冰山一角，一长串观察 LiveData 的代码是这种写法的特点）
扑面而来的就是 “复杂度”，为了理解发帖的界面状态，必须得理清 5 个数据源之间的关系。凝视这样的代码，你无法想象出发帖界面会长成什么样子，因为引起它变化的因素太多，每一个数据源的变化都会影响展示。
紧跟其后的就是 “bug”，多数据源的复杂度除了理解困难，还容易催生 bug。上面的代码就中招了。当用户第一次点击发帖时，正好网络不佳，于是常驻的“发帖失败请检查网络”显示出来。用户第二次点击发帖成功了，于是发帖成功动画会和弱网提示一同显示在界面上。因为我忘记在网络请求成功时，把 _poorNetworkLiveData 的值置为 false。状态太多，在所难免。。。
这不是 MVVM 独有的问题，MVP 也可以有类似的版本，对应的表现形式在 View 层接口：
interface PostViewInterface{ fun showPoorNetwork() fun showPostSuccess() fun showPostLoading() fun updatePostBtn() }
解决方案是 “唯一数据源”：
data class PostState( var clickable: Boolean = true, // 是否可点击 var backgroundColor: Int = 0xFF00FF, // 背景色 var text: String = "发帖", // 按钮名称 var loading: Boolean = false, // 是否发帖中 var poorNetwork: Boolean = "", // 弱网失败 var badWord: String = "",// 敏感词失败 var success: Boolean = false // 是否发帖成功 )
将所有和发帖这个业务相关状态都保存在一个数据类中。
ViewModel 持有这个数据：
class CommunityViewModel : ViewModel() { // 发帖状态数据源 private val _postStateLiveData = MutableLiveData<PostState>() val postStateLiveData: LiveData<PostState> = _postStateLiveData fun post(){ _postStateLiveData.value = PostState( clickable = false, loading = true, text = "发送中..." ) viewModelScope.launch(Dispatchers.IO) { val response = api.post() if(response.isFailed){ _postStateLiveData.postValue(PostState(poorNetwork = true)) } else { when(response.code) { CODE_BAD_WORD -> _postStateLiveData.postValue(PostState(badWord = "敏感词")) else -> _postStateLiveData.postValue(PostState(success = true)) } } } } }
界面观察这个数据：
class CommunityActivity : AppCompatActivity() { private val viewModel: CommunityViewModel by activityViewModels() private val postBtn: Button override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 观察发帖状态 viewModel.postStateLiveData.observer(this) { updatePost(it) } } private fun updatePost(state: PostState) { postBtn.apply { text = state.text clickable = state.clickable backgroundColor = state.backgroundColor } if(state.loading) showLoading() if(state.badWord.isNotEmpty()) showBadWord(state.badWord) if(state.poorNetwork) showPoorNetwork() if(state.success) showPostSuccess() } }
在定义界面状态时，也可以使用继承，这样可以让每个不同控件的状态只包含在自己的子类中。简单起见，demo 只是把所有的属性堆在一个类中。
难道一个界面中所有控件的状态都应该用一个 State 来表达，以做到唯一数据源？
理论上讲是的，但这样做会带来麻烦。对于复杂界面来说，State 会变成上帝类。每次对 State 的更新会超级费劲。
中庸之道是将整个界面分成若干个相互独立的状态，独立的意思是控件状态不会相互影响，即控件A的任何变化不会引起控件B的任何变化，则AB相互独立。这就很像 Clean Architecture 中的 Use Cases 了，即一整套业务逻辑可以被分割成相互独立的用户故事。
关于 Clean Architecture 的详解可以点击我是怎么把业务代码越写越复杂的 | MVP - MVVM - Clean Architecture
唯一数据源，就好比 y = f(x)，即给定一个 x（界面状态），必定会得到唯一 y（界面展示）。若换成 y = f(a, b, c, d)，这个函数就很复杂了，计算 y 值就容易出错。
除了容易出错，还不容易排查错误，当 y 的值不符合预期时（界面 bug），因变量太多，遂找很难定位导致它错误的变量，于是乎一个必现 bug，硬生生地被变成一个偶现 bug。（测试小姐姐又背锅了，“你无法复现，我怎么解？”）
可信数据源
这样写还是要出事，当进入社区时，会根据用户身份展示不同样式的发帖按钮。但在发帖的逻辑中是通过新建 PostState 实例来更新状态的，这样就会丢失原有按钮样式，所以得由上次状态生成新状态：
class CommunityViewModel : ViewModel() { private val _postStateLiveData = MutableLiveData<PostState>() val postStateLiveData: LiveData<PostState> = _postStateLiveData fun post(){ // 获取当前状态 val currentState = _postStateLiveData.value // 更改当前状态值 _postStateLiveData.value = currentState.apply { clickable = false, loading = true, text = "发送中..." } viewModelScope.launch(Dispatchers.IO) { // 获取当前状态并修改之 val currentState = _postStateLiveData.value val response = api.post() if(response.isFailed){ _postStateLiveData.postValue(currentState.apply { poorNetwork = true }) } else { when(response.code) { CODE_BAD_WORD -> _postStateLiveData.postValue( currentState.apply { badWord = "敏感词" } ) else -> _postStateLiveData.postValue( currentState.apply {success = true } ) } } } } }
这样写接着出事。。。
现在_postStateLiveData.value成了“共享变量”，会存在多线程并发读写，存在线程安全问题。
解决办法是COW，即 copy on write，在写变量的时候先拷贝源变量，然后对副本写。
关于 COW 的详细分析可以点击面试题 | 有用过并发容器吗？有！比如网络请求埋点
为了禁止变量的直接写操作，遂把唯一数据源的所有字段都定义成 val：
data class PostState( val clickable: Boolean = true, val backgroundColor: Int = 0xFF00FF, val text: String = "发帖", val loading: Boolean = false, val poorNetwork: Boolean = "", val badWord: String = "", val success: Boolean = false )
val 禁用了通过currentState.apply { poorNetwork = true }更新状态，而强迫使用下面这种方式：
class CommunityViewModel : ViewModel() { private val _postStateLiveData = MutableLiveData<PostState>() val postStateLiveData: LiveData<PostState> = _postStateLiveData fun post(){ val currentState = _postStateLiveData.value // 使用 copy() 浅拷贝 _postStateLiveData.value = currentState.copy ( clickable = false, loading = true, text = "发送中..." ) viewModelScope.launch(Dispatchers.IO) { val currentState = _postStateLiveData.value val response = api.post() if(response.isFailed){ // 使用 copy() 浅拷贝 _postStateLiveData.postValue(currentState.copy ( poorNetwork = true )) } else { when(response.code) { // 使用 copy() 浅拷贝 CODE_BAD_WORD -> _postStateLiveData.postValue( currentState.copy ( badWord = "敏感词" ) ) // 使用 copy() 浅拷贝 else -> _postStateLiveData.postValue( currentState.copy ( success = true ) ) } } } } }
copy() 是 data class 自带的浅拷贝方法，若成员是集合结构，还需自行实现深拷贝。
这就实现了 “可信数据源”，可信的意思就是它是安全的，不会发生不一致的情况。
经过如此这般地重构，从 “假唯一数据源” 到 “真唯一数据源” 最后到 “唯一可信数据源”。
