这是一个创建于 859 天前的主题，其中的信息可能已经有所发展或是发生改变。
如您已是 UnPeek-LiveData 资深玩家，今天这框架请不要错过 ——
刚于 Github 发行《 MVI 最佳实践》& 唯一可信源成熟态 “MVI-Dispatcher”，通过它可一举消除 “mutable 样板代码 + LiveData 连发事件覆盖 + LiveData.setValue 误用滥用” 等高频痛点问题，
欢迎 star 、test 、feedback 三连~
第 1 条附言 · 2022-07-30 13:26:05 +08:00
1.互联网非说理地，评论区是我地盘，我是这的地头蛇。你在我地盘发表作品，就得照顾我大师光环，否则别怪我随便找个理由嘲讽打压抬杠抹黑引战孤立，以针对你个人进行人身攻击寻求优越感。
2.Base64 是一好东西，然实践过程中易得，标准 Base64 在 URL 场景下存在不可预期问题，故业界萌生 Base64 改良版 Base64.UrlEncoder 作为最佳实践。
同理，响应式编程、MVI 属理想化模型，在实践过程中易得，标准 MVI 在 Java 命令式编程 Android View 页面开发场景下存在不可预期问题，故萌生 MVI 改良版为最佳实践。
3.你说这么多没用，我就是要随便找个理由打压你 —— 你这改良版，和理想化实验环境理论模型有出入，你这设计违背理想化理论，故你就是水平臭，你就是对 MVI 理解有偏差，你活该被指责攻击。
4.你不该对 “最佳实践” 感兴趣，更不该公开分享，你公开分享，就是在挑衅别人大师光环，你都 “最佳” 了，别人怎么办？
5.别指望别人去查百科了解 “最佳实践” 含义 —— 最佳实践（ best practice ）是一管理学概念，“认为存在某种技术、方法、过程、活动或机制可使生产或管理实践结果达到最优，并减少出错可能性”。
6.如不想因为 “最佳实践” 被杠，你最好别取《 MVI 最佳实践》这样标题，最好是《在 MVI 基础上，根据广泛实践，形成某种改良版，以使生产或管理实践结果达到最优，并减少不可预期错误》。
7.不过，就算你标题有 45 字这么长也不行，欲加你罪，何患无辞。就是妒忌你，总有理由三人成虎泼你脏水。你越认真，越有理由黑你。
8.你以后不要再分享了，你觉得不错东西，自用就行了。不必做个傻逼程序员，动不动觉得自用可惜，迫不及待分享。这里有 100 个理由恶意揣测你动机，你连呼吸都是错。
2.Base64 是一好东西，然实践过程中易得，标准 Base64 在 URL 场景下存在不可预期问题，故业界萌生 Base64 改良版 Base64.UrlEncoder 作为最佳实践。
同理，响应式编程、MVI 属理想化模型，在实践过程中易得，标准 MVI 在 Java 命令式编程 Android View 页面开发场景下存在不可预期问题，故萌生 MVI 改良版为最佳实践。
3.你说这么多没用，我就是要随便找个理由打压你 —— 你这改良版，和理想化实验环境理论模型有出入，你这设计违背理想化理论，故你就是水平臭，你就是对 MVI 理解有偏差，你活该被指责攻击。
4.你不该对 “最佳实践” 感兴趣，更不该公开分享，你公开分享，就是在挑衅别人大师光环，你都 “最佳” 了，别人怎么办？
5.别指望别人去查百科了解 “最佳实践” 含义 —— 最佳实践（ best practice ）是一管理学概念，“认为存在某种技术、方法、过程、活动或机制可使生产或管理实践结果达到最优，并减少出错可能性”。
6.如不想因为 “最佳实践” 被杠，你最好别取《 MVI 最佳实践》这样标题，最好是《在 MVI 基础上，根据广泛实践，形成某种改良版，以使生产或管理实践结果达到最优，并减少不可预期错误》。
7.不过，就算你标题有 45 字这么长也不行，欲加你罪，何患无辞。就是妒忌你，总有理由三人成虎泼你脏水。你越认真，越有理由黑你。
8.你以后不要再分享了，你觉得不错东西，自用就行了。不必做个傻逼程序员，动不动觉得自用可惜，迫不及待分享。这里有 100 个理由恶意揣测你动机，你连呼吸都是错。
 |
1
fromzero 2022-07-05 11:00:49 +08:00  10
又来发明新名词了，前端用烂的单向数据流。不说了，赶紧出付费教程，我第一个当韭菜
|
|
2
fromzero 2022-07-05 11:03:09 +08:00 3
想学习 mvi 的同学大可直接去看 aribnb 的 https://github.com/airbnb/mavericks ，基于 jetpack flow ，里面的代码质量细细研读会有很多收获
|
 |
3
KunMinX OP 根据你的阴阳怪气，很难让人不无语。就踩吧，黑吧，毁灭吧 ~
|
 |
4
xwdz9989 2022-07-05 14:51:35 +08:00
营销鬼才
|
 |
5
yaocai321 2022-07-06 10:46:50 +08:00 4
每次来 Android 节点发推广没人鸟你，心里没点数？
矫揉造作，直接去当 stormzhang 门徒得了，也好早日财务自由~ |
|
8
KunMinX OP 演的还挺像。1 、2 、3 、4 、5 ，人差不多也齐了，来个大家整个 “三人成虎”。
|
|
9
fromzero 2022-07-09 23:24:49 +08:00
@KunMinX 今天闲来无事，先来分析你的代码吧。 首先，mvi 的关键核心是状态机，不可变的状态，以及单向的数据流向，这也是现代声明式 ui 的思想，故 mvi 和 compose flutter 以及 swift ui 是十分契合的。大神的最佳实践中的 Event 应该就是 state 了，页面通过 out 订阅 state 的变化更新 ui ，这个没问题，但是不可变呢？你为什么直接更改 event 里的值啊？你这里也没有 reducer 的体现啊？ 另外 side effect 的情况本最佳实践怎么处理呢？
|
|
10
fromzero 2022-07-10 20:02:01 +08:00
@fromzero 不可变这里我看错了一丢丢，爱坤大神这里的 event 应该是代表每个 intent 产生的事件，但是数据什么的都包在 event 里面，然后再把 event 的数据赋值给 state 刷新，这里 state 的赋值也违法了不可变，那这里也很奇怪，我干嘛不直接拿 event 的数据刷新呢，out 监听的为什么是 event 不是 state ，那不是变成了 事件驱动 ui 而不是状态驱动 ui ？ 
|
|
11
fromzero 2022-07-10 20:43:08 +08:00 2
总结（仅仅是本菜鸡的个人观点）：
整体架构看起来没啥问题，用户触发事件，请求数据，ui 监听事件改状态刷新 ui ，完美的单向数据流👍🏻。but * 违反不可变，比如我在监听处偷偷修改 event 里面的值，直接破坏其他监听者的逻辑 * 没有状态机，只有一个 Event 事件队列机来发事件，通过监听 event 的数据，然后扔给给状态，而且状态这个变量 mStates 是由 ui 自己维护的（我自己维护我自己的状态？不应该是监听状态吗？） |
|
12
fromzero 2022-07-10 21:02:11 +08:00
@KunMinX 说实话分析完我是吓一跳的，我原本还是挺认可你的技术的，虽说喜欢造新名词，但是之前的技术文章多少有几篇还不错的，我今天去看了一下你的重学 android 已经涨到￥ 379 了，静下心多打磨点干货吧。
|
 |
13
GetCore 2022-08-14 01:01:07 +08:00
|
|
14
KunMinX OP 统一回复：
MVI 是实现单向数据流的一种方式，本质上是一种 IO 闭环，也即只要遵循函数式编程特性：唯一入口 + 唯一出口 + 无副作用，就可视作是 MVI 。 reduce 仅仅只是权宜之计，或者说主流解决方案，目的是在当下计算设备性能有限情况下，对状态集做的统一优化。实现 MVI 方式千千万，我个人认为 reduce 不能算是 MVI 本质。 至于 sample 案例中为什么没有为 “Intent” 字段添加 final ，那是因为 Java 下想要实现 Koltin val 同等效果，样板代码瞬间会飙出许多。val 是为了消除 数据一致性问题，而 java final 滋生的样板代码反而在日后容易滋生更多 “一致性问题”， 这几天腾出手开始解决这个问题，刚刚提交了可用于 Java 8 的 sealed class ，专门优化这问题。 最后，任何技术都存在演变的过程，没有什么一出生就是完美无缺，我希望一切都能实事求是交流，而不是高高在上的姿态嘲讽打击。 和所有我开源过的项目一样，MVI-Dispatcher 也是一个长期项目，我们希望打磨一个极低学习成本，在多数场景下都能稳定运作的框架。 |
|
15
KunMinX OP 也不能说是优化，应该说是一种细化和规范，提醒人们 newState 务必基于 oldState copy 而来，如果不是特别必要，比如如果业务细化程度不足以裂变出 partialChange ，那么在 MVP （最小可交付产品）设计中可以没有 reducer 。
目前觉得有必要引入 reducer 的场景在于事故高发地段，需要捕捉 state 变化的路径，乃至手动配置个 reducer 来管理 states 列表。 |
Select Language