共计 3756 个字符，预计需要花费 10 分钟才能阅读完成。
为了蕴含 Jetpack Compose 1.0.0-beta05 的更新内容，这篇文章在第一次公布后做出了更新 。如果您心愿查看 原始版本，请点击 这里。
2020 年，我开始了迟缓迁徙 Tivi UI 的工作，指标是使其转为由 Jetpack Compose 编写。大概 12 个月之后，工作实现！🎉
在本文中，咱们将会回顾并比照一些要害指标，以理解 Compose 绝对的劣势，其中包含: APK 大小、构建速度、代码行数。
利用自身
在咱们进一步理解 Compose 的相干内容前，先让我疾速地形容一下利用自身。
Tivi 曾经高度模块化，它每个 UI 的 界面 都在其本身的 Gradle 模块中 (名为 ui-$NAME)。每个界面都应用 Fragment 实现，随后在主 app 模块中应用 AndroidX Navigation 将它们联合起来。为了让您对架构有一个直观印象，上面是利用的模块图:
△ Tivi 的模块图，应用 Jake Wharton 所提供的，非常不便的 Gradle 工作 生成
因为导航图应用 深度链接 URI 实现，大多数 Fragment 彼此之间无所不知，从而保障理解耦。或者更为重要的是，这种模式反对独立模块编译，从而有助于进行并行构建。
留神: Tivi 的模块构造并不完满。其中，UI 模块 (位于顶层) 与根底模块 (位于底层) 间仍有许多依赖。现实状况下，每个层级该当放弃拆散。我接下来的工作正是要优化这一问题。
在开始迁徙至 Compose 之前，Tivi 曾经应用了 Android 开发者能够应用的所有炫酷 UI 组件，包含但不限于: Data Binding、Epoxy、Material Design Components、Insetter DBX、MotionLayout。但可怜的是，其中的许多组件应用了注解解决，因此也带来了额定的构建耗费。
迁徙流程
后面我曾提到，咱们曾经实现了迁徙的 “ 第一幕 ”，这话是什么意思呢？当初的利用看起来与我在 2020 年二月开始迁徙时别无二致。
利用的模块化象征它能够分片实现迁徙，每次只用迁徙一个 Fragment——而这也是近 11 个月以来 46 个拉取申请 中所做的事。
我从一个简略的界面: 剧集详情 开始迁徙，接下来是 上演详情、” 发现 ”、” 搜寻 ”、” 关注的上演 ” 等等。最近在 Paging3 反对了 Compose 后，我迁徙了最初的界面: “ 列表 ” 网格:
△ 迁徙前后，Tivi 中展现视频的成果
利用迁徙的第一个阶段应用了 Fragments 与 Navigation，同时每个 Fragment 的 UI 应用了 Jetpack Compose 实现。
第二个 (也是最初一个) 阶段是从 Fragment 迁出，并间接应用 Navigation Compose 组件。这一步在 这个 PR 中实现。
迁徙的过程对我来说轻而易举，毫无疑问 Compose 便是 Android UI 开发的将来。
上面，让咱们看看具体指标… 📊
指标
针对下列的每一个指标，咱们都比照了利用的三个不同版本:
- 接入 Compose 前 : 回到 2020 年 2 月，这是我为 Tivi 增加 Comepse 反对的第一个 PR 公布 之前 的 提交。
- Fragments + Compose : 此版本所基于的 提交，被标记为迁徙第一阶段的结尾。我检出了新的分支，并将 Jetpack Compose 更新到 1.0.0-beta05、AGP 更新到 7.0.0-alpha14、Gradle 更新到 7.0 以及 Kotlin 更新到 1.4.32，以缩小比拟中的不确定因素。您能够在 本分支 中看到相干的代码。
- 齐全接入 Compose : 这一版本应用了以后最新的主 提交。此时的 Tivi 曾经齐全基于 Compose (版本 1.0.0-beta05) 了，同时在整个利用中都没有 Fragment。
APK 尺寸缩减 🗜
您的用户最为关怀的指标，莫过于 APK 大小。
上面是开启了 资源缩减 的最小化公布版 APK (应用了 R8) 通过 APK Analyzer 所测量的后果:
△ 展现 Tivi APK 大小的图表
△ 展现 Tivi 办法数的图表
对于上述数字的阐明:
- 咱们应用了 APK Analyzer 报告的 “APK file size” (而不是下载时的大小)。
APK 大小剖析
在将迁徙后的利用与接入 Compose 前的利用做比拟后，咱们发现 APK 大小缩减了 41%，办法数缩小了 17%。
在应用了 Compose 后，咱们发现 APK 大小缩减了 41%，办法数缩小了 17%
这一数字表明，当您须要保留所有 View 类，以防呈现须要在布局文件中应用它们的状况时，压缩工具的作用非常无限。
代码行数 📜
我晓得在比拟软件我的项目时，计算源代码行数不是特地有用的统计形式；但这种形式可能提供一个视角，帮忙咱们理解事物是如何变动的。
为了进行测试，我应用了 cloc 工具。应用上面的命令能够排除各种构建文件、主动生成文件以及配置文件。
cloc . --exclude-dir=build,.idea,schemas
△ 展现 Tivi 源代码行数的图表
cloc 内建反对疏忽正文的性能 (尽管我没有进行验证)，因而下面的后果实用于理论的 “ 代码 ”。毫不意外的，XML 行数大幅缩小了 76%。再见了，布局文件，以及 styles、theme 等其余的 XML 文件👋。
乏味的是，Kotlin 代码的总行数也降落了。我对此景象的了解是，当初利用中的模板代码缩小了，同时咱们也得以移除大量的视图辅助类和工具类代码。您能够看到，我在 这个 PR 中删除了多年来编写的近 3,000 行代码。
构建速度 ⏳
构建速度是开发者们十分关心的一项指标。在开始解决之前，我感觉移除大量的注解处理器有助于晋升构建速度，但我不确定能晋升多少。
测试设置
在进行下一步前，很重要的一点是要晓得我是如何测量出上面的数字的。我遵循了与 Chris Horner 测量 不同 CPU 上的构建工夫 时相似的设置。
我在一台 Lenovo P920 上进行测试，它领有 192GB RAM 和速度极快的 Xeon Gold 6154 CPU。不必多说，我晓得这台机器不是开发者的通常配置，所以为了使测试尽量真切，我将 CPU 固定在了其最小的时钟频率上:
# 应用调频器的 performance 调速器来更改最大运行频率
sudo cpupower frequency-set -g performance
# 将最大频率设定为 CPU 的最低值：1.2GHz
sudo cpupower frequency-set -u 1.2GHz为了筹备所有的近程缓存文件，接下来我运行了 ./gradlew assembleDebug。
为了执行测试，我循环运行了下列命令五遍:
./gradlew --profile \
--offline \
--rerun-tasks \
--max-workers=4 \
assembleDebug这里并不一定须要配置
--max-workers，但这里如果不设置，Gradle 会应用该 CPU 默认可用的所有 64 个外围。限度到 4 个更靠近典型的笔记本电脑 CPU。
后果
您能够在上面看到后果，每个后果都应用了后果报告中的 “ 总构建工夫 (Total Build Time)” 值。
△ 展现 Tivi 构建工夫中位数的图表
这一后果令我有些惊奇，因为 “ 齐全接入 Compose” 比 “ 在每个 Fragment 中应用 Compose” 快了 25 秒。
感激 Ivan Gavrilović 找出起因。这一景象与 Compose 无关。” 齐全接入 Compose” 应用的是最新版本的 Dagger/Hilt，该版本应用了 Android Gradle Plugin 7.0 中的新 ASM API。而其余版本应用了较旧的 Hilt 版本，其应用了不同的机制，会重大拖慢生成 dex 文件的工夫。
退一步讲，思考到 Kotlin 编译器与 Compose 编译器插件为咱们所做的事件，如地位记忆化、细粒度重组等工作，构建工夫可能 缩小 29%， 能够说非常惊人。您能够查看咱们公布的文章来理解更多:
- 深刻详解 Jetpack Compose | 优化 UI 构建
- 深刻详解 Jetpack Compose | 实现原理
注意事项
对于下面的所有后果，有些事项须要留神:
与新性能相干工作
在这 11 个月中，我没有在 Tivi 上进行过重大的新性能开发，但我也没有刻意限度本人。我进行了许多无关乎迁徙的批改，可能会使后果产生偏差。
依赖更新
在这 11 个月的迁徙过程中，许多依赖都更新了。其中的大多数均为运行时依赖库，因而最有可能影响 APK 大小这一指标。
我也更新了 Gradle (从 6.0.1 到 7.0.0)、Android Gradle Plugin (3.6.0 到 7.0.0-alpha14) 以及 Kotlin (1.3.61 到 1.4.32)，这些更新都可能大幅影响构建速度。
Compose 仍处于 beta 阶段
这点是最为不言而喻的。Compose 目前仍处于 beta 阶段，所以所有的后果均来自开发过程中一个适时的快照。当今年晚些时候达到 1.0 版时，能够从新运行这些测试，并比照产生了哪些差别。
总结
如果咱们看了后果和注意事项，就应该留神到咱们并没有把 🍎 与 🍏 做比拟，而更像是在拿 🍎 与比它甜了点的亲戚 🍐 进行比拟，因而也不应该做出太多评估。
把水果类比放在一边，我感觉对我来说最大的播种，是 Compose 对于大多数开发者指标产生的影响是踊跃 (或中性) 的。思考到这一点，再加上 Compose 大大提高了开发人员的生产力，对我来说，Compose 无疑是 Android UI 开发的将来。
感激 Nick Butcher、Jose Alcérreca 和 Jolanda Verhoef。
