mac 机器还是挺好的，不过不值那个价，但是公司给配的不花钱，也就没什么问题了。
系统就是一坨，蹩脚的窗口管理和拖沓的动画时时刻刻让人不爽，老旧的系统组件和包管理的缺失让开发的体验远差于 Linux ，整天不是 CocoaPods 出错就是 SSL 出错，虽然解决也都不难，但纯纯就是 MacOS 的工程师在恶心人，很烦。
所以我选择装 Asahi Linux 来避免公司发的机器吃灰，只有需要在 macos 上编译打包的时候启动到 MacOS 系统，然后用 NoMachine 远程连进去用。

可能哪边的 wifi 驱动或设置不好吧。网线直连最快了，两遍手动设置 ip 为同一网段，就可以跑满网口速率。

@tyrantZhao 比例来说肯定是越来越高的，只是现在移动开发式微了，总量变少了，没有足够的市场机会给新的超级 APP 登场，所以感觉 flutter 用得没那么多。
两个冷知识：
1. 微信现在就在用 flutter ，新的小程序渲染引擎 skyline 也是基于 flutter 搞的
2. 所谓的鸿蒙原生开发，实际上也和 flutter“关系密切”： https://juejin.cn/post/7280006531922673719

@sniperboy0829 我开始玩的时候还是 beta 版本，还没正式发布。“ROI”这个东西对每个人的情况都不同，以我的情况来说，二本非科班出身的安卓开发，也没赶上移动开发最火的那几年，也没大厂经历，要不是当时比较早地选对了 flutter 作为主力方向，根本不会有后来做小 leader 的机会以及现在的薪资水平，所以对我来说“ROI”应该还是挺高的。

@everettstone 基本就是我上面说的那些了，然后再来一个建议就是多逛逛 pub.dev ，多尝试别人写好的插件，而不是自己写。我参与了几个商业项目，也包括涉及硬件和原生功能调用的，最终没有自己写一行原生或者 C 代码，全用的插件，完全没问题，反而总想着自己写原生可能最终会造成维护困难的结局。

@vczyh 应该说发展的还是挺好的，业内采用率越来越高，不光移动开发，很多桌面项目也开始用，我现在的公司就在用 Flutter 做同时兼容移动端(含平板)和三大桌面端的项目。
至于网上说卡的，我分几方面说：
1. 我做了好几个商业 flutter 项目，还没碰到过有什么用户反馈的性能问题最终发现是 flutter 本身的问题，基本都是出了 bug 或者同事的写法用法不好，只要写得没问题，flutter 本身的性能表现不会成为项目的瓶颈
2. 有些问题其实是通用的技能水平问题，比如图片视频资源压缩、比如数据量大的时候先采样再绘制、比如能复用的数据不复用，每一帧都重新计算，而且还是多层循环嵌套……这些东西其实是开发者水平的问题
3. 有些 app 我自己觉得流畅性没啥问题，可是别人就说感觉卡，掉帧，我只能说可能确实人与人体质不同，有人就是天生写轮眼吧
4. 针对上面这种，flutter 现在工作的重点就是把底层渲染引擎换成 Impeller ，ios 已经基本稳定了，预计 24 年内 android 也能差不多： https://juejin.cn/post/7337898389450080306

所以其实要我说，网上说 flutter 卡的，大多数其实是开发者水平问题，是代码写得不好，让 flutter 背了锅。现在市面上很多 app 都用了 flutter ，普通用户根本用不出来区别。用跨平台方案甚至直接 web 套壳的项目，只要代码写得好，很多也比低水平的原生项目流畅。

@debuggerx 对了，我写 Flutter 差不多 7 年了，个人和公司的项目都写了很多，也接手维护过几个项目，不同人(尤其是不同出身，比如安卓、ios 、前端、后端)写出的 flutter 项目的味道截然不同，很多原始技术栈的习惯在 flutter 这边很有可能并不适合，这也是我发现有些其他技术栈的老手转过来写的项目有时还没新手写的代码好维护的原因。上面那个 demo 项目是基于最新的 riverpod 写的(对面面试官的评价反馈是我这份代码是他们几个月来面试了几十人，最终交付质量最高的一份)，其实并不是很建议新手上来就用这么复杂的东西，还是从基础的无/有状态组件和 setState 写起来。

建议不要直接写项目，一定先耐着性子把官网文档读完，写一遍官方示例，最好把 dart 语言的最佳实践也通读几遍，否则写出来的代码不够 flutter/dart ，会影响后续的学习和维护的。

@zhuxc 虽然项目结构还是不错的，但是简单瞅了一下，就发现几个明显的点，比如异步函数的类型没声明对、一些 immutable 的类的构造函数没声明成 const 、一些冗余的操作和写法可以用 dart 里方便的语法大幅度简化、ListView 的子项应该用 map 函数来生成而不是手动循环填充 widgets 数组等等……

下面这个是我前段时间面试一家公司时做的面试题，前后大概花了两天，可以在线打开玩一玩，不建议学，但是可以看看里面一些写法，自认为还是比较符合 flutter/dart(最新)的语法和习惯的。
https://github.com/debuggerx01/flutter_ecommerce_demo

我上周也打了上海电信 10000 号，得到的说法是，现有机顶盒 iptv 不能直接转，得先交 16 块违约金，然后办理退还机顶盒退年费，办理软终端就是安装费 100 和 100 年费，也就是说现在想搞的话要花 116 块，等到现有 iptv 的一年套餐到期再换就是省那个 16 块……

用 flutter 的项目越来越多了

把服务器部署成 runner 你们提交任务上去 排队执行

盲猜两个最大的可能性:
1. 选错了学习资料，看了太多尤其是国内低水平的和过时的教程，导致走的弯路。直接看官网最新教程和示例学习，直接 next.js 上手最简单。
2. 被已有经验束缚，尤其原来是做原生开发的，转前端写 web 或者转 flutter ，经常出现这个情况，原生开发的那一套模式根深蒂固，各种新概念总想往原生上靠，于是就出现了很多资深原生开发写的类 web 代码甚至还不如学习了同样时间的新手。

坐标浦东，今天突然不能通过 ddns 访问了，穿透进去发现是 ip 变了，但路由上的 ddns 服务不知为何没修改成功，重启路由后好了。

@magic3584 所以我的经验就是，原生层越轻越好，数据和逻辑尽量全在 flutter 层去实现，这样维护难度、扩展性、bug 率和体验都会好非常多。
我就接手过一个项目，ble 连硬件设备的，硬件接口和数据库逻辑在原生的 sdk 依赖里，数据处理在原生层，flutter 调用要靠 method channel 和 stream 监听，flutter 拿到以后可能还要再包装一次成 json 数据给 webview 用，整个项目维护起来要死要活。
而我以前自己搞得一个类似的项目，就直接全部用 flutter 和纯 dart 实现，ble 蓝牙连接、状态维护和数据包解析全用 flutter_blue 做，数据库用 sqflite ，webview 直接用后端接口而不是用 jsbridge 从 app 拿数据，整体维护起来就非常清爽可控。

刷了 miui ，可以串流手机屏幕和应用，挺爽的。
目前主要用途是给小朋友用宝宝巴士。
不过显示和单喇叭的效果确实不太好。

@zy0829 单元测试肯定有意义，但是投入产出值不值得，更多的是取决于项目环境，其次才是开发水平，比如需求频繁变动的，快速迭代经常把刚上线没多久的功能直接砍掉的，pm 设计需求很少考虑复用的，这种项目追求单元测试覆盖真就没啥意义……
所以，不知道项目和团队的具体情况，没法直接下定论到底经理的想法对不对。当然如果这个经理就是纯粹凭个人喜好做的这些决定，那大概率是要出问题的

全栈开发，一个人把前后端都写了，自然也就不需要联调过程了。
当然对开发水平要求比较高，不是随便一个会写点前端的后端或者对后端一知半解的前端就能玩得转的。
有幸曾在一家外企创业团队待过，开发时一个人就负责一整个需求，需要什么就写什么，前端、后端、db 、mq 、cms 后台，信息模板……，需求涉及到的就一口气全做了，效率极高，问题很少，对团队和个人成长都有好处……

为什么需要这么低的延迟，是什么应用场景？

都是惯的，就该直接让用 dart 写脚本🐶