因为 View 本身就没有完整的生命周期的概念，View 只有 attachWindow dettachWindow 这些，View 完全跟随 Fragment/Activity 的生命周期，View 属于 ui 组件，而不是 ui 容器，容器是用来装控件的，所以有生命周期的概念。而 ViewModel 的生成和销毁是需要伴随宿主的生命周期的。

@VERTU 各有取舍，flipper 侵入性强但是仅仅 debug 而已，实现的功能也不只于 layout

@tidezyc 是的 还是挺稳的。

@tidezyc 可以试试，我断了梯子，还一直给我推送

telegram 的 gmail 机器人断了梯子还能继续推通知。要先连成功一次

你的 ui 基于事件驱动，当然不可避免会有粘性事件的场景。跟人家 flow 和 repeatLifeCycle ,甚至 livedata 没有半毛关系，人家本来就不是为这种场景设计的。
贬低 Android 官方，抬高自己？显得你很牛逼？
这种延迟 1ms 的解决方案看起来也很奇葩，感觉你对这个粘性事件着魔了一样，围绕着大作文章。

@KunMinX 说实话分析完我是吓一跳的，我原本还是挺认可你的技术的，虽说喜欢造新名词，但是之前的技术文章多少有几篇还不错的，我今天去看了一下你的重学 android 已经涨到￥ 379 了，静下心多打磨点干货吧。

总结（仅仅是本菜鸡的个人观点）：
整体架构看起来没啥问题，用户触发事件，请求数据，ui 监听事件改状态刷新 ui ，完美的单向数据流👍🏻。but
* 违反不可变，比如我在监听处偷偷修改 event 里面的值，直接破坏其他监听者的逻辑
* 没有状态机，只有一个 Event 事件队列机来发事件，通过监听 event 的数据，然后扔给给状态，而且状态这个变量 mStates 是由 ui 自己维护的（我自己维护我自己的状态？不应该是监听状态吗？）

@fromzero 不可变这里我看错了一丢丢，爱坤大神这里的 event 应该是代表每个 intent 产生的事件，但是数据什么的都包在 event 里面，然后再把 event 的数据赋值给 state 刷新，这里 state 的赋值也违法了不可变，那这里也很奇怪，我干嘛不直接拿 event 的数据刷新呢，out 监听的为什么是 event 不是 state ，那不是变成了 事件驱动 ui 而不是状态驱动 ui ？ 

@KunMinX 今天闲来无事，先来分析你的代码吧。 首先，mvi 的关键核心是状态机，不可变的状态，以及单向的数据流向，这也是现代声明式 ui 的思想，故 mvi 和 compose flutter 以及 swift ui 是十分契合的。大神的最佳实践中的 Event 应该就是 state 了，页面通过 out 订阅 state 的变化更新 ui ，这个没问题，但是不可变呢？你为什么直接更改 event 里的值啊？你这里也没有 reducer 的体现啊？ 另外 side effect 的情况本最佳实践怎么处理呢？

想学习 mvi 的同学大可直接去看 aribnb 的 https://github.com/airbnb/mavericks ，基于 jetpack flow ，里面的代码质量细细研读会有很多收获

又来发明新名词了，前端用烂的单向数据流。不说了，赶紧出付费教程，我第一个当韭菜

期待把 ide 的功能抄过来，我用的最多的是，cherry pick/squash commit ，筛选某个 user 的 commit ，筛选日期

@mxalbert1996 twitter 也只是在不紧要的 三级页面用了 compose 。什么时候有大型 App 敢把首页重构成 Compose 代表这个东西成熟了

黑果没必要。万一搞出问题折腾半天

八股文 搜一下网上都是答案。-_-||

@yilindoudou 是的 声明示 ui 已经是未来，前端都玩烂了