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

感谢

相关推荐
人工智能培训咨询叶梓4 小时前
探索开放资源上指令微调语言模型的现状
人工智能·语言模型·自然语言处理·性能优化·调优·大模型微调·指令微调
CodeToGym6 小时前
Webpack性能优化指南:从构建到部署的全方位策略
前端·webpack·性能优化
无尽的大道7 小时前
Java字符串深度解析:String的实现、常量池与性能优化
java·开发语言·性能优化
superman超哥7 小时前
04 深入 Oracle 并发世界:MVCC、锁、闩锁、事务隔离与并发性能优化的探索
数据库·oracle·性能优化·dba
前端青山17 小时前
Node.js-增强 API 安全性和性能优化
开发语言·前端·javascript·性能优化·前端框架·node.js
青云交1 天前
大数据新视界 -- 大数据大厂之 Impala 性能优化:应对海量复杂数据的挑战(上)(7/30)
大数据·性能优化·impala·数据分区·查询优化·海量复杂数据·经典案例
chusheng18401 天前
Python 爬取大量数据如何并发抓取与性能优化
开发语言·python·性能优化
XMYX-02 天前
MySQL 性能优化策略:提升响应速度与系统稳定性
mysql·性能优化
PangPiLoLo2 天前
高可用架构-业务高可用
java·性能优化·架构
尸僵打怪兽2 天前
软考(中级-软件设计师)数据库篇(1101)
数据库·oracle·性能优化·软考