好奇心驱使,看看Android Jetpack Compose 1.5.1性能到底有没有提升?

前言

Android Jetpack Compose从2019年在Google I/O 大会上首度亮相,到2023年9月份发布 1.5.1 稳定版本已经有一些年头,但Compose的性能时至今日仍然是被开发者所诟病。

本篇文章,主要是满足笔者自己的好奇心,顺便使用Perfetto工具和大家一起测一测,这次新鲜出炉的 1.5.1 版本是否真的如官方所说的一样性能有所提升?

准备工作

  • AndroidStudio:Android Studio Giraffe | 2022.3.1 Patch 1
  • 一台Google Pixel4手机:搭载Android 12系统,开启开发者选项,开启HWUI呈现模式,选择在屏幕上显示为条形图,开启显示刷新频率;
  • 一个使用Android Jetpack Compose LazyColumn组件实现的列表App,集成滴滴开源的DoKit研发助手。

测试目标

对比Android Jetpack Compose 1.4.1 和 1.5.1版本的LazyColumn组件 的性能表现。实际上,从 1.3.0 起,Compose就对Modifier系统进行了重构,引入Modifier.Node作为Modifier.composed 的更高性能替代品,但这个过程不是一蹴而就的,需要时间逐步去完成替换。由于时间精力有限,笔者就不做 1.3.0 等其它版本的测试对比了。

温馨提示:Android官方推荐我们使用 Compose 物料清单 (BoM),通过指定 BoM 的版本来管理所有 Compose 库版本。

BOM 与 Compose 库版本对应表点这里查看

1.4.1 对应 2023.04.01,1.5.1 对应 2023.09.00

测试步骤

  1. 编写Shell脚本使用adb shell swipe命令模拟不断的在LazyColumn组件界面来回滑动;
  2. 使用Perfetto官方提供的record_android_trace辅助脚本录制trace文件,持续10秒左右,每个版本录制10次;
  3. 使用Perfetto UI打开录制好的trace文件,记录并统计android_frame_timeline_metric指标数据并汇总成表格;

LazyColumn组件界面没有很复杂,是从官方Jetchat项目拷贝过来的代码。看动图可以发现,左上角的屏幕刷新率和DoKit帧率是没有变化的。

测试数据

通过使用Perfetto获取android_frame_timeline_metric指标数据并汇总(每次10秒测10次),其中total_frames是应用的总帧数,missed_frames是应用丢帧的数量,fps是帧率=total_frames/时间(秒)

可能测试方式不是很合理(但是配合脚本测试起来很方便),如有更好的方式,欢迎大家指教。

Android Jetpack Compose 1.4.1

测试数据部分截图如下:

android_frame_timeline_metric指标数据

进程timieline

每次10秒测10次数据汇总:

序号 total_frames missed_frames fps
1 787 49 78.7
2 774 45 77.4
3 777 50 77.7
4 787 48 78.7
5 788 52 78.8
6 798 43 79.8
7 778 48 77.8
8 794 46 79.4
9 777 50 77.7
10 783 50 78.3
平均帧数 平均丢帧数 平均每秒丢帧数 平均帧率 平均丢帧率
784.3 48.1 4.81 78.4 5.77%

注:平均丢帧率 = 平均丢帧数 / (平均帧数+平均丢帧数)

Android Jetpack Compose 1.5.1

测试数据部分截图如下:

android_frame_timeline_metric指标数据

进程timieline

每次10秒测10次数据汇总:

序号 total_frames missed_frames
1 807 30
2 825 23
3 825 19
4 832 13
5 840 8
6 830 13
7 838 8
8 842 7
9 846 10
10 837 8
平均帧数 平均丢帧数 平均每秒丢帧数 平均帧率 平均丢帧率
832.3 13.9 1.39 83.2 1.64%

注:平均丢帧率 = 平均丢帧数 / (平均帧数+平均丢帧数)

数据比较

Compose版本 平均帧数 平均丢帧数 平均每秒丢帧数 平均帧率 平均丢帧率
1.4.1 784.3 48.1 4.18 78.4 5.77%
1.5.1 832.3 13.9 1.39 83.2 1.64%

显而易见,使用同样的机型,同样的测试代码,1.5.1 相对 1.4.1帧率更高丢帧更少,虽然不能说是遥遥领先,但确实是有显著提升,而且对比Timeline也很明显。

注:可能大家会觉得测试的时间短或者测试的次数小导致样本数据小不合理,但是实际上笔者经过多次测试发现(延长时间和增加测试次数),基本上这俩个版本的数据差距在Android 12系统的Google Pixel4上差不多就是这样,只是限于篇幅就不过多展示了数据了,感兴趣并且有条件有时间的朋友可以自己测试看看,可能的话加入更多的版本,机型进行对比。

结论

因测试机型、时间和精力等方面的限制,本次测试并不严谨,测试数据也仅供参考。但依然可以用这个小样本数据来回答本文开头提出的疑问:

Android Jetpack Compose 1.5.1 性能有明显提升,体验上更加丝滑了,建议大家赶紧升级。

正如Android官方所说的那样,Android Jetpack Compose很努力,性能正在变得越来越好。

什么?还没用上Jetpack Compose?这个不重要,程序员也要学会跳出技术的角度从更宏观的角度来考人生,人生短短数十载,珍惜当下,拥抱未来,跟上变化。

感谢

相关推荐
alexhilton6 小时前
SnapshotFlow还是collectAsState?对于Jetpack Compose来说哪个更香?
android·kotlin·android jetpack
顾林海8 小时前
Android 性能优化:启动优化全解析
android·java·面试·性能优化·zygote
断剑重铸之日10 小时前
Flutter 滑动面板组件(修复版)
flutter·性能优化
顾林海16 小时前
Android深入解析 so 文件体积优化
android·面试·性能优化
勤奋的知更鸟16 小时前
JavaScript 性能优化实战:深入性能瓶颈,精炼优化技巧与最佳实践
开发语言·javascript·性能优化
_一条咸鱼_18 小时前
Android Runtime安全上下文管理(76)
android·面试·android jetpack
_一条咸鱼_18 小时前
Android Runtime跨进程调用优化方案深度解析(75)
android·面试·android jetpack
_一条咸鱼_18 小时前
OpenGL ES 深度剖析
android·面试·android jetpack
mit6.82419 小时前
[Nagios Core] 事件调度 | 检查执行 | 插件与进程
c语言·开发语言·性能优化
Code季风21 小时前
深度优化 spring 性能:从缓存、延迟加载到并发控制的实战指南
java·spring boot·后端·spring·缓存·性能优化