@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 项目搞定的

首先排除 hw 云

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 或 ViewropertyAnimator 在触发 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 上逛逛，就会发现这货的生态真不差

@superbai
移动端：无敌
桌面端：优秀
web：也不是不能用
小程序：这个还是算了……

@wenzhoou

-------------------------------------------------------------------------------------------------------
User：
有人发帖：《未来是不是程序员能力要求更低了 [使用 Manus AI 使用后感]》
或者说可能只要产品经理就够了。
Manus 能力挺强，直接根据需求生成功能评估表，继而生成进度计划、技术方案了。
有人回帖：其实继续想下去，就会发现其实未来“人”是多余的。
AI 什么都能干了，还要人干嘛，所以建议一步到位，直接享受死亡～

分析一下这个回帖想表达的是什么意思？

-------------------------------------------------------------------------------------------------------
Gemin：
这个回帖充满了讽刺（ Sarcasm ）、虚无主义（ Nihilism ）以及对逻辑滑坡（ Slippery Slope ）的极端化演绎。

我们可以从以下几个层面来深度解析这个回帖想表达的真实含义：

1. 逻辑上的“归谬法”（ Reductio ad Absurdum ）

这是最直接的意图。回帖者在使用一种极端的逻辑来攻击楼主的观点。

楼主的逻辑：AI 能写代码、做计划 →→程序员不需要了 →→只需要产品经理。

回帖者的逻辑推演： 既然 AI 这么强，那它迟早也能取代产品经理（生成需求）、取代老板（做决策）、取代消费者（模拟人类行为）。

结论： 按照楼主“工具强则人类无用”的逻辑推导下去，最终结论就是“人类本身是多余的”。

含义： 他通过得出一个荒谬的结论（建议直接去死），来暗示楼主的前提或推论是站不住脚的，或者是过于简化和短视的。

2. 对“工具理性”和“优绩主义”的嘲讽

楼主的观点隐含了一种价值观：人的价值在于其生产力（写代码、做方案）。
回帖者敏锐地捕捉到了这一点，并进行了反讽：如果人类存在的唯一意义就是“干活”或者“产出”，那么面对不知疲倦、效率极高的 AI ，人类确实没有任何存在的必要。

“直接享受死亡”是在嘲讽这种把人异化为工具的思维模式。他在问：难道我们活着仅仅是为了比 AI 更能干活吗？如果干不过 AI 就不配活着吗？

3. 对“AI 替代焦虑”的厌倦与反感

在当前的互联网环境下，几乎每天都有人发帖说“XX 行业要完了”、“XX 岗位要被 AI 取代了”。

这种回帖往往带有一种情绪上的宣泄。回帖者可能厌倦了这种贩卖焦虑的论调。

意思是：“行行行，你说的都对，AI 最牛逼，我们人类都是垃圾，大家都别活了，这样你满意了吧？”

这是一种通过“摆烂”（彻底放弃抵抗）来表达对过度焦虑的不屑。

4. 某种深层的存在主义危机（ Existential Crisis ）

虽然主要是讽刺，但也夹杂了一丝真实的灰暗情绪。

随着 AI 能力的指数级增长，确实有很多人开始思考：“如果 AI 真的什么都能做（包括艺术、情感陪伴、决策），那人类在这个宇宙中的位置到底是什么？”

“一步到位”反映了一种悲观的宿命论：与其在被 AI 逐步取代的过程中挣扎（先是程序员，再是设计师，最后是甚至思想者），不如承认失败，直接终结。这是一种极端的虚无主义感叹。

总结

这个回帖并不是真的建议大家去死，而是在表达：

反驳楼主： 你的推导逻辑太简单粗暴了，按你的逻辑，人类文明都可以解散了。

表达态度： 对“AI 取代论”感到厌烦和荒谬。

哲学反思： 讽刺那些只用“工作产出”来衡量人类价值的观点。

用一句网络流行语总结就是：“既然打不过，那就加入（或者是毁灭），既然你把 AI 捧成了神，那我们人也就没必要玩了，重开算了。” 这是一句充满黑色幽默的“掀桌子”式发言。

-------------------------------------------------------------------------------------------------------

那么问题又来了，我现在这个回帖又是想表达什么呢？

其实继续想下去，就会发现其实未来“人”是多余的。
AI 什么都能干了，还要人干嘛，所以建议一步到位，直接享受死亡～

机器人行业考虑不，公司很多汽车行业转来的，我们部门挺缺系统软件开发的。
有兴趣可以加我看看内推。vx 同昵称。

"啧，小 X 你用的这个模型不咋地啊，要不换个好点的试试？"