当前位置：首页 > news >正文

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

news 2026/3/26 17:35:01

网罗开发（小红书、快手、视频号同名）

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

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

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

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

文章目录

- 前言
- Flutter 的 rebuild，本质上和 React 的 re-render 是一回事
- - Flutter 的核心问题不是“慢”，而是“画太多”
- 一个最容易写崩的 Flutter Demo
- - 问题示例：整个页面被 setState 带着跑
  - 实际运行会发生什么？
- 这就是 Flutter 性能问题“前端化”的根源
- - Flutter 是声明式 UI，而不是命令式 UI
  - - iOS UIKit（命令式）
    - React / Flutter（声明式）
- Widget 拆分，本质就是 Component 拆分
- - Flutter 的 Widget 拆分，等价于 React 的组件拆分
  - 关键变化点在哪里？
- 为什么 Flutter 更需要“结构设计能力”
- - iOS 原生：结构随便，更新精准
  - Flutter / 前端：结构就是性能边界
- RN、前端踩过的坑，在 Flutter 里会再踩一遍
- 前端经验在 Flutter 中，反而是加分项
- 总结

前言

如果你是从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,);}}