哈喽。我是老刘

老刘前段时间写了两篇关于Dart语言取消宏的文章：

• Dart的宏取消了期待3年的功能，说没就没了？
• Dart宏被砍掉的真相：为什么Go、Python、Java等高级语言都拒绝宏？

很多人评论说Rust的宏就是非常好用的。

这个观点老刘是非常同意的。所以今天想来畅想一下如果当初Flutter选择了Rust而非Dart作为其开发语言，现在的Flutter会不会更好？

我觉得大概率不会。不过，

• 若Flutter当初选用Rust而非Dart。发布态性能与稳定性可能略有提高，但开发体验、环境易用性、学习曲线等方面大概率会变差，整体效果未必比更好今天的Dart方案。
• Flutter的引擎层本就由C++和渲染引擎承担重活；Dart主要影响框架层与开发体验，不是决定性的性能瓶颈。收益有限、代价显著，不过，

二、原因分析

接下来我们从Flutter的5个方面来分析：

性能与内存管理

这两点是Rust相对于Dart的巨大优势。但是放到Flutter上面收益有多大呢？

性能问题

• 应用上架后使用者在乎的是首屏速度、滚动不卡、切换不顿。
• Dart和Rust在发布态都走AOT，最终都是原生机器码。
• UI框架层的纯CPU差距，还没有差距大到能感知的程度。
• 重活其实是交给C++引擎和GPU管线的，纯UI框架层的差距很难肉眼感知。
• 列表滚动锁到60fps，Rust不会神奇变成120fps。
• 真正决定体验的是布局复杂度、绘制策略、图片体积、网络延迟。
• 换成Rust收益有限。

内存问题

• Dart 的分代 GC 就是为短命对象而生。Widget、Element、RenderObject 来去如潮水。GC 一轮过去，垃圾就被带走了开发者几乎不需要操心。说起来，
• Rust 没有 GC。靠所有权、借用和 RAII 维持秩序。也正因为这个原因 UI 场景几乎是 Rust 所有权模型最拧巴的一块：
• 树形结构本身就有父子双向指针
• 业务代码里还要频繁跨节点共享状态
• 事件冒泡、回调、依赖注入…，到处都是共享引用 + 生命周期不确定

• 结果就是的观点是。 干净的 Ownership 模型被迫降级到 Arc / Arc + Weak 拆环，手动管理引用计数，把 Java 那套 GC 思维又搬回来。

• 好处也有的观点是。数据竞态更少，内存泄漏更难。

• 但这不是 Flutter 的主要痛点；老实说，相反代价和心智负担会更大。

包体积与启动速度

包体积的大头在引擎和资源，换语言不会动到这些。Rust 去掉 VM 能省一点运行时负担。但单态化可能让二进制变厚，总体差异不大。前面说的是大包成 App 后使用者使用上的差异，比如性能稳定性等；下面看看开发体验上的差异。

体验

热重载/热重启：

• Dart 可以做到保存后回到当前界面状态还在总时间 1-2 秒——依赖 Dart VM 和增量注入实现这种效果。Rust 没有跨网站通用 JIT/VM；如果想实现类似方案可能需要动态库热替换或加一层解释层，各网站一致性和工具链成熟度都有限。实际开发中的反馈节奏大概率会更慢。

编译与调试：

• Rust 的很多设计是为了性能和内存安全。所以这些特性更适用于偏底层的大型程序，例如宏或泛型单态化。泛型单态化导致同一个泛型在不同类型上会生成多份代码；UI 中泛型组件多且跨 crate 复用多。一改公共 trait 或泛型参数，就会触发大范围增量重编。例如你只是改了一个按钮通用组件，下游几十个模块代码都得重新生成。在没有成熟热更新程序情况下在 UI 开发中 Rust 的编译时间会比 Dart 长得多。从而降低迭代效率，也比基于 Java/Kotlin 的 Android 原生开发稍逊一步。

语言本身编写体验：

如果把学习门槛忽略不计，一个日常开发者若想把。

Dart 在移动端 UI 场景中做出了合理取舍——牺牲部分底层控制以换取快速迭代和高效团队协作。而 Rust 则把这一切留给程序员自己负责，对普通移动应用来说并非比较好的选择。

环境与插件