认真对待每时、每刻每一件事,把握当下、立即去做。
Flutter UI 性能优化实践经验,结合关键优化方向和具体代码示例进行一个解析。
一. 布局优化
1. 减少布局计算
使用 ListView.builder 实现懒加载,只构建可见项,避免一次性计算所有子项布局。同时要注意避免在 Column 中嵌套 ListView 导致布局冲突:
// ❌ 错误写法 Column(children: [ Header(), ListView(children: items.map((e) => Item(e)).toList()) ]) // ✅ 正确写法 Column(children: [ Header(), Expanded(child: ListView.builder(itemCount: items.length)) ])
2. 分帧渲染
2.1 分帧渲染解析
对复杂卡片采用分帧构建策略,这里说的是过渡帧,本质上会增加总渲染时间,但改善了感知性能提升体验。
bool _showRealContent = false; @override void initState() { super.initState(); WidgetsBinding.instance.addPostFrameCallback((_) { setState(() => _showRealContent = true); // 下一帧加载真实内容 }); } Widget build(BuildContext context) => _showRealContent ? _buildReal() : _buildPlaceholder();
addPostFrameCallback 工作原:WidgetsBinding.instance.addPostFrameCallback 会在当前帧绘制完成后执行回调函数,且回调只执行一次。
分帧渲染的本质是将原本可能超过 16.6ms 的构建任务拆解为多个子任务,分散到连续帧中执行。例如,对长列表的逐项渲染或复杂动画的分步计算。而示例中的“过渡帧”仅通过占位符延迟真实内容加载,属于视觉优化手段,未实际拆分构建任务。
用户代码通过 _showRealContent 控制占位符与真实内容的切换,仅减少首帧的构建压力,但若 _buildReal() 本身耗时仍超过 16.6ms,依然会引发卡顿。真正的分帧渲染需结合 Future.delayed、compute 隔离计算或 ListView.builder 的懒加载机制。
2.2 分帧渲染实现
2.2.1 使用 Future.delayed 分帧渲染
通过将任务拆分为多个异步帧执行,避免主线程阻塞:
Future<void> _loadDataInFrames(List<Widget> widgets) async { for (var i = 0; i < widgets.length; i++) { await Future.delayed(Duration(milliseconds: 16)); // 约60fps的帧间隔 setState(() { _visibleWidgets.add(widgets[i]); // 逐帧添加Widget到界面 }); } }
特点:
- 适用于顺序加载大量小部件;
- 需手动控制帧间隔时间,避免过快导致卡顿。
2.2.2 使用 compute 隔离计算
将耗时计算放到隔离线程,完成后分帧更新 UI:
// 定义耗时计算函数(需为顶级函数或静态方法) static int _heavyCalculation(int input) { return input * 2; // 模拟复杂计算 } // 在UI线程调用 void _startCalculation() async { final result = await compute(_heavyCalculation, 1000000); setState(() => _result = result); // 计算完成后更新UI }
特点:
- 适合 CPU 密集型任务(如 JSON 解析、图像处理)。
- 需注意数据序列化限制(不能传递闭包或非基本类型)。
2.2.3 ListView.builder 懒加载机制
自动按需渲染可见区域的子项:
ListView.builder( itemCount: 1000, itemBuilder: (context, index) { return ListTile( title: Text('Item $index'), ); }, )
优化技巧:
- 结合
itemExtent固定子项高度提升性能。 - 复杂子项使用
RepaintBoundary隔离重绘。
2.2.4 其他分帧渲染方法
Keframe 组件库
FrameSeparateWidget( child: YourComplexWidget(), // 包裹复杂组件 )
效果:自动拆分组件树为多帧渲染,卡顿减少50%。
2.2.4 综合建议
- 轻量级任务:优先用
Future.delayed。 - 计算密集型:选择
compute或 Isolate。 - 长列表:
ListView.builder+RepaintBoundary。 - 复杂页面:集成 Keframe 组件。
3. RelayoutBoundary 布局边界
在开发中一般很不直接使用 RelayoutBoundary,我们可以使用三个条件来触发 RelayoutBodudary 生效。
3.1 constraints.isTight
强约束,Widget 的 size 已经被确定,里面的子 Widget 做任何变化,size 都不会变。那么从该 Widget 开始里面的任意子 Wisget 做任意变化,都不会对外有影响,就会被添加 Relayout boundary(说添加不科学,因为实际上这种情况,它会把 size 指向自己,这样就不会再向上递归而引起父 Widget 的Layout了)。
3.2 parentUsesSize == false
实际上 parentUsesSize 与 sizedByParent 看起来很像,但含义有很大区别
parentUsesSize 表示父 Widget 是否要依赖子 Widget 的 size,如果是 false,子Widget 要重新布局的时候并不需要通知 parent,布局的边界就是自身了。
3.3 sizedByParent == true
可以理解为"尺寸由父级全权决定"的布局模式。当 Widget 设置该属性时,它的尺寸不依赖自身内容计算,而是完全服从父级分配的约束条件,就像学生按照老师指定的座位表入座,无需自己找位置。
父级主导:尺寸由父级约束直接确定,跳过 Widget 自身的布局计算逻辑。
非严格约束:虽非isTight(严格约束),但通过父级规则(如 Flex 布局的剩余空间分配)仍能明确尺寸。
性能优化:避免子 Widget 重复计算尺寸,提升布局效率。
RelayoutBoundary 的设立原则是:子节点尺寸变化不会影响父节点尺寸。
若 sizedByParent == true,由于子节点尺寸完全依赖父节点约束,其自身尺寸变化不会向上传递影响父节点,因此自然满足 RelayoutBoundary 的条件。
二. 渲染优化
1. 控制刷新范围
将频繁更新的 UI 部分拆分为独立 Widget,避免全局刷新。例如验证码倒计时组件:通过将倒计时状态移至子组件(状态下移),避免父组件因状态更新而重建,实现精准刷新。
class CountdownButton extends StatefulWidget { @override _CountdownButtonState createState() => _CountdownButtonState(); } class _CountdownButtonState extends State<CountdownButton> { int _seconds = 60; void _startCountdown() { Timer.periodic(Duration(seconds: 1), (timer) { if (_seconds == 0) timer.cancel(); setState(() => _seconds--); }); } @override Widget build(BuildContext context) => Text('$_seconds秒'); }
相比在父组件中使用 setState,此实现仅刷新倒计时文本。
2. 避免无效重建
使用 const 构造函数声明静态 Widget:
const Text('静态文本'), // ✅ 编译期确定 Text('动态文本') // ❌ 每次重建
3. 隔离重绘区域
对复杂子组件使用 RepaintBoundary 隔离重绘区域。
RepaintBoundary 隔离动画
RepaintBoundary( child: AnimatedContainer(...), // 独立重绘的动画组件 )
三. 动画优化
1. AnimatedBuilder 最佳实践
预构建静态子组件避免重复创建:
AnimatedBuilder( animation: _animation, child: const HeavyWidget(), // ✅ 预构建 builder: (_, child) => Transform.rotate( angle: _animation.value, child: child // 复用子组件 ) )
相比直接在 builder 内创建子组件,性能提升约 16%。
2. 使用 Tween 动画
优先使用轻量级动画类型:
AnimationController( duration: const Duration(seconds: 1), vsync: this, )..repeat(reverse: true); final Animation<double> _animation = Tween(begin: 0.0, end: 1.0).animate(_controller);
四. 列表优化
1. 长列表处理
使用 ListView.builder+itemExtent 提升滚动性能:
ListView.builder( itemCount: 10000, itemExtent: 56.0, // 固定高度避免动态计算 itemBuilder: (ctx, i) => ListTile(title: Text('Item $i')) )
结合 AutomaticKeepAliveClientMixin 实现状态保持。
2. 图片懒加载
使用 cached_network_image 优化网络图片:
CachedNetworkImage( imageUrl: 'https://example.com/image.jpg', placeholder: (_, __) => CircularProgressIndicator(), errorWidget: (_, __, ___) => Icon(Icons.error), )
五、状态管理优化
1. 精准更新
使用 Provider 实现局部刷新:
Selector<Model, String>( selector: (_, model) => model.title, builder: (_, title, __) => Text(title) // 仅title变化时重建 )
相比 Consumer 减少不必要的重建。
2. 避免 build 中创建对象
// ❌ 错误:每次build新建Logger Widget build() { final logger = Logger(); return ... } // ✅ 正确:提前初始化 static const _logger = Logger(); Widget build() => ...
六. 工具与调试
1. 性能分析工具
- 使用 DevTools 的 Performance 视图检测超时帧(红色标记)。
- 开启
Repaint Rainbow检查过度重绘的 Widget。
2. 构建模式
始终在 profile 模式下测试性能:
flutter run --profile
调试模式会引入额外性能开销。
通过以上六大方向的优化组合,可使 Flutter 应用达到 60FPS 的流畅体验。实际开发中建议结合 DevTools 持续监控性能指标。