这是一个创建于 61 天前的主题，其中的信息可能已经有所发展或是发生改变。
虽然个人很喜欢用 Flutter ，但是统应用用 Flutter 来写有些画蛇添足了，难道 Xiaomi 也要再重新造个 OS 好方便到时候移植？
 | 1 javalaw2010 2 月 4 日 小米这么大的出货量应该干不出来完全抛弃安卓的事儿，我觉得有可能是新的产品形态。 |
 | 2 ynxh 2 月 4 日  2 xiaomi 确实有自研 os 在搞着了。预计有一款产品，自研 os + 自研芯片 + 自研大模型的会师。 Flutter 我是觉得挺好的... |
 | 3 x86 2 月 4 日 2 玩不明白的话用啥写都白搭 |
 | 4 albatron 2 月 4 日 我的小米 14T 到现在还没收到 hyperos3 的更新推送，怎么就开始说 hyperos4 的事情了 |
 | 5 tanszhe 2 月 4 日 4 Flutter 的性能肯定是小于原生性能的。 开发的包变大，性能变卡 优势就是快 夸平台。小米这是要缩减成本吧 |
 | 6 VinsonGuo OP 2 月 4 日 1 @ynxh 系统应用需要调用大量的原生 api ，用 flutter 就得写无数个 method channel ，而且性能还是和原生有差距的。hyperos 本身现在风评就很差，被其他家吊打，就怕再用上 flutter 步子迈太大... |
 | 7 zsk425 2 月 4 日 除非真的要搞自研 OS ，否则想不出为什么要用 Flutter ，保持观望 |
 | 8 96 2 月 4 日 不如也整个大网页，大家都是 JS ，一起让前端再次伟大 |
 | 9 1343EFF 2 月 4 日 严重怀疑他的车机 APP 大多数用的 flutter 渲染，准备统一车机和手机的技术栈了 |
 | 10 xFrye 2 月 4 日 应该是下一代 os 的 UI 层将会基于 flutter ，可预见未来后续国内其他的 os 会往这个方向发展？至于是不是选 flutter 就不好说了 |
 | 11 debuggerx 2 月 4 日 3 @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 2 月 4 日 系统应用用 flutter 重写，无障碍不要了吗？信源有问题吧 |
 | 13 4seasons 2 月 4 日 小米这股价跌成这样，果然是有原因的 |
 | 14 david1025 2 月 4 日 最应该重写的应该是操作系统，你重写几个系统应用就算是流畅了，对应用户来说感知不是很明显，第三方 app 该卡顿掉帧还是卡顿掉帧 |
 | 17 NyxJinx 2 月 4 日 flutter ffi +rust 挺好的 |
 | 18 fuwu1245 2 月 4 日 0 遗留 有没有可能引入新 Bug |
 | 19 darkengine 2 月 4 日 @david1025 这些手机厂可没这个魄力重写操作系统。 |
 | 20 hronro 2 月 4 日 via Android 安卓上不清楚，iOS 上 Flutter 的应用明显不如原生的应用流畅。如果同一套 Flutter 的代码在安卓上比安卓原生的流畅，那真有点 iOS 的下限吊打安卓的上限的感觉了。 |
 | 22 nethcx 2 月 4 日 flutter 总感觉有种不跟手的感觉 |
 | 23 liyafe1997 2 月 4 日 @debuggerx 是这样的，就跟你在 Windows 下用 GDI 甚至 WinForm/通用控件手搓各种特效，性能肯定比不上极端一点比如直接上 DirectX ，上 Unity3D 里面显示 3D 动画。但是这种会有一个 runtime 开销，以及最重要的冷启动开销。 别说 Unity3D ，你就算用 WPF 拖几个简单的控件，冷启动时间以及资源占用肯定比 WinForm/MFC 这种直接用 Win 通用控件差很多。看看 Win11 的一堆系统组件用 XAML island 就是这个鸟样子，为什么 Win11 总有一种拖泥带水粘滞感。 说白了就是，确实动画/性能更好，但是可能冷启动 App 时加载时间更长，占内存更多 |
 | 24 Loku 2 月 4 日 |
 | 25 w568w 2 月 4 日 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 2 月 4 日 @liyafe1997 冷启动时长这点我赞成你的说法，但实际来说没 unity 那种那么夸张，不负责任大致估计的话，如果原生冷启动只要十几几十毫秒，flutter 则可能需要 200ms 甚至更多。 但有意思的点是，现在的 os 都会为了视觉和体感的流畅加入启动动画，这个时间在一定程度上缩小了差距，另外系统应用一般功能单一，不会在启动时加入全屏启动页并初始化一大堆东西，所以相比于其他商业应用，启动性能也是会好很多的。 |
| 28 VinsonGuo OP @ybz 我说的原生不是 native c/cpp, 而是 android API 。试想一下开发一个 settings app ，里面各种蓝牙、wifi 、display 选项都要调用到 android api 来获取，需要把相关的 android api 包一层，想想维护起来都痛苦 |
 | 29 Gilfoyle26 2 月 4 日 5 这帮员工为了 KPI 真的是脸都不要了，就欺负雷子好久不搞技术了，在那里瞎玩。迟早要给雷子这点江山玩没了。  |
| 31 ybz PRO 2 |
 | 32 renmu 2 月 4 日 via Android 1 我觉得这点性能差距远比十几年屎山好得多 |
 | 33 wuruxu 2 月 4 日 已经不买小米好几年了，看来还要继续 |
 | 34 thtznet 2 月 4 日 9 简单理解：以前 N 个前辈留的屎上代码不想维护了，有这打补丁的时间不如推翻重来，那么重来就是我会什么，选什么，压根没那么多什么深入的性能考虑，都是想太多，哪行哪业都是草台班子凑出来的，别把人想得太复杂。 |
 | 35 zoharSoul 2 月 4 日 看见了 支持 |
 | 36 est 2 月 4 日 flutter 的典型应用就是咸鱼 垃圾得一批。 |
 | 37 aalivexy 2 月 4 日 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 2 月 4 日 1 @aalivexy Impeller 的性能优于 Skia ，增加了预编译着色器和 Vulkan / Metal 支持。我从 Flutter 1.22 开始使用，当时还是 Skia ，并没有感觉到和原生有显著的渲染性能差距（当然，当时 60fps / 120fps 的差距还是有的）。 把我原来回复中的 Skia 替换成 Impeller ，也不改变结论，反而更说明 Flutter 的渲染性能应当是和原生相当的。 |
 | 40 WebKit 2 月 4 日 不能吧？小米用 flutter 的有什么优势吗？难道新系统不是基于 android 的？？如果不是基于 android 的，然后支持 flutter 那我觉得挺好的，至少比华为鸿蒙那个强 |
 | 41 lysShub 2 月 4 日 小米不用跨平台，flutter 的唯一优势没了，说不定体验还不如 web 呢 |
 | 42 ysy950803 2 月 5 日 不太懂，又不跨端，用 Flutter 干什么？ Kotlin 写 Compose 不香吗？ |
 | 43 IvanLi127 2 月 5 日 除非小米要抛弃 android ，否则就是疯了.... 那能决策成这样，过于离谱 |
 | 44 kenis 2 月 5 日 不太明白什要用 Flutter ，是需要配多端？ |
 | 45 callmesmc 2 月 5 日 Flutter 真的还不如 web 呢 |
 | 47 yuPD97Yeed4QM245 2 月 5 日 via iPhone 我不信 |
 | 48 Avedge 2 月 5 日 大的要来了？ |
 | 49 xiaobd 2 月 5 日 via Android |
 | 50 cvooc 2 月 5 日 我感觉更像是给跨端做准备, 未来估计会出双系统? |
 | 51 marsKnight 2 月 5 日 呵呵 大学推荐我买小米的同学已经不用小米了 |
 | 53 92Developer 2 月 5 日 报道的就有问题，做准备呢，就称为[史上最稳定]，搞笑嘛这不是。在我这，粗粮和 360 一个 B 味儿，此生不用，见一次黑一次。 |
 | 54 crackidz 2 月 5 日 咋的，这是要学鸿蒙搞自己的 OS ？老老实实搞套壳不好么 |
 | 55 xiaoke 2 月 5 日 还没出来就敢说“史上最稳定”？ |
 | 56 PlG5sBkXD1ziLeGB 2 月 5 日  12  听说你还在搞什么原创，搞来搞去好像也就这样 |
 | 57 kapaseker 2 月 5 日 这听起来。。。好不小米啊！ |
 | 59 duanxianze 2 月 5 日 用什么都无所谓，能把十几年的屎山代码重构一下就肯定好的多了 |
| 62 duanxianze 2 月 5 日 @lysShub 小米肯定跨平台啊，人（手机）车，家 |
 | 63 jmliang 2 月 5 日 小米汽车这个 App 就是 flutter 写的 |
 | 64 AoEiuV020JP 2 月 5 日 我是看好的， 就算说是系统 app ，但也不可能真用 flutter 开发什么被其他 app 依赖的系统组件，flutter 只是写 ui 的，无非是一些内置应用的 ui 使用 flutter ，哪怕是设置 app ，你不打开它用什么 ui 框架都不占用资源，而这些 app 正是 flutter 最擅长的场景， |
 | 65 mscsky 2 月 5 日 说的是 ui 层？ |
 | 66 THESDZ 2 月 5 日 不知道小米有没有什么前期的调研以及小范围的实验。 就怕他们觉得一般人不懂 flutter 这些的区别，然后炒一波情绪，卖一波股价，留一地鸡毛。 |
 | 67 whevether 2 月 5 日 @PlG5sBkXD1ziLeGB 这很小米。企业文化就是这样。每次都是各种突破。各种提升。搞得好像很黑科技。 |
 | 68 MozzieW 2 月 5 日 @duanxianze #62 跨平台，不是跨设备。手机、车机、电视都是 Android 一个平台 |
 | 69 NGXDLK 2 月 5 日 手上有一部红米 K60 至尊，感觉系统流畅性很拉胯 |
 | 70 justtokankan 2 月 5 日 但是 Flutter 谷歌的维护团队人员较少了很多，而且 KMP 以后会更加成熟吧 |
 | 71 tangqiu0205 2 月 5 日 Flutter 那不更卡了吗 |
 | 72 Actrace 2 月 5 日 flutter 做 UI 确实还行，但是如果涉及到对接系统 API ，可能不是那么舒服。 |
 | 73 FireKey 2 月 5 日 用 flutter 用来给自研 OS 积累 app 数量,估计是想出个抛弃 Android 的版本. |
 | 74 so898 2 月 5 日 小米搞这个若是为了自己的系统做准备那是要吃大亏的，鸿蒙 flutter 版都做了多久了，社区说不合并就不合并，两边差异越来越大，搞的 flutter 在 iOS Android 上要编一套，去鸿蒙还要改一改再编一套，以后是不是还要针对小米改一改再编一套？ |
 | 75 404www 2 月 5 日 @PlG5sBkXD1ziLeGB 笑死我了 |
 | 78 woodfizky 2 月 5 日 有一说一，系统 app 要不了多少性能吧？不过卡不卡是一回事，耗电量提升就不好玩了。 |
 | 80 gogozs 2 月 5 日 就因为想用 flutter 抢占公司的生态位？ |
 | 81 beimenjun PRO 1 好像有点知道小米的策略了，一直用 Android 肯定是不行的，iOS 又不可能。但是又要避免做三星 Tizen 的小米版本，所以生态很重要。 于是高层和员工都把目光投向 Flutter ，到时候只要完成 Flutter 和新系统的对接，“理论上”，现有的 Flutter for Android 的 App ，只要重新编译一次，基本就能实现比较平滑的自研了。 但是如果“理论”不可行呢？那就按照小米的长期作风，“做失败了不说出去”，继续用 Android ，用 Flutter 写，至少可以减少 iOS 和 Android 的双端不少差异性，顺带带走一堆陈年代码导致的历史债务，反正小米的 App 我是真的没看出有啥是发挥出原生优势的。说不定一些 App 还能上架 iOS 。 这条路如果走通，也算是“性价比”自研系统的路径了，但是小米必须承担起 Flutter 大量社区开发工作才行，不然新的系统还是为了自研而自研了，在运行 App 方面没有独到的优势，必须做成一个为 Flutter 特别优化的系统才有卖点。 |
 | 82 wkend 2 月 5 日 小米还在偿还技术债务 |
 | 84 wowawesome 2 月 5 日 @PlG5sBkXD1ziLeGB #56 已经在唱了 |
 | 85 ProphetN 2 月 5 日 大厂切换技术栈，和新旧技术的优劣无关，单纯只是领导层的话语权之争罢了。 |
 | 86 unco020511 2 月 5 日 重写系统应用有啥用?除了 settings,相册,拍照 还有什么系统应用是天天要用的? |
 | 87 HK560 2 月 5 日 不是很懂安卓现在开发路线是咋样的，不用 flutter 的话，现在是要用 jetpack compose 写吗？问一下各位，打算业余学一下安卓开发来着 |
| 88 MozzieW 2 月 5 日 1 @so898 鸿蒙 Flutter 搞不好单纯就是自己垃圾，想用开源又不尊重开源，又菜又爱玩，自己把自己折腾死。 鸿蒙适配 Flutter 有两个主要工作： 1. 让 Flutter 主仓库支持鸿蒙系统 2. 第三方库适配 主仓库适配这个不说了，第三方库这个，把原来的第三方库 Fork 一下，就算没有合回主仓库也能接受，实际怎么做的？把一堆第三方库到处乱放，丢弃 Git 历史，有些干脆就直接放了几个版本的文件夹。导致使用的是鬼那么麻烦，还得一个个试。大部分项目本来适配一次后面就没有什么工作，直接可以和原仓库合并、更新，但是原仓库 Git 丢了导致不能继续维护。 这是培训班出来的吧 |
 | 89 penzi 2 月 5 日 小米完蛋了。能做出这种决策只能说明魔改安卓已经积重难返了，这个时候做出多离谱的技术决策可能在内部都能接受了 |
 | 90 youyouzi 2 月 5 日 原生不好吗？本来小米系统就被喷拉跨，想不通为什么上这种跨应用框架 |
| 91 MozzieW 2 月 5 日 这里说的是“系统 App”，重点应该是 App ，不是系统。 Android 的系统有好几层，代码主要是 C++、Java 。Java 使用都的地方主要是系统服务和 App ，Flutter 跨平台本来说的也是 App 这层，这里如果不是大动作，简单理解就是以后的 App 都用 Flutter 写的意思，和系统层没什么关系，Android 的、以前的 Apk 一样安装，跟鸿蒙那个根本就不是一回事。 比如 Android 的 App 启动页面，是要创建一个 Activity ，这个过程是需要和系统服务进行交互的，理论上可以使用 Dart 或 Rust 重写，但是我估计都不会动，而是继续使用 Java 的实现，而是把 UI 部分交给 Flutter ，和现在 Flutter 开发的非系统应用逻辑一样。这里说的“系统 App”，更多可能是天气、社区之类的，不可能是把系统的服务用 Flutter 重写了。简单的逻辑是：FLutter 是一个 UI 框架，使用的语言是 Dart 。系统服务，我指的是系统后台运行的不包括 UI 的服务，只能说是用 Rust 、Dart 重写。 这个过程中反馈给 Flutter 的话，对 Flutter 社区当然是利好。 |
 | 92 mathe 2 月 5 日 BEN 本来就尸屎山代码，再该就更屎山了 |
 | 93 xkeyC 2 月 5 日 1 @VinsonGuo os3.1 已经能拆包了，比如系统相册里面一个 dex 都没有，flutter 写 ui ，rust 直接调内部系统 api ，把 java 扔了 |
 | 94 BingoXuan 2 月 5 日 flutter 这是应用层面，真正核心的是系统图形栈。如果图形栈还是 Android 的话，本质上还是 Android 。能重写系统图形栈才是新的 OS |
 | 95 realpg PRO 不负责任的说啊 纯主观感受 flutter ui 很多时候比 android 的 material 那个原生 ui 框架性能要好 |
 | 96 geekvcn 2 月 5 日 via Android 小米一个连更新 linux 内核大版本能力都没的，万年安卓 4.4.4 现在才好点但安卓更新还是不如右商的，谈自研系统，营销字研吧。 目前全世界手机内核和 OS 系统 GPU 和各种驱动都更新的只有苹果，谷歌，华为。高通 SDK GPU 驱动支持稍微好点，联发科基本出厂 SDK 是啥就是啥除了基带全靠 ARM 授权。 不提代工会不会被掐脖子，默认不会，小米自研前先芯片自主程度超过联发科吧联发科好歹基带自研。小米 ARM 公版就算了，基带联发科的，苹果好歹 ARM 指令集+自研架构性能能耗无敌，基带也在开发 小米哪代系统不宣传底层重构，结果永远是屎上雕花，宣传永远是头部，其它永远是字研。 也不是单说小米，小米自主程度起码大过 OV ，后者公版芯片都憋不出来芯片团队就解散了。荣耀脱离华为也是喜欢拿供应商的技术字研。比如 ATL 的负极掺硅电芯，荣耀叫青海湖，小米叫金沙江…… |
| 97 geekvcn 2 月 5 日 via Android 小米先符合谷歌安卓的推荐吧，先把 OPENGL ES 全局切换到 vulkan ，旧机型内核和安卓版本更新先追上友商，追上后 Linux 内核和 GPU 驱动更新追上谷歌。别鼓捣自己自研芯片了，把展锐收了起码有基带用，同样 ARM 公版估计还更省钱 |
 | 98 vibbow 2 月 5 日 小米不关 MIUI 优化，连 split apk 都不能装 |
 | 99 PhpBB 2 月 5 日 海外版 ROM 呢? |
 | 100 leokun 2 月 5 日 听起来不是很靠谱 |
Select Language