reactna1ve

我是找了几个朋友在小区楼下摆了一个求婚的场景，然后戒指是 tb 买的莫桑石几百块😂我媳妇儿倒也不介意这个

不知道最近刚发布出来的存在传感器能不能感应到猫...能的话可以用这个来搞

祝福

可以，mix2s 已经装了。屏幕太小其实没啥用

MVVM MVI 只是更多是协议式范式，我见过有把 MVVM 写成 MVP 的。我理解 MVI 更多是一种函数式编程思想的演进，即保证当前 ui 和定义的有限状态机是幂等的。但是实际工程中碰到的问题会有：
1 、uistate 粒度区分，粒度细了状态数量爆炸，粒度粗了没意义
2 、由于中间隔了一层 dispatcher ，导致问题追溯的路径不是连贯的
3 、ping-pong 问题。比如在某个场景下会触发多个 View 的修改，同时修改的状态依赖上一个 View 的状态以及当前逻辑，MVI 下这个通信逻辑会非常绕。Logic 和 View 之间来回横跳
4 、性能问题，这个上面你也说了，我们这没用 composer 很大一部分原因就是这个
5 、无论是 rx 还是 livedata ，intent 不会区分事件和状态。这俩的区别是事件会 consume （ like toast 或者 click ），但是状态是保持的，需要自己去区分

所以这玩意并不是唯一的解决方案，更多是一种思路。具体的架构模式得参考自己的工程环境

我个人理解是：
无论前后端，首先是一名工程师，工程师本身是去解决问题的，语言本质上只是工具之一。然后回到前端方向上，首先要去看公司这个方向上现在存在的问题：
- 是业务不行？需要不断试错验证新业务的可行性，那么对于工程师来说，如何在现有基础上快速迭代是首先要解决的技术问题
- 业务到瓶颈了？那看前端方向上的瓶颈是什么？交互体验太差？交互体验差是因为逻辑 bug 多还是性能不行

就算工作是疯狂去抄其他产品的实现，作为工程师去执行的时候起码也要去思考为什么老板要抄这家？老板就算不思考这点只是去抄，那起码其他产品的团队怎么做的决策要推动这样的方案上线，对于大的产品不可能说没经过市场认证就直接推广的，所以市场起码认可这样的方案。从中可以尝试去理解市场，这样增强自己对于产品甚至整个行业的判断力。

其他还有很多细节楼上也有人说了，比如交互的细节，实现方案中可能存在的各种问题，比如现在对于隐私合规和无障碍越来越重视的环境下，产品不了解这些东西，研发可以积极提出来而不是简单的实现，这样也是对于业务的一种理解。

我理解这些会是一个工作多年工程师和一个新人工程师的差距，至于编码上的其实反而差距没那么大

@exploreexe 你在 flutter 的 contributors 里面能找到他，刚看了眼，相关文档已经一年没更新了。

@exploreexe 头条、腾讯内部其实也都在加强 flutter 的使用
-----------------------------------------------------------------------------
别逗了，字节花大力招进来的 flutter 步道师 去年就跑路了。现在主业务基本没用这玩意的

盖楼