赞同楼主所述。语言皆为更少代码解决特定领域问题而生。

basic：dim a as string
c：string a

显然后者更简练。

语言是指令工具，故当计算机常识，如数据读写表示传输，备齐后，根据实际场景掌握相应语言即可。

可以诋毁，可以凭个人主观情感故意曲解，但不可以漠视。MVI-Dispatcher 系列分享到此为止，就让子弹飞一会。

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

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

如是视频，弄个外置 NAS 也行

如无 touchBar ，我愿入 13pro 8 10 24 512 ，否则不如加点钱上 14pro 10 14 32 1t

m2 air 一经推出，某宝店 m1 14pro 连夜涨价 1.5k 。市场数据最灵验

@pcatzj
根据你的审题，很难让人有效回应。上述主题谈的是 “技术本质” 对应 “单一职责原则”。框架设计时为保证逻辑内聚，顺带遵循依赖倒置、迪米特等。

@Bnfkbs
确实如此，挫折太多，信息残缺，易消磨意志。
找到好教程是一种方式，并且由于好教程通常可遇不可求，开源一项目并长期维护，亦是保持兴趣习惯，遭遇痛点场景，乃至提炼技术本质方式。
说白了，一切皆需要经历累积和时间沉淀。祝你好运。

建议再等一年。M3 + 新模具。
今年 pro13 就一清库存。

@b1iy 没错，我也是如此，每次要投送，只得重启。看来确实系统问题。

触摸板，
屏幕，无广告，
内存管理，流畅，
大部分时间静音，不发热，
续航，真移动办公

自从上周 google 在播客中提到 “flow 是否会取代 liveData”，之后各种关于 “LiveData 被下岗” 的人云亦云不绝于耳，

事实上，Flow 在处理 “表现层” 逻辑及 “页面间通信” 逻辑时的表现糟糕透顶，至少目前来看完全不足以胜任这方面的精细化定制需求，

flow 本来就是操作业务数据的工具，硬生生为其加入 state 等表现层的概念，试图通过 repeatOnLifecycle 等半生不熟的函数来取代 LiveData 在这方面的工作 …

个人预计 “将 flow 用于改变 UI 状态和页面间通信” 的设计，至少 1 年内都不足以演化为在线上环境使用。

经过我们的调研，70% 以上的公司仍在使用 java 开发或维护项目，而 java 项目又是 “null 安全一致性问题” 高发的场景，因而关于 Jetpack MVVM，我们专注且只分享 java 语言背景的案例，

kotlin 如今官方推广已有 4 年，有条件请及早上车 kotlin，以及尝试 compose 等框架。

我们对 LiveData 数据倒灌及其对策的探究始于 2019 年 7 月，历时两年，

在累积过足够多的场景样本，以及小伙伴们主动积极的测试、反馈、有效源码方案的分享，UnPeek-LiveData 得以不断演化，并完善至如今的模样，

再一次感谢小伙伴们实事求是的互动交流。

唯有其人亲历过，才会有体会，不然不会理解这样那样用的意义，你给他们说 1w 遍也无用。

你若真的想接触高手，唯有先自行把功课做好，做好功课才有机会感知哪里还需高手的临门一脚，不然也很难让人给你介绍

某些培训机构的课程动辄 5 、6000 元，且很少有备课，都是即兴发挥，每节课的长度基本在 120 分钟到 160 分钟不等，
可能原本 5 分钟就能交代明白的，愣是要花 2 个多小时都未必讲明白。

我个人从未报名过任何培训机构的课程，他们不能帮我节省时间，通常我更倾向于在自己做好功课的前提下，付费向特定领域的多位高手请教。

事实上，如真的想了解一个领域的内容，运行该领域热门的示例项目，阅读源码和花个把月爬坑、累积场景样本，这样就足以打好该领域的基础，对该领域的全貌有个初步的了解。