为什么 Flutter 的性能问题，更像“前端问题”，而不是“原生问题”？

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

前言

如果你是从RN / Web / iOS一路走过来再写 Flutter，大概率都会有一个非常强烈的感觉：

Flutter 的很多性能问题，看起来不像原生问题，反而特别像前端问题。

不是卡在系统层，也不是卡在 CPU，而是卡在——
“谁触发了刷新”“刷了多少”“为什么不该刷的也刷了”。

这篇文章我们就站在RN / 前端 / iOS 的对比视角，把 Flutter 的性能问题掰开来看，看看它到底在“像谁”。

Flutter 的 rebuild，本质上和 React 的 re-render 是一回事

很多 Flutter 新手一开始都会被一句话洗脑：

Flutter 很快，因为是自绘 UI。

但真正写过一段时间你会发现，自绘解决的是“怎么画”，而不是“画多少次”。

Flutter 的核心问题不是“慢”，而是“画太多”

在 Flutter 里，只要触发了setState：

setState((){count++;});

当前 Widget 以及它的子树，都会重新执行 build 方法。

这件事和 React 非常像：

setCount(count + 1);

React 会重新执行当前组件的 render，然后通过 diff 决定哪些 DOM 要更新。

区别只在于：

• React：diff 后更新 DOM
• Flutter：diff 后生成新的 RenderObject 树

问题的本质完全一致：

状态变化 → 重新描述 UI → 对比 → 更新

所以你会发现，Flutter 的很多性能坑，和 React 一模一样：

• 状态放得太高
• rebuild 范围过大
• 一个变量变化，整个页面都跟着动

一个最容易写崩的 Flutter Demo

先来看一个非常常见、也非常“自然”的写法。

问题示例：整个页面被 setState 带着跑

classCounterPageextendsStatefulWidget{@override_CounterPageStatecreateState()=>_CounterPageState();}class_CounterPageStateextendsState<CounterPage>{int count=0;@overrideWidgetbuild(BuildContextcontext){print("build CounterPage");returnScaffold(appBar:AppBar(title:Text("Counter")),body:Column(children:[Text('Count:$count',style:TextStyle(fontSize:32),),ElevatedButton(onPressed:(){setState((){count++;});},child:Text("Increment"),),HeavyWidget(),],),);}}classHeavyWidgetextendsStatelessWidget{@overrideWidgetbuild(BuildContextcontext){print("build HeavyWidget");returnContainer(height:200,color:Colors.blue,);}}

实际运行会发生什么？

每点一次按钮，你会看到控制台输出：

build CounterPage build HeavyWidget

哪怕HeavyWidget和count毫无关系，它也会被重新 build。

如果你写过 React，是不是马上就联想到一句话：

“父组件 re-render，子组件默认都会跟着 render。”

这就是 Flutter 性能问题“前端化”的根源

很多人会问：

Flutter 不是号称性能接近原生吗？
为什么我写起来和 React 一样容易卡？

原因其实很简单：

Flutter 是声明式 UI，而不是命令式 UI

我们对比一下三种思路：

iOS UIKit（命令式）

label.text="Count:\(count)"

• 你只更新一个控件
• 系统不会帮你“重画整个页面”
• 错误空间小，但灵活性低

React / Flutter（声明式）

Text('Count:$count')

• UI = 状态的函数
• 状态变了，就重新算 UI
• 范围控制全靠开发者

声明式 UI 的性能好坏，几乎完全取决于：

你有没有把“变化控制在最小范围内”

这就是为什么 Flutter 更像前端，而不是传统原生。

Widget 拆分，本质就是 Component 拆分

很多 Flutter 性能优化文章都会告诉你一句话：

“多拆 Widget。”

但如果你不理解背后的原因，这句话是没法真正用好的。

Flutter 的 Widget 拆分，等价于 React 的组件拆分

我们改写刚才的例子：

classCounterPageextendsStatefulWidget{@override_CounterPageStatecreateState()=>_CounterPageState();}class_CounterPageStateextendsState<CounterPage>{int count=0;@overrideWidgetbuild(BuildContextcontext){returnScaffold(appBar:AppBar(title:Text("Counter")),body:Column(children:[CounterText(count:count),ElevatedButton(onPressed:(){setState((){count++;});},child:Text("Increment"),),constHeavyWidget(),],),);}}classCounterTextextendsStatelessWidget{finalint count;constCounterText({requiredthis.count});@overrideWidgetbuild(BuildContextcontext){print("build CounterText");returnText('Count:$count',style:TextStyle(fontSize:32),);}}classHeavyWidgetextendsStatelessWidget{constHeavyWidget();@overrideWidgetbuild(BuildContextcontext){print("build HeavyWidget");returnContainer(height:200,color:Colors.blue,);}}

关键变化点在哪里？

• HeavyWidget使用了const
• CounterText成为独立 Widget
• rebuild 范围被压缩

运行后你会发现：

build CounterText

HeavyWidget不再重新 build。

这和 React 里的memo、PureComponent本质一模一样。

为什么 Flutter 更需要“结构设计能力”

这也是很多 iOS 开发者转 Flutter 时最不适应的地方。

iOS 原生：结构随便，更新精准

• MVC/MVVM 强约束
• 控件更新是命令式
• 写得再烂，也不至于整页刷新

Flutter / 前端：结构就是性能边界

在 Flutter 里：

• 状态放在哪，决定了 rebuild 范围
• Widget 怎么拆，决定了性能上限
• build 结构本身就是“性能设计”

这也是为什么：

Flutter 项目越大，越像前端工程，而不像传统原生工程。

RN、前端踩过的坑，在 Flutter 里会再踩一遍

如果你有 RN 或前端经验，会发现很多问题异常熟悉：

• useState 滥用 → rebuild 抖动
• 状态提升过度 → 整棵树刷新
• 列表 item 不稳定 → diff 失效

Flutter 里只是换了名字：

底层逻辑一模一样。

前端经验在 Flutter 中，反而是加分项

如果你问我：

什么背景的人，学 Flutter 最快、踩坑最少？

我的答案通常是：

写过 React，并且真的踩过性能坑的人。

因为你已经习惯了：

• 控制状态作用范围
• 拆组件而不是堆逻辑
• 把性能当成结构问题，而不是“调参数”

这些能力，在 Flutter 中完全可以复用。

总结

Flutter 的性能问题之所以“像前端”，不是因为它不够原生，而是因为：

• 它是彻底的声明式 UI
• 性能边界由结构设计决定
• rebuild 本质等同于 re-render

如果你用iOS 命令式思维写 Flutter，很容易踩坑；
但如果你用前端组件化思维来设计 Flutter，性能反而会非常稳。