_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%左右),虽然对于用户来说是无感知的。
再次看一下构建次数:
那么提升的原因也就找到了,因为避免了不必要的构建。所以针对这类不依赖于动画的子Widget,预构建它可以显著提高性能。
类似这种builder/child的模式还有不少,你可以多多留意一下。
复用
- 尽量使用
const
来定义一些不变的Widget,这相当于缓存一个Widget并复用它。
我之前看到过一篇博客,作者测试一个页面上构建1000个重复图标,结果使用const
构造函数的,FPS大约高8.4%,内存使用量降低约20%。
当然作者也说了,实际一个页面上有1000个Widget也不现实。其实说这个点的原因也是希望大家能养成一个好习惯。
- 添加
GlobalKey
也能复用widget。这个使用场景相对较少,可以了解一下。相关内容链接:说说Flutter中的Key
RepaintBoundary
这个我之前有详细介绍过,可以直接查看:说说Flutter中的RepaintBoundary,这里我就不重复说了。合理的使用RepaintBoundary
可以减少不必要的刷新提升性能。
4.加载策略
按需加载
推荐使用ListView.builder
来动态实现列表,而不是直接使用ListView
静态创建。注意这里在使用ListView.builder
的itemBuilder
来构建item时,可不要预构建Widget了。类似的Widget还有PageView.builder
和 GridView.builder
。
PS:按需加载是一种策略,并不是仅仅依靠这几个类型的Widget。比如之前阿里AliFlutter的分享中,就有提到列表中加载图片的优化。通过判断图片的在屏和离屏,来合理回收图片,这样减小了内存的波动,同样也可以带来性能的提升。
错峰加载
错峰加载的目的是为了避免因同一时间的大量构建,而产生卡顿现象。这里我举一个例子:
在使用PageView.builder
这个Widget时,我发现在左右滑动切换页面时会有卡顿的现象。使用timeline
来分析发现两个问题,一是切换的页面比较复杂,比较耗时。二是页面构建的时间点在滑动中。
页面复杂的问题我进行了一定的优化,虽然有效果,但还是有卡顿发生。那么只能针对第二点再进行优化,我们先看一下PageView.
相关源码:
return NotificationListener(
onNotification: (ScrollNotification notification) {
if (notification.depth == 0 && widget.onPageChanged != null && notification is ScrollUpdateNotification) {
final PageMetrics metrics = notification.metrics;
final int currentPage = metrics.page.round();
if (currentPage != _lastReportedPage) {
_lastReportedPage = currentPage;
widget.onPageChanged(currentPage);
}
}
return false;
},
child: Scrollable(),
);
代码很简单,如果我们设置了onPageChanged
的监听,那么在滑动中(ScrollUpdateNotification
)计算当前页的页码并返回(round方法,四舍五入)。所以在滑动到一半的时候,onPageChanged
就会回调结果,我因为在这里触发了页面的刷新代码,导致了卡顿的发生。
其实在我熟知的安卓中,默认行为都是在滑动结束后才去加载页面数据。所以按照这个思路处理,调整一下加载策略。
修改代码如下:
NotificationListener(
onNotification: (ScrollNotification notification) {
if (notification.depth == 0 && notification is ScrollEndNotification) {
final PageMetrics metrics = notification.metrics;
final int currentPage = metrics.page.round();
if (currentPage != _lastReportedPage) {
_lastReportedPage = currentPage;
_onPageChange(currentPage);
}
}
return false;
},
child: PageView.builder(),
)
我们在PageView.builder
上添加一个NotificationListener
,同时修改ScrollUpdateNotification
为ScrollEndNotification
。这样就自定义了我们的滑动监听事件,通过错峰加载保证了UI的流畅。
PS:在Flutter 1.17的重要改动中就有一条:在高速滚动时推迟图像解码。这也是运用了错峰加载的策略。
5.耗时计算
避免将一些耗时计算放在UI线程,我们可以把耗时计算放到Isolate
去执行(多线程)。
举一个Flutter源码中的例子:
Future loadString(String key, { bool cache = true }) async {
final ByteData data = await load(key);
if (data == null)
throw FlutterError(‘Unable to load asset:
k
e
y
′
)
;
i
f
(
d
a
t
a
.
l
e
n
g
t
h
I
n
B
y
t
e
s
<
10
∗
1024
)
/
/
10
K
B
t
a
k
e
s
a
b
o
u
t
3
m
s
t
o
p
a
r
s
e
o
n
a
P
i
x
e
l
2
X
L
.
/
/
S
e
e
:
h
t
t
p
s
:
/
/
g
i
t
h
u
b
.
c
o
m
/
d
a
r
t
−
l
a
n
g
/
s
d
k
/
i
s
s
u
e
s
/
31954
r
e
t
u
r
n
u
t
f
8.
d
e
c
o
d
e
(
d
a
t
a
.
b
u
f
f
e
r
.
a
s
U
i
n
t
8
L
i
s
t
(
)
)
;
r
e
t
u
r
n
c
o
m
p
u
t
e
(
u
t
f
8
d
e
c
o
d
e
,
d
a
t
a
,
d
e
b
u
g
L
a
b
e
l
:
′
U
T
F
8
d
e
c
o
d
e
f
o
r
"
key'); if (data.lengthInBytes < 10 * 1024) { // 10KB takes about 3ms to parse on a Pixel 2 XL. // See: https://github.com/dart-lang/sdk/issues/31954 return utf8.decode(data.buffer.asUint8List()); } return compute(_utf8decode, data, debugLabel: 'UTF8 decode for "
key′);if(data.lengthInBytes<10∗1024)//10KBtakesabout3mstoparseonaPixel2XL.//See:https://github.com/dart−lang/sdk/issues/31954returnutf8.decode(data.buffer.asUint8List());returncompute(utf8decode,data,debugLabel:′UTF8decodefor"key"’);
}
static String _utf8decode(ByteData data) {
return utf8.decode(data.buffer.asUint8List());
}
因为utf8.decode
方法处理10KB数据大约需要3ms的时间(手机Pixel 2 XL),所以在超过10KB的数据就使用了compute
方法将耗时计算放到Isolate
。这里根据数据大小选择不同的方式,是因为Isolate
的创建使用也是有空间和时间上的消耗,所以Isolate虽好,可不要滥用哦!
同样的,我们项目中的json解析操作也可以这样处理,以保证在一些性能较差的机子上可以不造成UI的卡顿。具体实现可以看:在后台处理 JSON 数据解析
这里我简单说明一下原因:Flutter应用中的Dart
代码执行在UI Runner
中,而Dart
是单线程的,我们平时使用的异步任务Future
都是在这个单线程的Event Queue
之中,通过Event Loop
来按顺序执行。(这个单线程模型和js是一样的)
也就是说即使我们是异步执行这段计算代码,但由于这段代码耗时过长,那么这段时间内线程没有空闲(可以理解为任务代码都是插空执行?),也就是线程过载了。导致期间Widget的layout等计算迟迟无法执行,那么时间越长,卡顿的现象就越明显。
因此使用Isolate
来处理耗时计算,利用多线程来做到代码的并行执行。
可能这里你会有疑问,那我网络请求也是Dart代码而且有时也挺耗时的,怎么不见页面卡顿?其实这是因为网络请求在io线程,不会占用ui线程。且实际的网络请求也并不是在Dart层做的,Dart代码部分只是一层封装,真正的请求是由底层的操作系统去实现的。
6.GPU
上面的几点大都是关于UI线程的优化。其实在观察Performance Overlay
时,我们发现有时UI很流畅,但是GPU却会很耗时。这里主要是绘制上的压力比较大(GPU Runner
)导致的,可能包括对Skia
的saveLayer
、clipPath
等耗时函数调用。
saveLayer
会在GPU中分配一块新的绘图缓冲区(离屏渲染),切换绘图目标,这些操作是在GPU中非常的耗时,尤其在比较老的设备上。
使用
clipPath
会影响接下来每一个绘图指令。尤其这个Path比较复杂的时候都需要和这个复杂的Path做相交操作,而且把Path之外的部分剔除掉。
在Flutter源码中搜索canvas.saveLayer
可以发现一些需要注意的:
-
当
Text
的overflow
属性为TextOverflow.fade
,且文字超出范围时,会调用saveLayer
。 -
使用
Clip.antiAliasWithSaveLayer
作为剪切行为时,会调用saveLayer
(据说早期Flutter版本中大都使用这一方式)。建议优先使用Clip.hardEdge
和Clip.antiAlias
。这部分属性一般在ClipRect
、ClipOval
和ClipPath
等裁剪功能Widget中用到。 -
修改
RawChip
的isEnabled
属性,触发enableAnimation
动画时,会调用saveLayer
。
而对于clipPath
,相对没有saveLayer
耗时。但需要注意对于裁剪行为。优先考虑使用BoxDecoration
的borderRadius
属性来解决。比如Inkwell
的borderRadius
属性就可以裁剪它的外形,如果borderRadius
实在不能满足,可以使用customBorder
属性(使用clipPath
)。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![Flutter性能优化实践 —— UI篇,程序员,flutter,ui,javascript](https://imgs.yssmx.com/Uploads/2024/04/859553-6.jpeg)
结语
- 现在随着短视频,抖音,快手的流行NDK模块开发也显得越发重要,需要这块人才的企业也越来越多,随之学习这块的人也变多了,音视频的开发,往往是比较难的,而这个比较难的技术就是NDK里面的技术。
- 音视频/高清大图片/人工智能/直播/抖音等等这年与用户最紧密,与我们生活最相关的技术一直都在寻找最终的技术落地平台,以前是windows系统,而现在则是移动系统了,移动系统中又是以Android占比绝大部分为前提,所以AndroidNDK技术已经是我们必备技能了。
- 要学习好NDK,其中的关于C/C++,jni,Linux基础都是需要学习的,除此之外,音视频的编解码技术,流媒体协议,ffmpeg这些都是音视频开发必备技能,而且
- OpenCV/OpenGl/这些又是图像处理必备知识,下面这些我都是当年自己搜集的资料和做的一些图,因为当年我就感觉视频这块会是一个大的趋势。所以提前做了一些准备。现在拿出来分享给大家。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
又是图像处理必备知识,下面这些我都是当年自己搜集的资料和做的一些图,因为当年我就感觉视频这块会是一个大的趋势。所以提前做了一些准备。现在拿出来分享给大家。
[外链图片转存中…(img-6o8hAGqA-1711856811770)]文章来源:https://www.toymoban.com/news/detail-859553.html
[外链图片转存中…(img-l1bA8ZbU-1711856811770)]文章来源地址https://www.toymoban.com/news/detail-859553.html
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
到了这里,关于Flutter性能优化实践 —— UI篇的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!