共计 2892 个字符，预计需要花费 8 分钟才能阅读完成。
为了让 Jetpack Compose 的应用体验更上一层楼，以及理解大家对 Compose 开发、学习方面的内容需要，这里诚邀您参加 Jetpack Compose 应用状况调研, 点击这里 即刻参加调研。
作者 / Google Play 技术负责人 Andrew Flynn 和 Jon Boekenoogen
2020 年，Google Play 商店开发团队管理层做出了一个重大决定: 革新整个 Play 商店技术栈。因为现有代码的历史曾经长达 10 多年，在有数的 Android 平台版本公布和性能更新的过程中产生了微小的技术负债。咱们须要新的框架，在不影响 开发者的工作效率、用户体验或 Play 商店本身性能 的同时，可能撑持数百名工程师同时发展工作。
咱们为此制订了一个长期路线图，来更新商店内从网络层始终到像素渲染的所有内容。在这之中，咱们还想要采纳古代的申明式界面框架，以实现咱们围绕交互性和用户满意度的产品指标。在剖析了各种抉择后，咱们做出了 (在过后) 一个大胆的决定——应用过后还处于 Alpha 预览阶段的 Jetpack Compose。
从那时起，Google Play 商店与 Jetpack Compose 团队密切合作，公布并欠缺了满足咱们特定需要的 Jetpack Compose 版本。本文将为您介绍咱们的迁徙办法以及在此过程中发现的挑战和劣势，并分享一些对于有泛滥贡献者的利用抉择 Compose 的洞察。
优先思考
当咱们对新的界面渲染层应用 Jetpack Compose 时，须要优先思考以下两点:
- 开发者的工作效率 : Play 商店团队有数百个工程师改良代码，因而开发起来应该很容易 (也很乏味)。
- 性能 : Play 商店会渲染大量媒体密集型内容，其中很多业务指标对提早和卡顿非常敏感，所以咱们须要确保它在所有设施上体现良好，尤其是低内存硬件和 Android (Go 版本) 设施。
开发者的工作效率
一年多来，咱们始终在应用 Jetpack Compose 编写用户界面代码，也得益于 Jetpack Compose 让界面开发变得更加简略。
咱们偏向于 编写界面时应用更少的代码，有时甚至能够缩小 50%。此项改良的实现得益于 Compose 是一个利用了 Kotlin 简洁性的申明式界面框架。自定义绘图和布局当初是简略的函数调用，而不必再通过对视图子类进行各种复写。
以评分表格为例:
应用视图类编写，此表格蕴含:
- 总共 3 个视图类，其中 2 个须要自定义绘制圆角矩形和星形
- 约 350 行 Java 代码，55 行 XML
应用 Compose 编写，此表格蕴含:
- 所有的 @Composable 函数都蕴含在同一文件和语言中！
- 约 210 行 Kotlin 代码
动画
动画因其简略、富裕表现力而成为 Compose 备受赞美的一项性能。咱们的团队正在应用 Compose 构建动效性能，极大地提高了 Play 商店用户的满意度。借助 Compose 的申明性和动画 API，编写间断或并行动画从未如此简略。咱们的团队不再放心对于动画勾销和回调链的所有极其状况。Lottie 是一个风行的动画库，曾经提供了易于应用的 Compose API。
您能够观看《动画成为 Compose 备受赞美的一项性能》视频理解更多无关应用 Compose 构建动画的信息。
当初您可能会想: 这所有听起来都很棒，但提供视图的库依赖项呢？的确，并非所有的库开发者都实现了基于 Compose 的 API，尤其是在咱们首次迁徙时。然而，Compose 通过其 ComposeView 和 AndroidView API 提供了 简略的视图互操作性。咱们以这种形式胜利地与 ExoPlayer 和 YouTube Player 等风行库集成。
性能
Play 商店和 Jetpack Compose 团队密切合作，以确保 Compose 能够像视图框架一样疾速运行并且没有卡顿。因为须要把 Compose 打包在利用中 (而不是作为 Android 框架的一部分)，这是一项艰巨的工作。在屏幕上渲染单个界面组件很快，然而将整个 Compose 框架加载到利用内存中所用的端到端工夫却很长。
Play 商店采纳 Compose 后最大的性能改良之一来自 基准配置文件 的开发。尽管曾经推出了一段时间的 云配置文件 能够帮忙改善利用启动工夫，然而它们只实用于 API 28+，且对于更新节奏频繁 (每周) 的利用成果不佳。为了解决这一问题，Play 商店和 Android 团队合作开发了基准配置文件 (Baseline Profiles): 开发者预约义打包好的、利用能够指定的一个配置文件，它们随您的利用提供，与云配置文件齐全兼容，并且能够在具体利用级别和库级别进行定义 (适配 Compose 的开发者可收费应用此性能！)。通过推出基准配置文件，Play 商店发现其搜寻后果页的 初始页面渲染工夫缩小了 40%。这是微小的提高！
重复使用界面组件 是使 Compose 在渲染方面表现出色的 外围机制，尤其是在滚动状况下。Compose 会尽可能跳过已知能够跳过的可组合项的重组 (例如，它们是不可变的)，然而如果所有参数满足 @Stable 正文要求，开发者也能够强制将可组合项设置为可跳过。Compose 编译器还提供了一份 便捷指南，阐明避免特定函数被跳过的原理。当在 Play 商店中创立在滚动状况下频繁应用的大量重复使用界面组件时，咱们发现不必要的重组会减少失落的帧工夫，从而导致卡顿。咱们建设了一个 修饰符 (Modifier)，以便在咱们的调试设置中轻松发现这些重组。通过将这些技术利用于咱们的界面组件， 咱们可能将卡顿缩小 10-15%。
△ 实际操作中的重组可视化修饰符 (Modifiers)蓝色 (无重组)，绿色 (1 次重组)
为 Play 商店利用优化 Compose 的另一个要害是 为整个利用制订具体的端到端的迁徙策略 。在最后的集成试验中，咱们遇到了双栈问题: 在单个用户会话中同时运行 Compose 和视图类渲染十分占用内存，尤其是在低端设施上。当代码在同一页面上运行时就会呈现这种状况，当两个不同的页面 (例如，Play 商店主页和搜寻后果页) 各自位于不同的堆栈上时，也会呈现这种状况。为了改善这种启动提早，咱们 为页面迁徙到 Compose 的程序和工夫安顿 制订一个具体打算，这是十分重要的。同时咱们发现，在利用迁徙到齐全应用 Compose 进行渲染应用之前，对一些通用类进行肯定的 “ 预热 ” 是有助于进步内存性能的。
将 Compose 从 Android 框架中分离出来缩小了咱们团队间接为 Jetpack Compose 做出奉献的开销，从而缩短了改良工作的周转工夫，使所有开发者受害。咱们与 Jetpack Compose 团队单干，推出 LazyList 我的项目类型缓存 等性能，并疾速进行轻量级修复，如 额定的对象调配。
展望未来
Play 商店采纳 Compose 后，晋升了咱们团队开发者的幸福感，并 大大提高了代码品质和衰弱度 。所有的全新 Play 商店性能都建设在此框架之上，且 Compose 有助于为利用实现更快的速度和更顺畅的拜访。因为咱们 Compose 迁徙策略的性质，咱们无奈精确掂量 APK 大小 变动或构建速度等，然而咱们看到的所有迹象都十分踊跃！
Compose 是 Android 界面开发的将来，也帮忙 Play 商店实现了进一步的优化。欢迎您继续关注 咱们理解最新内容。