好奇心驱使,看看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?这个不重要,程序员也要学会跳出技术的角度从更宏观的角度来考人生,人生短短数十载,珍惜当下,拥抱未来,跟上变化。

感谢

相关推荐
鬓戈7 小时前
Qwen3.8-27B + vLLM 性能优化
人工智能·性能优化·vllm
yunwei378 小时前
eBPF 示例教程:实现 `scx_nest` 调度器
linux·后端·性能优化
HwJack208 小时前
【HarmonyOS开发小实践】ArkUI 应用级状态AppStorage 与跨页面共享、持久化
ui·华为·性能优化·harmonyos
FlashGeek10 小时前
全 AI 实战: 一次语音房 Flutter内核 native 内存泄露的定位与修复
性能优化
wuyk55513 小时前
从零吃透 MQTT 通信|第 11 章 MQTT 项目调试验证、性能优化、常见疑难问题、OTA 升级基础
c语言·开发语言·stm32·学习·性能优化
忆~遂愿15 小时前
Paperless-ngx 部署实战:PostgreSQL + Redis 文档库与固定公网访问
性能优化
天天喝旺仔1 天前
Go 并发编程:Goroutine 与 Channel 实战
云原生·性能优化·架构·go
iNeuOS工业互联网2 天前
iNeuOS工业互联网操作系统,重要更新:性能优化、安全漏洞与BUG修复,远程控制响应效率大幅提升
性能优化·bug
Web3&Basketball2 天前
LLM 峰谷定价怎么吃满:一个能对账的错峰调度器
python·性能优化·大模型·任务调度·成本优化·deepseek·推理优化
yunwei372 天前
eBPF 教程:追踪 CUDA GPU 操作
linux·后端·性能优化