前言：由于框架本身也在不断地迭代，因此文章中的部分代码可能存在更新或者过时，如果你想阅读源码或者查看代码的在项目中的实际使用方法，可以查看笔者目前在维护的compose项目：Spacecraft: 《Spacecraft - 我的安卓技术实践平台》-查看代码请进入develop分支 (gitee.com)
关于安卓的MVI架构
近些年安卓的架构发展的真是非常迅速，笔者入行不久，就已经从MVC，MVP一路干到MVVM，自以为对MVVM非常熟悉，略有心得的时候，谷歌稍稍的更新了开发者文档(应用架构指南 | Android 开发者 | Android Developers (google.cn))
虽然通篇没有涉及到MVI，但是许多业内的小伙伴，特别是前端开发表示，开发文档中提到的单向数据流，唯一数据源，不正是MVI区别于MVVM的最显著的特征吗？
作为一个常年上班摸鱼钻研的新油条，果断研究起来，于是在翻阅了谷歌的开发文档、掘金上大佬写的文章以及阅读了几个开源MVI架构项目之后，自己也动手折腾了一个小DEMO，表示真香，但是也发现了一些问题。
注意：如果你对MVI架构没有任何认识，请在掘金阅读相关MVI架构文章或者阅读谷歌开发者文档之后，再继续阅读下文
遇到的小问题
1. 状态？事件！
MVI架构中，特别是谷歌推崇的开发模式，是将整个页面的状态存放于单一的类中，而且这个类必须是Kotlin的data class，因为kotlin的这个特殊的类自带了copy功能，非常方便去更新部分的属性，于是我们就有了下面的一个类：
data class NewsUiState( val isSignedIn: Boolean = false, val isPremium: Boolean = false, val newsItems: List<NewsItemUiState> = listOf(), val userMessages: List<Message> = listOf() ) data class NewsItemUiState( val title: String, val body: String, val bookmarked: Boolean = false, ... )
Ok，我们有了一个Ui的状态，其实如果你懂电影或游戏中的帧的概念的话，这个UiState实际上就是页面的一帧或很多帧，这样解释或许不恰当，但是足够你理解这个概念，也就是说，ViewModel只需要向Ui提供当前的状态就好了，至于UI拿到这个数据之后如何去展示显示UI，就和ViewModel没关系了。
目前为止，一切都很美好，数据流是单向流向viewModel，响应式...
但是，如果你注意到NewsUiState里面有个属性userMessages，在文档中，这个属性被用来充当ViewModel需要向Ui发送的通知，例如Toast之类的。
从这里开始一切都变得怪异起来了，你往一个表示状态的容器里面填充了一些事件，而且使用了列表，则说明事件需要被消费掉，否则越填充越多，更严重的是会产生数据倒灌的问题，当你切换到手机主页再切换回APP的时候，UI会尝试从ViewModel的状态流中取数据，然后将本应该消费掉的Toast事件又取出来消费一遍，于是出现了下面的场景：
当一个用户输错了密码之后，APP提示“密码错误，请重试”，他切换到其他APP又切回来的时候，发现APP又继续提示“密码错误，请重试”，即使他没有做任何操作 、
一切的问题根源都是来源于，UiState表示的是一种状态而非一种事件容器，因此如果你把事件填充进去，Ui就会尝试反复取出他，执行特定的逻辑，于是Toast被反复调用了。
此刻大多数人的第一反应是：Ui去更新viewModel中UiState的值。但是别忘了，MVI可是单项数据流动的呀，UI可不能去直接修改viewModel中的值！
正当笔者大呼谷歌RNM退钱的时候，发现谷歌在文档中写了解决方案，如下：
lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState.collect { uiState -> uiState.userMessages.firstOrNull()?.let { userMessage -> // TODO: Show Snackbar with userMessage. // Once the message is displayed and // dismissed, notify the ViewModel. viewModel.userMessageShown(userMessage.id) } ... } } }
哇哦，谷歌爸爸真的好聪明呀，既然Ui不能直接修改viewModel的值，那viewModel就提供一个方法给Ui调用不就行了，每次UI消费了这些一次性事件，就去调用一次viewModel提供的方法，然后viewModel去删除列表中被消费的事件对象，这就问题解决了，谷歌爸爸赛高！对此，笔者再次重申：
如果你是一个对代码坏味道敏感的人，可能已经隐隐约约闻到了一股屎味，没错请相信你的直觉。说好的响应式呢，结果还是要手动去维护事件的消费，万一我忘了呢，完蛋又出现bug了。
