@evilHa 多关注各种人才流动消息就会注意到了，最近几年，但凡聪明点的、有点能力的，很多都在逃离华子这艘船了……

根据百度百科的记录，「同年 9 月，检方以损害商品声誉罪提起公诉。」——建议问下 AI 这个“检方提起公诉”是啥意思。
虽然我的态度也是你法我笑，但这个事情里，牢翔凭啥敢嘴硬不认罪，是不是有靠山呢？

@shench 没说反，未来底层人类需要给 AI 和机器人腾出空间和能源。就算科技发展解决了空间和能源问题，真人创造价值的效率不如 AI ，还有什么存在的必要性？

猜测全球人口数量可能会以数量级锐减，才能达到新的平衡态。

@a33291 有个 fvp ，国人作者直接基于 ffmpeg 开发的，除了 Linux 可能还有点问题，其他平台基本都可以

@Oilybear 个人体验：
即使是单一平台的 APP ，不管是古法编程还是 AI 辅助还是纯 agent 项目，用 flutter 的效率和效果都不比原生差。这里的原因我认为主要是两点：
1. flutter 相比原生的社区生态是降维打击，很多功能都有写好的库，而且很多积极维护的库不仅处理了跨平台兼容性问题，甚至平台本身的兼容性问题和 bug 都处理了，开发体验和稳定性比原生还好。
2. 不管是安卓还是 iOS 其实总的来说都还处于稳定成熟的传统原生（ OC 、xml ）向现代但不够成熟的方案（ compose 、swiftui ）转变的过程中，相比之下对于 AI 来说，flutter 是考虑到稳定性、确定性、丰富度更优的方案。

如果考虑到多平台，而且需要长期维护迭代，而不是一锤子买卖的项目，跨端方案比多端原生的优势更是巨大。这不是简单的两个平台只需要多一倍 token 这么简单的问题，下面是 gemini 的分析：

1. 软件工程的终极噩梦：状态与逻辑同步
无论 AI 多么聪明，如果在原生端分别实现，你依然会有两套完全独立的业务逻辑代码。
假设你需要修改一个电商 App 的“购物车结算逻辑”。 原生方案下，你需要分别 prompt （提示） AI 去修改 iOS 的 Swift 代码和 Android 的 Kotlin 代码。由于原生系统的生命周期、状态管理模式（如 iOS 的 SwiftUI/Combine 对应 Android 的 Compose/Flow ）不同，AI 生成的代码结构会截然不同。
这就导致了：
a. Bug 的不对称性：双端可能出现完全不同的 Bug 。iOS 可能因为闭包循环引用导致内存泄漏，Android 可能因为协程未取消导致崩溃。
b. 需求对齐极难：随着业务迭代，两套代码会逐渐“漂移”（ Drift ），最终导致同一个功能在两端的表现不一致。
c. 跨端方案的优势：使用跨端逻辑意味着业务核心代码只有一份。修一个 Bug ，双端自动生效，这不仅是写得快，更是错得少。
补充一下，哪怕只是最简单的业务逻辑，你让 AI 分别用 java/kotlin 和 OC/swift 去写两遍，其实都不一定能保证它们在各种 case 下的表现能“完全一致”，但如果核心业务逻辑是完全共享的，不管是用 dart 、js 、c 还是 rust ，就很难会出现不一致的问题导致的 bug 。

2. 代码生命周期中的“维护成本”公式
在软件工程中，代码的创建成本在整个生命周期中只占极小部分。代码写出来是一次性的，但阅读、重构、排查 Bug 需要持续投入。维持双端甚至多端一致性的沟通和校验成本比 AI 的创建成本要高得多。
你是愿意让人类开发者（哪怕借助 AI ）去 Review （审查）一份跨端代码的 Pull Request ，还是同时去 Review 两份基于不同语言、不同架构的 PR ？代码量翻倍，意味着人类审查的认知负荷（ Cognitive Load ）翻倍。AI 可以生成代码，但最终为线上 Bug 负责的依然是人类。


3. 多端生态不仅是 iOS 和 Android
现代跨端框架（如 Uni-app, Taro, React Native Web ）解决的不仅仅是手机 App 的问题。
现在的企业往往需要：iOS App 、Android App 、微信小程序、支付宝小程序、H5 移动端网页、甚至桌面客户端。 如果你让 AI 去写原生代码，你需要让 AI 分别写：1. Swift (iOS) 2. Kotlin (Android) 3. WXML/WXSS/JS (微信小程序) 4. GTK\Qt\Win32
即使 AI 能写，部署、测试、发版需要经过 4 个完全不同的流水线。而使用跨端框架，一套代码编译到多端，配合 AI 辅助编写这套“统一代码”，这才是真正的效率乘数效应。

@lingz004 舍得花钱就找个设计师，或者找个靠谱的能生图的 AI 出几张图也行，然后还原设计稿呗，专业的事交给专业的人或工具。
肯下工夫就多看看成熟优秀的设计指南，参考精致的设计案例，但是有些人天生审美细胞不发达，比如我，自己做的小工具基本就靠抄 deepin 的设计，不然搞出来的东西自己都嫌弃……

比如：
https://www.debuggerx.com/2023/07/18/remote-system-monitor
https://github.com/debuggerx01/weekly_todo

Flutter +3
公司项目从移动端到 pc 端到上位机，全是一套 flutter 项目搞定的

首先排除 h w 云

AirReceiverLite ，某些自制 TV 系统会带，可以找找学习版。

@killertom 都烂，但是能烂到没法用的，华子那是独一份儿

公司开发电脑用 deepin v23 两年了，准备年后回来趁需求空档期换成 deepin v25

@liyafe1997 冷启动时长这点我赞成你的说法，但实际来说没 unity 那种那么夸张，不负责任大致估计的话，如果原生冷启动只要十几几十毫秒，flutter 则可能需要 200ms 甚至更多。
但有意思的点是，现在的 os 都会为了视觉和体感的流畅加入启动动画，这个时间在一定程度上缩小了差距，另外系统应用一般功能单一，不会在启动时加入全屏启动页并初始化一大堆东西，所以相比于其他商业应用，启动性能也是会好很多的。

@tanszhe 一个反很多人直觉的情况是，在复杂布局和大量动画特效的场景下，flutter 的性能表现要略优于 compose ，远强于原生传统 view 布局。这对于对特效、动画、流畅度要求越来越高的系统应用来说是非常合适的。

gemeni 的解释如下：


原生 Android (Classic View System)

布局性能： 最差（在复杂场景下）。
传统 View 系统（尤其是 RelativeLayout 和带权重的 LinearLayout ）存在“二次测量 (Double Taxation)”问题。父 View 可能需要多次测量子 View 才能确定位置。当布局嵌套很深时，测量时间呈指数级增长，极易导致掉帧。
虽然 ConstraintLayout 解决了嵌套问题，但其底层的约束求解器（ Cassowary 算法）在极度复杂的动态界面中仍有计算开销。
动画性能： 高上限，但难优化。
如果使用 RenderNode 或直接在 SurfaceView / TextureView 的 Canvas 上绘制，性能是极高的（接近底层图形 API ）。
但常规的 ObjectAnimator 或 ViewPropertyAnimator 在触发 layout 过程时（如改变 View 大小），会引起整个 View 树的重绘，开销巨大。


Flutter

布局性能： 极佳。
Flutter 使用单次遍历 (Single-pass) 布局算法。父节点传递约束，子节点返回大小，时间复杂度为 O(N)。无论布局多深，性能损耗也是线性的。
自带渲染引擎 (Skia/Impeller)：Flutter 不依赖 OEM 组件，直接通过 GPU 绘制。在处理大量 UI 元素时，它更像是一个游戏引擎，表现非常稳定。
动画性能： 最稳定流畅。
动画核心与 UI 渲染紧密结合。对于大量粒子或复杂变换，Flutter 的重绘区域控制（ Repaint Boundary ）非常高效。
特别是在 Impeller 引擎（解决 Shader 编译卡顿）普及后，复杂动画的流畅度通常优于未深度优化的原生应用。


Jetpack Compose

布局性能： 优秀（优于传统 View ）。
Compose 强制执行单次测量规则（禁止子 View 被多次测量）。这在架构上解决了传统 View 的性能瓶颈。
它利用间隙缓冲区 (Gap Buffer) 和 智能重组 (Smart Recomposition)，仅重绘数据发生变化的部分。
注意： 如果代码写得不好（例如频繁触发重组而没有使用 derivedStateOf 或 remember ），性能会急剧下降。
动画性能： 良好，但在极高负载下略逊于 Flutter 。
Compose 的动画系统是声明式的，底层优化很好。
但在处理极大量并发动画（如全屏粒子）时，由于 Compose 仍运行在 JVM 上且需经过 Android 图形栈，相比 Flutter 直接对接 GPU ，由于对象创建（ GC 压力）和跨层调用，极限性能稍弱。

为受便秘困扰的小仙女们开发个“屙了么”吧💩

我就从来不纠结这个问题，因为十几年前就选了 Linux ，这么多年眼看 Linux 越来越好，那俩越来越拉，哪个是差哪个是更差都没啥影响

@superbai 高德小程序和 hm 的 sdk 更新也都是停在了 21 年，现在不也都正常用，实在不行逛逛 github 或者加群问问别人，常见的问题都有人踩过坑的；微信 sdk 一般是用 fluwx ，这个在 pub.dev 上搜搜就能看到，没事多在 pub.dev 上逛逛，就会发现这货的生态真不差