Compose 渲染性能到底怎么样?
前言
去年曾经写过一篇文章调研
Compose
的性能:相比 XML , Compose 性能到底怎么样?
不过这篇文章主要是从包体积,页面首次打开时间来分析
Compose
的性能,而
Compose
作为一个
UI
框架,相信大家更关注它的渲染性能比如
FPS
,本文主要就是从
FPS
的角度来分析
Compose
的性能
本文主要包括以下内容:
如何测量 Compose
的FPS
Compose
列表渲染性能分析Compose
粒子动画渲染性能分析
如何测量Compose
的FPS
所谓
FPS
也就是每秒显示的帧数,Android
设备的 FPS
一般是 60,也即每秒要刷新 60 帧,所以留给每一帧的绘制时间最多只有 1000/60 = 16.67ms 。一旦某一帧的绘制时间超过了限制,就会发生 掉帧,用户在连续两帧会看到同样的画面。监测
Android
应用的
FPS
,其实已经是相当成熟了,主要就是利用
Choreographer.getInstance().postFrameCallback()
方法,在这里就不缀述了。
那么,我们该怎么监听
Compose
的
FPS
呢?利用
Choreographer
监测仍然适用于
Compose
吗?
其实
Choreographer
依然可以用来监测
Compose
的
FPS
,不过
Compose
提供了更加方便的
API
供我们使用:
withFrameMillis
withFrameMillis
本质上是对
Choreographer
代码的封装,它会在下一帧到来时回调,并且会返回下一帧开始绘制的时间
下面我们来看下如何利用
withFrameMillis
来监测
Compose
的
FPS
@Composable
funFpsMonitor(modifier: Modifier) {
var fpsCount by remember { mutableStateOf(0) }
var fps by remember { mutableStateOf(0) }
var lastUpdate by remember { mutableStateOf(0L) }
Text(
text = "Fps: $fps", modifier = modifier
.size(60.dp), color = Color.Red, style = MaterialTheme.typography.body1
)
LaunchedEffect(Unit) {
while (true) {
withFrameMillis { ms ->
fpsCount++
if (fpsCount == 5) {
fps = (5000 / (ms - lastUpdate)).toInt()
lastUpdate = ms
fpsCount = 0
}
}
}
}
}
代码逻辑很简单:
withFrameMillis
会返回每一帧开始绘制的时间,两帧开始绘制时间的差值就是一帧绘制的时间1000/(ms-lastUpdate)
就是1秒内可以绘制的帧数,也就是FPS
为了避免帧数抖动过快,我们每5帧计算一次平均 FPS
,也就是fps = (5000 / (ms - lastUpdate)).toInt()
Compose
列表渲染性能分析
关于
Compose
的列表的性能问题也是老生常谈了,很多人都说Compose
的LazyColumn
在低端手机上会卡顿,那么我们就来分析比较一下同一个页面用LazyColumn
与RecyclerView
分别实现,在性能上有什么差距?首先来看下页面的样式
如上,这个页面整体是一个列表,共有4种类型
可左右滑动的 Banner
包含文字与一张图片的 item
包含3张图片的复杂 item
作为视频封面的大图 item
然后我们用
LazyColumn
与RecyclerView
分别实现以上页面,然后在不同手机上分别测量其快速滑动时的FPS
,结果如下:Compose vs View | Android 5.1 | Android 7.1 | Android 11 |
---|---|---|---|
LazyColumn | 21 FPS | 43 FPS | 60 FPS |
RecyclerView | 60 FPS | 60 FPS | 60 FPS |
同时在
debug
包与
release
包都进行了以上测试,结果基本一致。可以看出,
LazyColumn
与
RecyclerView
在性能上的确有一定差距,尤其在低端手机上,
LazyColumn
快速滑动时掉帧明显,而
RecyclerView
则都很流畅
只能说
RecyclerView
太强了~
Compose
粒子动画渲染性能分析
除了列表,我们也可以通过粒子动画的方式来测量
Compose
的性能,通过粒子动画我们可以评估在极端情况下Compose
与View
的渲染性能首先来看下粒子动画效果:
如上,我们可以在画布上生成随机粒子并且做动画,随着粒子数量的增长,观察应用的
FPS
,以此评估Compose
的渲染性能,我们同时也实现了一个View
版本以进行对比,结果如下:Compose VS View | 100 | 1000 | 3000 | 10000 |
---|---|---|---|---|
Android 5.1 Compose | 60 FPS | 23 FPS | 8 FPS | 2 FPS |
Android 5.1 View | 60 FPS | 25 FPS | 8 FPS | 2 FPS |
Android 7.1 Compose | 60 FPS | 49 FPS | 21 FPS | 8 FPS |
Android 7.1 View | 60 FPS | 52 FPS | 22 FPS | 8 FPS |
Android 11 Compose | 60 FPS | 60 FPS | 60 FPS | 60 FPS |
Android 11 View | 60 FPS | 60 FPS | 60 FPS | 60 FPS |
可以看出,随着粒子数从
100
增长到
10000
,应用的
FPS
逐渐降低,在低端手机上尤其明显
而与列表不同的是,
Compose
与
View
在粒子动画中的渲染性能几乎一致,可以说是几乎没有区别
总结
本文主要从
FPS
的角度分析介绍了
Compose
的渲染性能,可以看出在画布中随机生成粒子动画时,
Compose
与
View
的渲染性能几乎一致。
而对于复杂列表,
LazyColumn
与
RecyclerView
在性能上有一定差距,在低端手机上尤其明显,在快速滑动时会有明显卡顿。
结合两个实验,看起来应该是
LazyColumn
组件存在一定性能问题,而
Compose
本身的渲染性能已经基本与
View
一致了~
项目地址
本文所有代码可见:https://github.com/shenzhen2017/compose-fps
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。