镀膜屏幕和镀膜眼镜片一样脆弱，不宜在 40 度以上环境使用，不宜用酒精擦拭，不宜接触碱性溶液，不宜粘附橡胶之类的材质，以免脱膜。

我通常是 mac 通过 Microsoft remote desktop 访问 windows ，这样可以直接延续 mac 的键位和鼠标滚动方向

m1 芯片 mac 可以玩原神。windows 建议台式机。

可以在设置中查看是否具备 “电池优化” 选项，如有，开启即可。
充到 80%，自动会走电源线路，不再走电池。24 小时插电也无事。

@Guaidaodl
也是，考虑线程安全。

@Guaidaodl

受你的启发，想到一个简便方式了。类似于把 copy 环节后置，也即开发者写代码时，像往常一样直接改字段，然后回推时给到 UI 的是重新 copy 的 uiStates ，也即可以给观察者套上一层 wrapper 来内部实现 copy 。

@reactna1ve 理解你意思了，2 包含异步顺序等问题。

@reactna1ve

没错，3 十分有体会，包括 editText 等自身能产生数据的控件情况。
5 的话，uiEvent 由于会改变 mvi-view 以外的环境（比如新增一个 window ，新增一个页面到返回栈），所以对纯函数而言又是副作用，需要某种方式解决，
2 没有理解，我的理解是，uiStates 和 actions 都聚合在 mvi-model 中，从发起 intent 到 action 为止，这期间可以记录本次操作路径，并且本次发起请求和回推结果，都可以记录

这几天讨论 MVI 的人有点多，我简单分享下自己的理解。

MVI 是响应式编程的产物。

响应式编程有个潜规则：一个控件只能在同一个粘性观察者（ BehaviorSubject ）中响应，

然而随着业务发展，开发者很容易误在多个粘性观察者中放置同一控件实例，即引发 “多个粘性观察者不符预期回推” 的隐患，

MVI 主要就是来解决这问题。通过将页面 uiStates 聚合在一处，控件只从这唯一观察者响应数据变化，从而确保环境重建时，回推的最后一次数据来源唯一，乃至符合预期。

由于控件集中响应，uiStates 字段不可变，加上每次根据 intent 执行业务，拿到的都是当前 action 当前 partialChange ，故唯有通过 copy 整合当前 partialChange 到上一次 uiStates ，来确保 uiStates 的延续，这个 copy 以延续的过程就叫 reduce ，

不过如果不是有专门的需求，我们无须特意写个 reducer 类来体现，而仅仅是 reduce 方法或直接 copy ，心意到了即可，

与此同时，UI 侧都是通过 diff 来判断本次某控件是否刷新。jetpack compose 无须开发者手动 diff ，其内部类似前端 DOM ，根据本次注入的声明树自行在内部差分合并渲染新的内容。当前我个人是用 DataBinding observableField 来做 diff 。

当然 MVI 也有其不便之处，由于它本来就是要通过聚合 uiStates 来规避上述不符预期问题，故 uiStates 很容易爆炸，特别是 UiStates 居多情况下，每次回推都要做数十个 diff ，在高实时变化的场景下，有一定的性能影响，

MVI 许多页面和业务都需手写定制，难通过自动生成代码等方式半自动开发，故我们我们不如退一步，反思下为什么要用响应式编程？

穷尽所有可能，我觉得最合理的解释是，响应式编程十分便于单元测试 —— 由于控件只在观察者中响应，那么有输入就必定有回响，

也是因为这原因，官方出于完备性考虑，以响应式编程作为架构示例。

现实中情况往往十分复杂。

android 当初为了站稳脚跟，选择复用已有的 java 生态和开发者，乃至使用 java 来作为官方语言，后来 java 越来越难支持现代化移动开发，故而转向 kotlin ，

用 kotlin 的开发者，更容易跟着官方文档走，一开始就是接受 flow 、reactive 的那一套，且 kotlin 的确抹平了语法复杂度，所以天然就是响应式编程的模式在开发，如此便有机会踩坑，并且有动力通过 MVI 的方式来改善响应式编程开发。

然而 10 个 android 7 个纯 java ，其中 6 个从不用 rxJava ，剩下一个还是偶尔用用 rxjava 的线程调度切换，

所以响应式编程在 java android 开发中的推行不太理想，领导甚至可能为了照顾多数同事，而要求撤回响应式编程代码，如此便很难有机会踩坑，更谈不上使用 MVI ，

也因此，实际开发中更多考虑的是，如何从根源上避免各种不可预期问题。对此从软件工程角度出发，我在设计模式原则中找到答案 —— 任何框架，只要遵循单一职责原则，就能有效避免各种不可预期问题，反之过度设计则易引发不可预期问题，

例如 BehaviorSubject ，实际上是一种过度设计，因为它的观察者是开放式，一旦开了这口子，后续便不可控，一个良好的设计是，不暴露不该暴露的口子，不给用户犯错的机会。一个正面的案例是 DataBinding observableField ，一个控件只能在 xml 中绑定一个，从根源上杜绝上述不符预期问题。

不过 DataBinding 也存在过度设计，例如开发者能拿到 binding 实例去直接调用控件实例，如此 observableField 数据绑定的努力前功尽弃。

目前想到的就是这些，有不同观点欢迎补充。

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

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

@haya

之前维护的 KeyValueX 是通过类反射方式，让巨型项目不用初始化编译即可直接套用接口。

SealedClass4Java 基于其场景，倒是很难这么做，不过权衡代码安全等角度问题，我个人可忽略这个问题。

@Kasumi20

消息分流，但又要确保数据一致性 ...

统一回复：

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

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

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

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

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

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

根据你的需求，可考虑通过系统 API 实现负一屏 widget ，好比现负一屏支付宝、微信扫码支付按钮 …

建议 b 站搜下极客湾测评。对三星台积电 CPU 有细说。

一般换手机多源于 CPU 问题，如性能跟不上、发热、续航 …

几个高中同学，大学毕业前讨论过这问题。

毕业 6 年后，其中一位在银行上班的同学，一次河边散步时提起这事，

他说，当年想不通你为何说 “工作不单单是为了挣钱”，后来职场上见过多年是是非非，理解了你说的，像工匠一样，一辈子就只专心做好一件事，也是幸事。

其实我并不记得当年我说了什么，只是特别反感为找工作而找工作，尤其反感 “工作只是为养家糊口” 说法，

我觉得工作的意义在于实现自我价值，借由这份工作发挥和完善自己的长处，

另工作的本质是通过劳动交换价值，故给资本家打工只是工作的一种。当个无产阶级光杆司令创业，也是工作，也值得尊重。

之前听过一个概念，叫 “长期公平”，

一名优秀的工程师在接到需求时，能第一时间预估和规避各种潜在的错误，此皆平日训练累积所得，终能复利。

项目是公司的，经验是自己的。

ipad 4:3 尺寸，看 1080p 教学视频很难有好体验，且读写传输电脑音视频文件不便