哈喽，我是老刘

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

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

很多人评论说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来拆解循环。

同时，还得手动去管理引用计数，这几乎是又把Ja va那一套GC思维给搬了回来。

好处也有：数据竞态更少，内存泄漏更难。

但这不是Flutter的主要痛点。

相反，代价和心智负担会更大。

包体积与启动速度（编译产物）

包体积的大头在引擎和资源，比如渲染引擎、字体、图片、音视频。

换语言不会动到这些。

Rust去掉VM能省一点运行时负担，但单态化可能让二进制变厚。

综合来看，差异不会太大。

前面说的主要是成App后，用户使用上的差异，比如性能、稳定性等。

接下来，我们再看看开发体验上的差异。

开发体验

热重载/热重启

假设只是改一个按钮文案，或者调整一个布局。

Dart可以做到保存后回到当前界面，状态还在，总时间1-2秒。

底层依靠的是 Dart VM 和增量注入。

Rust 没有跨平台通用的 JIT/VM。

如果想实现类似方案，可能需要动态库热替换，或额外加一层解释层。

各平台一致性和工具链成熟度都有限。

因此在实际开发中，反馈节奏大概率会更慢。

编译与调试

Rust语言的很多设计，是为了性能和内存安全服务的。

因此这些特性更适用于偏底层的大型系统，比如宏或者泛型泛型单态化。

泛型泛型单态化是指同一个泛型在不同类型上会生成多份代码，编译负担随之上升。

UI里泛型组件多、跨crate复用多，一改公共trait或泛型参数，就会触发大范围增量重编。

比如你只是改了一个按钮的通用组件，下游几十个模块的代码都得重新生成。

再加上没有成熟的热更新系统，因此在UI体系的日常开发中，Rust语言相对于Dart来说，开发体验会更差。

老刘判断，应该会比基于Ja va/Kotlin的Android原生开发体验更差一点。

语言本身的编写体验

如果说前面讲的是语言附加工具链的差异，那么接下来就看看语言本身在日常开发中的差异。

抛开学习门槛先不谈，日常开发体验好的编程语言，应该让开发者把更多注意力放在业务逻辑上，而不是语言细节上。

从这个角度看，编程语言越偏向底层，开发者就越需要花费更多时间和精力去管理细节。

比如指针管理、内存分布、线程安全等。

因为底层系统需要编程语言暴漏这些细节，给开发者更灵活的控制。

放到具体的Rust开发过程中，就需要投入更多时间和精力去管理状态、生命周期、所有权等等。

总的来说，Rust语言的设计目标是性能和内存安全，而不是开发体验。

而Dart 相对来说就是放弃了对底层对象的直接控制，而是通过虚拟机和GC等机制来屏蔽底层细节。

如果是开发操作系统或者数据加解密等偏底层的系统，那么Rust语言的优势会非常明显。

但在开发普通的移动应用或者Web应用时，Dart语言这种屏蔽底层细节以换取开发效率和开发体验的取舍，会显得更合理，也更符合开发者预期。

生态与插件

除了站在语言本身的角度分析开发体验，影响开发体验的另一重因素就是生态。

生态问题其实比较难评价。

当初Flutter刚刚发布的时候，Dart语言也没啥生态可言，甚至可能还不如Rust的生态。

但有一点可能会带来较大影响：

Rust的学习曲线更陡峭，可能会影响更多第三方开发者的加入。

学习曲线

学习曲线的陡峭程度，基本上已经是比较公认的了，这里就不展开赘述了。

• Dart语法与心智模型接近Ja va/C#，易于大规模团队采用；空安全与异步模型贴合UI开发者习惯。
• Rust学习曲线显著更陡，UI开发广泛人群进入门槛提高，社区增长速度可能受限。

好了，前面我们分析了如果将Dart替换为Rust，为啥我觉得大概率不会比现在更好。

总结起来就是一句话：术业有专攻，Rust的设计初衷就是更多为了偏底层的系统开发，而不是为了UI的应用开发。

可能的优势场景（若选Rust）

前面说了很多Dart相对于Rust的优势，接下来也聊聊如果换成Rust，会得到哪些好处。

• 核心模块更稳

  • 布局计算、手势、文本 shaping 等内部逻辑性能更高，更稳定。

• 原生库复用

  • 通过C ABI更容易复用现有高性能原生库；安全FFI边界更清晰。

• 减少架构复杂度

  • 现有的Flutter架构体系中，很多通过FFI调用C/C++代码的场景，这些场景如果用Rust实现，就不需要再通过FFI调用了。
  • 比如视频编解码、数据加解密等等。
  • 这样可以避免很多潜在的异步、并发和线程安全等问题。

• 完善的宏体系

  • Rust的宏系统功能更加强大，表达能力更强，能够实现更多的代码生成和元编程。
  • 对于大型项目来说，Rust的宏系统能够帮助开发者更高效地组织代码，减少重复劳动。

综合评价

用Rust重做Flutter并不会在用户侧性能上带来决定性收益，反而会显著牺牲开发者体验与生态繁荣速度这两项关键成功因素。

现实世界里更合理的做法，是使用Dart这类高级语言作为UI主栈。

同时，在需要的地方把性能关键模块用Rust（或C++）实现，通过FFI嵌入。

这也与今天大型移动应用的常见工程实践一致。

总之，软件开发没有银弹，只有把问题拆小、用数据说话、靠迭代取胜。

如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

—— laoliu_dev