旦用难回 Jetpack MVI 最佳实践

[KunMinX]

如您已是 UnPeek-LiveData 资深玩家，今天这框架请不要错过 ——

刚于 Github 发行《 MVI 最佳实践》& 唯一可信源成熟态 “MVI-Dispatcher”，通过它可一举消除 “mutable 样板代码 + LiveData 连发事件覆盖 + LiveData.setValue 误用滥用” 等高频痛点问题，

欢迎 star 、test 、feedback 三连~

https://github.com/KunMinX/Jetpack-MVI-Best-Practice

[fromzero]

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

[fromzero]

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

[KunMinX]

根据你的阴阳怪气，很难让人不无语。就踩吧，黑吧，毁灭吧 ~

[xwdz9989]

营销鬼才

[yaocai321]

每次来 Android 节点发推广没人鸟你，心里没点数？
矫揉造作，直接去当 stormzhang 门徒得了，也好早日财务自由~

[cenbiq]

@fromzero 一直想找一个这样的库，感谢老铁

[XXWHCA]

@fromzero 明白这就看一楼推荐的库了解一下

[KunMinX]

演的还挺像。1 、2 、3 、4 、5 ，人差不多也齐了，来个大家整个 “三人成虎”。

[fromzero]

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

[fromzero]

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

[fromzero]

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

[fromzero]

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

[GetCore]

/go/flamewar

[KunMinX]

统一回复：

MVI 是实现单向数据流的一种方式，本质上是一种 IO 闭环，也即只要遵循函数式编程特性：唯一入口 + 唯一出口 + 无副作用，就可视作是 MVI 。

reduce 仅仅只是权宜之计，或者说主流解决方案，目的是在当下计算设备性能有限情况下，对状态集做的统一优化。实现 MVI 方式千千万，我个人认为 reduce 不能算是 MVI 本质。

至于 sample 案例中为什么没有为 “Intent” 字段添加 final ，那是因为 Java 下想要实现 Koltin val 同等效果，样板代码瞬间会飙出许多。val 是为了消除 数据一致性问题，而 java final 滋生的样板代码反而在日后容易滋生更多 “一致性问题”，

这几天腾出手开始解决这个问题，刚刚提交了可用于 Java 8 的 sealed class ，专门优化这问题。

最后，任何技术都存在演变的过程，没有什么一出生就是完美无缺，我希望一切都能实事求是交流，而不是高高在上的姿态嘲讽打击。

和所有我开源过的项目一样，MVI-Dispatcher 也是一个长期项目，我们希望打磨一个极低学习成本，在多数场景下都能稳定运作的框架。

[KunMinX]

也不能说是优化，应该说是一种细化和规范，提醒人们 newState 务必基于 oldState copy 而来，如果不是特别必要，比如如果业务细化程度不足以裂变出 partialChange ，那么在 MVP （最小可交付产品）设计中可以没有 reducer 。

目前觉得有必要引入 reducer 的场景在于事故高发地段，需要捕捉 state 变化的路径，乃至手动配置个 reducer 来管理 states 列表。