好奇心驱使,看看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 小时前
实验四 mybatis动态sql及逆向工程
sql·性能优化·mybatis
!chen9 小时前
大数据技术领域发展与Spark的性能优化
大数据·性能优化·spark
小园子的小菜9 小时前
接口性能优化实战:5大策略+落地案例
性能优化
Ulyanov10 小时前
大规模战场数据与推演:性能优化与多视图布局实战
开发语言·python·性能优化·tkinter·pyvista·gui开发
晓风残月淡10 小时前
高性能MYSQL(四):查询性能优化
数据库·mysql·性能优化
郝学胜-神的一滴10 小时前
机器学习数据预处理:归一化与sklearn的MinMaxScaler详解
人工智能·python·程序人生·机器学习·性能优化·sklearn
Curvatureflight12 小时前
前端性能优化指南:从加载到交互的每一毫秒
前端·性能优化·交互
国科安芯12 小时前
无人驾驶物流车网关的多路CANFD冗余架构与通信可靠性分析
单片机·嵌入式硬件·性能优化·架构·自动驾驶·安全性测试
REDcker13 小时前
WASM 软解 H.265 性能优化详解
性能优化·wasm·h.265
居7然21 小时前
ChatGPT是怎么学会接龙的?
深度学习·语言模型·chatgpt·性能优化·transformer