Flutter性能优化实践 —— UI篇

最新推荐文章于 2025-04-30 08:00:00 发布

2401_84407867

最新推荐文章于 2025-04-30 08:00:00 发布

阅读量1k

点赞数 13

分类专栏：程序员文章标签： flutter ui 数据库

本文链接：https://blog.youkuaiyun.com/2401_84407867/article/details/138874079

版权

在官方文档中，性能分析需要确保使用真机并在profile模式下运行。不过我们可以使用debug模式来寻找卡顿，因为我觉得它可以放大你的“问题”。

下面正式进入正题。（为了显得口语化一点，我会将Flutter的构建（build）用“刷新”表示。本篇源码基于Flutter SDK版本 1.17.0）

2.控制刷新范围

我们使用setState方法就可以轻松刷新页面，但是要尽力控制刷新范围。我举一个例子：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传在注册账户时，通常需要获取验证码。这时会有一个倒计时功能，那么我们就需要每隔一秒刷新一下这个倒计时数字并显示出来。

如果这个倒计时的逻辑处理你放在了注册页面，那么每当setState时都是一整个页面的刷新。而这整页刷新显然是不必要的。而它并不会让你感知到卡顿，所以也不易发现，

解决方法就是将这个倒计时的按钮单独封装到一个StatefulWidget，在这个StatefulWidget中使用setState刷新，控制刷新范围。

同样的，你也可以使用provider等状态管理框架来实现局部刷新。精准控制你的刷新范围，千万不要setState刷新一把梭。

3.控制刷新次数

比起控制刷新范围，控制刷新次数（避免无效刷新）甚至更加重要。这部分我整理了四点，下面逐一说明一下。

需求控制

还是上面的注册场景，这里需要我们输入的内容满足条件才可以点击注册按钮。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传那么我们的做法就是监听TextField的文字输入，每次输入时判断是否满足条件，更新按钮是否可点击的状态。代码大致如下：

bool _clickable = false;

void _verify() {
String phone = _phoneController.text;
String vCode = _vCodeController.text;
String password = _passwordController.text;
_clickable = true;
if (phone.isEmpty || phone.length < 11) {
_clickable = false;
}
if (vCode.isEmpty || vCode.length < 6) {
_clickable = false;
}
if (password.isEmpty || password.length < 6) {
_clickable = false;
}
setState(() {

});
}

MyButton(
onPressed: _clickable ? _register : null,
text: ‘注册’,
)

其实这里可以优化一下。因为现在的每次输入都必定刷新，我们可以在_clickable参数有变化时再刷新，避免无效的刷新。优化的代码如下：

void _verify() {
String phone = _phoneController.text;
String vCode = _vCodeController.text;
String password = _passwordController.text;
bool clickable = true;
if (phone.isEmpty || phone.length < 11) {
clickable = false;
}
if (vCode.isEmpty || vCode.length < 6) {
clickable = false;
}
if (password.isEmpty || password.length < 6) {
clickable = false;
}
/// 状态不一致时刷新
if (clickable != _clickable) {
setState(() {
_clickable = clickable;
});
}
}

就这样一个简单的处理，试想一下可以减少多少次的刷新。

类似的，在CustomPainter中有个shouldRepaint的重写方法，我们可以根据需求控制CustomPainter是否进行重绘。

预构建Widget

动画的使用在实际开发中很常见，但是一旦使用不当也会造成不必要的刷新，甚至会带来卡顿。

举一个deer中的例子，商品列表页中有一个商品操作菜单的呼入呼出动画（这里就不谈具体的实现效果了，有兴趣的可以去看源码）。一开始的写法如下：

AnimatedBuilder(
animation: animation,
builder:(_, __) {
return MenuReveal(
revealPercent: animation.value,
child: _buildGoodsMenu(context),
);
}
)

效果如下：外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传这个动画看起来还是比较流畅的。顶部的性能图表(Performance Overlay)中，UI花费的时间平均在7.2ms/frame。比起16ms的安全标准来说已经非常好了。

但是我们来看看构建次数（呼入呼出各一次）：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传这里仔细看就有点问题，动画执行时我们只希望可变的部分刷新（MenuReveal），但实际上连菜单中的按钮也一起刷新构建了。

那么优化的方法就是预构建菜单中的按钮，将_buildGoodsMenu(context)方法放在AnimatedBuilder之前执行再传入或是放在AnimatedBuilder的child中。

AnimatedBuilder(
animation: animation,
child: buildGoodsMenuContent(context), // <-----放在这里
builder:(, child) {
return MenuReveal(
revealPercent: animation.value,
child: child // <----这里使用
);
}
)

效果如下：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传可以看到UI线程花费的时间在6ms/frame左右。这个提升还是比较大的（16%左右），虽然对于用户来说是无感知的。