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

@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 你用的这个模型不咋地啊，要不换个好点的试试？"

「而且全部都是不备案，不联网，的个人单机应用。」
“人家”能上架，不代表人人能上架，这点伎俩都想不明白的话还是早点洗洗睡吧。

先试试 Deepin 25 ，万一合适就相当于超了近路了，觉得不合适再试试各种“老牌选择”不迟。

@V2023
@BennnnJi
把前 50 楼和后面的分开看，心里就该明白是肿么回事了