虽然个人很喜欢用 Flutter ，但是系统应用用 Flutter 来写有些画蛇添足了，难道 Xiaomi 也要再重新造个 OS 好方便到时候移植？
 | 1 javalaw2010 4 小时 42 分钟前 小米这么大的出货量应该干不出来完全抛弃安卓的事儿，我觉得有可能是新的产品形态。 |
 | 2 ynxh 4 小时 41 分钟前  1 xiaomi 确实有自研 os 在搞着了。预计有一款产品，自研 os + 自研芯片 + 自研大模型的会师。 Flutter 我是觉得挺好的... |
 | 3 x86 4 小时 37 分钟前 1 玩不明白的话用啥写都白搭 |
 | 4 albatron 4 小时 37 分钟前 我的小米 14T 到现在还没收到 hyperos3 的更新推送，怎么就开始说 hyperos4 的事情了 |
 | 5 tanszhe 4 小时 36 分钟前 2 Flutter 的性能肯定是小于原生性能的。 开发的包变大，性能变卡 优势就是快 夸平台。小米这是要缩减成本吧 |
 | 6 VinsonGuo OP @ynxh 系统应用需要调用大量的原生 api ，用 flutter 就得写无数个 method channel ，而且性能还是和原生有差距的。hyperos 本身现在风评就很差，被其他家吊打，就怕再用上 flutter 步子迈太大... |
 | 7 zsk425 4 小时 33 分钟前 除非真的要搞自研 OS ，否则想不出为什么要用 Flutter ，保持观望 |
 | 8 96 4 小时 30 分钟前 不如也整个大网页，大家都是 JS ，一起让前端再次伟大 |
 | 9 1343EFF 4 小时 28 分钟前 严重怀疑他的车机 APP 大多数用的 flutter 渲染，准备统一车机和手机的技术栈了 |
 | 10 xFrye 4 小时 22 分钟前 应该是下一代 os 的 UI 层将会基于 flutter ，可预见未来后续国内其他的 os 会往这个方向发展？至于是不是选 flutter 就不好说了 |
 | 11 debuggerx 4 小时 22 分钟前 @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 压力）和跨层调用，极限性能稍弱。 |
 | 12 mizuki9 4 小时 17 分钟前 系统应用用 flutter 重写，无障碍不要了吗？信源有问题吧 |
 | 13 4seasons 4 小时 16 分钟前 小米这股价跌成这样，果然是有原因的 |
 | 14 david1025 4 小时 13 分钟前 最应该重写的应该是操作系统，你重写几个系统应用就算是流畅了，对应用户来说感知不是很明显，第三方 app 该卡顿掉帧还是卡顿掉帧 |
 | 17 NyxJinx 4 小时 8 分钟前 flutter ffi +rust 挺好的 |
 | 18 fuwu1245 4 小时 4 分钟前 0 遗留 有没有可能引入新 Bug |
 | 19 darkengine 4 小时 3 分钟前 @david1025 这些手机厂可没这个魄力重写操作系统。 |
 | 20 hronro 3 小时 57 分钟前 via Android 安卓上不清楚，iOS 上 Flutter 的应用明显不如原生的应用流畅。如果同一套 Flutter 的代码在安卓上比安卓原生的流畅，那真有点 iOS 的下限吊打安卓的上限的感觉了。 |
 | 22 nethcx 3 小时 53 分钟前 flutter 总感觉有种不跟手的感觉 |
 | 23 liyafe1997 3 小时 48 分钟前 @debuggerx 是这样的，就跟你在 Windows 下用 GDI 甚至 WinForm/通用控件手搓各种特效，性能肯定比不上极端一点比如直接上 DirectX ，上 Unity3D 里面显示 3D 动画。但是这种会有一个 runtime 开销，以及最重要的冷启动开销。 别说 Unity3D ，你就算用 WPF 拖几个简单的控件，冷启动时间以及资源占用肯定比 WinForm/MFC 这种直接用 Win 通用控件差很多。看看 Win11 的一堆系统组件用 XAML island 就是这个鸟样子，为什么 Win11 总有一种拖泥带水粘滞感。 说白了就是，确实动画/性能更好，但是可能冷启动 App 时加载时间更长，占内存更多 |
 | 24 Loku 3 小时 46 分钟前 |
 | 25 w568w 3 小时 46 分钟前 1 @tanszhe > Flutter 的性能肯定是小于原生性能的 为啥啊，Android 原生的图形渲染框架是 Skia [1]，Flutter 使用的图形渲染框架也是 Skia [2]。Android 原生的运行时是 ART ，Flutter 是 Dart Runtime [3]。 难道 Android 通过 Java -> C++ 调用的 Skia 比 Flutter 通过 Dart -> C++ 调用的 Skia 更高级吗 [1] https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/hwui/pipeline/skia/SkiaPipeline.cpp [2] https://docs.flutter.dev/resources/architectural-overview#flutters-rendering-model [3] https://dart.dev/overview#native-platform |
 | 26 ybz PRO @VinsonGuo #6 这个不是问题，flutter 调用原生已经在全面往 ffi 转了，前期的线程合并工作已经做完了，现在 flutter 运行在主线程，可以同步调用原生 api 了。 |
| 27 debuggerx 3 小时 36 分钟前 @liyafe1997 冷启动时长这点我赞成你的说法，但实际来说没 unity 那种那么夸张，不负责任大致估计的话，如果原生冷启动只要十几几十毫秒，flutter 则可能需要 200ms 甚至更多。 但有意思的点是，现在的 os 都会为了视觉和体感的流畅加入启动动画，这个时间在一定程度上缩小了差距，另外系统应用一般功能单一，不会在启动时加入全屏启动页并初始化一大堆东西，所以相比于其他商业应用，启动性能也是会好很多的。 |
| 28 VinsonGuo OP @ybz 我说的原生不是 native c/cpp, 而是 android API 。试想一下开发一个 settings app ，里面各种蓝牙、wifi 、display 选项都要调用到 android api 来获取，需要把相关的 android api 包一层，想想维护起来都痛苦 |
 | 29 Gilfoyle26 3 小时 32 分钟前 这帮员工为了 KPI 真的是脸都不要了，就欺负雷子好久不搞技术了，在那里瞎玩。迟早要给雷子这点江山玩没了。  |
| 31 ybz PRO 1 |
 | 32 renmu 2 小时 28 分钟前 via Android 我觉得这点性能差距远比十几年屎山好得多 |
 | 33 wuruxu 2 小时 4 分钟前 已经不买小米好几年了，看来还要继续 |
 | 34 thtznet 1 小时 39 分钟前 简单理解：以前 N 个前辈留的屎上代码不想维护了，有这打补丁的时间不如推翻重来，那么重来就是我会什么，选什么，压根没那么多什么深入的性能考虑，都是想太多，哪行哪业都是草台班子凑出来的，别把人想得太复杂。 |
 | 35 zoharSoul 1 小时 14 分钟前 看见了 支持 |
 | 36 est 54 分钟前 flutter 的典型应用就是咸鱼 垃圾得一批。 |
 | 37 aalivexy 11 分钟前 via Android @w568w 因为 Flutter 目前在 Android 上确实不是 Skia 。 > The Dart code that paints Flutter's visuals is compiled into native code, which uses Impeller for rendering. 在你引用的第二个链接里是这么写的。 可以参考： https://docs.flutter.dev/perf/impeller |
| 38 w568w 5 分钟前 @aalivexy Impeller 的性能优于 Skia ，增加了预编译着色器和 Vulkan / Metal 支持。我从 Flutter 1.22 开始使用，当时还是 Skia ，并没有感觉到和原生有显著的渲染性能差距（当然，当时 60fps / 120fps 的差距还是有的）。 把我原来回复中的 Skia 替换成 Impeller ，也不改变结论，反而更说明 Flutter 的渲染性能应当是和原生相当的。 |
Select Language