相比 XML , Compose 性能到底怎么样?

相比 XML , Compose 性能到底怎么样?前言 最近Compose已经正式发布了1.0版本,这说明谷歌认为Compose已经可以用于正式生产环境了 那么相比传统的XML,Compose的性能到底怎么样呢?

前言

最近Compose已经正式发布了1.0版本,这说明谷歌认为Compose已经可以用于正式生产环境了
那么相比传统的XML,Compose的性能到底怎么样呢?

本文主要从构建性能与运行时两个方面来分析Compose的性能,数据主要来源于:Jetpack Compose — Before and afterMeasuring Render Performance with Jetpack Compose , 想了解更多的同学可以直接点击查看

构建性能

Compose构建性能主要以 tivi 为例来进行说明
Tivi是一个开源的电影App,原本基于FragmentXML构建,同时还使用了DataBinding等使用了注解处理器的框架
后来迁移到使用Compose构建UI,迁移过程分为两步

  1. 第一步:迁移到NavigationFragment,每个FragmentUI则由Compose构建
  2. 第二步:移除Fragment,完全基于Compose实现UI

下面我们就对Pre-Compose,Fragments + Compose,Entirely Compose三个阶段的性能进行分析对比

APK体积

包体积是我们经常关注的性能指标之一,我们一起看下3个阶段的包体积对比

p1.png
p2.png
可以看出,TiviAPK 大小缩减了 46%,从 4.49MB 缩减到 2.39MB,同时方法数也减少了17%

值得注意的是,在刚开始在应用中采用Compose时,有时您会发现APK大小反而变大了
这是因为迁移没有完成,老的依赖没有完成移除,而新的依赖已经添加了,导致APK体积变大
而在项目完全迁移到Compose后,APK 大小会减少,并且优于原始指标。

代码行数

我们知道在比较软件项目时,代码行数并不是一个特别有用的统计数据,但它确实提供了对事物如何变化的一个观察指标。
我们使用cloc工具来计算代码行数

cloc . --exclude-dir=build,.idea,schemas

结果如下图所示:

p4.png 可以看出,在迁移到Compose后,毫无意外的,XML代码行减少了76%
有趣的是kotlin代码同样减少了,可能是因为我们可以减少很多模板代码,同时也可以移除之前写的一些View Helper代码

构建速度

随着项目的不断变大,构建速度是开发人员越来越关心的一个指标。
在开始重构之前,我们知道,删除大量的注解处理器会有助于提高构建速度,但我们不确定会有多少。

我们运行以下命令5次,然后取平均值

./gradlew --profile --offline --rerun-tasks --max-workers=4 assembleDebug

结果如下

p3.png
这里考虑的是调试构建时间,您在开发期间会更关注此时间。

在迁移到Compose前,Tivi 的平均构建时间为 108.71 秒。
在完全迁移到 Compose 后,平均构建时间缩短至 76.96 秒!构建时间缩短了 29%
构建时间能缩短这么多,当然不仅仅是Compose的功劳,在很大程度上受两个因素的影响:

  1. 一个是移除了使用注解处理器的DataBindingEpoxy
  2. 另一个是HiltAGP 7.0 中的运行速度更快。

运行时性能

上面我们介绍了Compose在构建时的性能,下面来看下Compose在运行时渲染的性能怎么样

分析前的准备

使用Compose时,可能有多种影响性能的指标

  • 如果我们完全在Compose中构建UI会怎样?
  • 如果我们对复杂视图使用Compose(例如用 LazyColumn 替换 RecyclerViews),但根布局仍然添加在XML
  • 如果我们使用Compose替换页面中一个个元素,而不是整个页面,会怎么样?
  • 是否可调试和R8编译器对性能的影响有多大?

为了开始回答这些问题,我们构建了一个简单的测试程序。
在第一个版本中,我们添加了一个包含50个元素的列表(其中实际绘制了大约 12 个)。该列表包括一个单选按钮和一些随机文本。

p5.jpeg
为了测试各种选项的影响,我们添加以下4种配置,以下4种都是开启了R8同时关闭了debug

  1. 纯Compose
  2. 一个XML中,只带有一个ComposeView,具体布局写在Compose
  3. XML中只包含一个RecyclerView,但是RecyclerView的每一项是一个ComposeView
  4. XML

同时为了测试build type对性能的影响,也添加了以下3种配置

  1. Compose,关闭R8并打开debug
  2. Compose,关闭R8并关闭debug
  3. XML,关闭R8并打开debug

如何定义性能?

Compose运行时性能,我们一般理解的就是页面启动到用户看到内容的时间
因此下面几个时机对我们比较重要

  1. Activity启动时间,即onCreate
  2. Activity启动完成时间,即onResume
  3. Activity渲染绘制完成时间,即用户看到内容的时间

onCreateonResume的时机很容易掌握,重写系统方法即可,但如何获得Activity完全绘制的时间呢?
我们可以给页面根View添加一个ViewTreeObserver,然后记录最后一次onDraw调用的时间

使用Profile查看上面说的过程,如下分别为使用XML渲染与使用Compose渲染的具体过程,即从OnCreate到调用最后一次onDraw的过程

使用XML
使用Compose

渲染性能分析

知道了如何定义性能,我们就可以开始测试了

  1. 每次测试都在几台设备上运行,包括最近的旗舰、没有Google Play服务的设备和一些廉价手机。
  2. 每次测试在同一台手机上都会运行10次,因此我们不仅可以获取首次渲染时间,也可以获取二次渲染时间
  3. 测试Compose版本为1.0.0

我们根据上面定义的配置,重复跑了多次,得到了一些数据,感兴趣的同学可以直接查看所有数据

p8.png
分析结果如上图所示,我们可以得出一些结论

  • R8和是否可调试对Jetpack Compose渲染时间产生了显着影响。在每次实验中,禁用R8和启用可调试性的构建所花费的时间是没有它们的构建的两倍多。在我们最慢的设备上,R8 将渲染速度加快了半秒以上,而禁用debug又使渲染速度加快了半秒。
  • XML中只包含一个ComposeView的渲染时间,跟纯Compose的耗时差不多
  • RecyclerView中包含多个ComposeView是最慢的。这并不奇怪,在XML中使用ComposeView是有成本的,所以页面中使用的ComposeView越少越好。
  • XML在呈现方面比Compose更快。没有办法解决这个问题,在每种情况下,Compose 的渲染时间比 XML 长约 33%。
  • 第一次启动总是比后续启动花费更长的时间来渲染。如果您查看完整的数据,第一个页面的渲染时间几乎是后续的两倍。

比较让我惊讶的是,尽管Compose没有了将XML转化成ViewIO操作,测量过程也因为固有特性测量提高了测量效率,但性能仍然比XML要差
不过,根据Leland Richardson说法,当从Google Play安装应用程序时,由于捆绑的AOT编译,Compose 在启动时渲染会更快,从而进一步缩小了与XML的差距

总结

经过上面对Compose性能方面的分析,总结如下

  1. 如果完全迁移到Compose,在包体积,代码行数,编译速度等方面应该会有比较大的改善
  2. 如果处于迁移中的阶段,可能因为旧的依赖没有去除,而已经引入了新的依赖,反而导致包体积等变大
  3. 尽管没有了XML转换的IO操作,测量过程也通过固有特性测量进行了优化,Compose的渲染性能比起XML仍然有一定差距
  4. 尽管目前Compose在性能方面略有欠缺(在大多数设备上仅超过一两帧),但由于其在开发人员生产力、代码重用和声明式UI的强大特性等方面的优势,Compose仍被推荐使用

参考资料

Jetpack Compose — Before and after
Measuring Render Performance with Jetpack Compose

今天的文章相比 XML , Compose 性能到底怎么样?分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/16152.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注