假如Flutter用Rust，你也写不出更快的App

哈喽，我是老刘

老刘前段时间写了两篇关于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