相比 XML , Compose 的性能

构建性能

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

1. 第一步：迁移到Navigation与Fragment,每个Fragment的UI则由Compose构建
2. 第二步：移除Fragment，完全基于Compose实现UI

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

APK体积

包体积是我们经常关注的性能指标之一

Tivi 的 APK 大小缩减了 46%，从 4.49MB 缩减到 2.39MB，同时方法数也减少了17%

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

代码行数

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

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

结果如下图所示：

 

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

构建速度

随着项目的不断变大，构建速度是开发人员越来越关心的一个指标。 在开始重构之前，我们知道，删除大量的