在前不久的 Android Dev Summit '19 上，Jetpack Compose 终于发布了一个可直接获得的预览版。现在的版本还是 0.1.0-dev02，处于非常早期的版本，官方也再三强调非常有可能产生变化且无法用于生产环境。不过我认为这是简单了解一下 Compose 的好时机。有备而无患。

首先来了解一下现在尝试 Compose 所需要的环境：

1. Android Studio 4.0 Canary1
2. Kotlin 1.3.60-eap-25
3. minSdkVersion 21（也就是 Android 5.0）

为什么需要 Compose

Android 已经十年，设备的变化非常大，也涌现出很多心的开发技术和思想，但用来开发 UI 的工具却还依旧停留在十年前。不少控件已经过时而且背负了太多历史包袱，重新开始或许是更好的选择。

开发 UI 需要编写 XML 布局，通过代码加载，可能还需要通过 XML 来定义 style，为了编写一个界面要做的工作太多了。而且考虑到 Activity 和 Fragment，需要顾及的就更多了。如果要自定义一个 View，要做什么工作？我想“自定义 View”这几个字，都能吓退一批人吧。

并且大量 UI 工具与系统的版本绑定，新功能新修复无法及时让开发者和用户受益。Material design？Who cares？那是 5.0 以上才大部分支持的东西，更别提 shape theming 了。

原先的控件使用了一些只有官方能使用的黑魔法，也就是 hidden API。Compose 将完全在公开的 API 上进行构建，官方使用的广大的普通开发者也能够使用。

插点私货。我偶尔会看着隔壁 Flutter 流下羡慕的泪水。它提供了大量官方的控件，应对各种场景，而且在各种系统版本上提供统一的行为。而我却需要满世界找非官方的实现，一个个查看是否满足我的需求，是否还在维护，是否需要自己魔改。当然，我无比感恩这些开发者的贡献，但我觉得我们应该被 Android 官方善待。

然后是 data flow。对于 UI 编程来说，分发事件和接收状态是与开发者关联最密切的事情。而现有的 android.widget 在这两个方面都做得不够好：状态的管理比较混乱；事件在分发时就已经改变了控件的状态；listener 可以跟 Kotlin 结合更紧密提供更合适的做法。

声明式 UI 编程

声明式编程通常是相对于命令式编程（imperative programming）来说的，不关注编程中具体的过程，而是以最后的结果为重点。在 UI 这一特定的领域来说，声明式编程则意味着：当状态发生变化时，声明式框架会自动更新视图。

声明式的 UI 框架会关注：

1. 对于给定的数据，UI 是如何被展示的；
2. 怎么对事件进行响应；
3. 不考虑 UI 之前的状态对当前的状态产生的影响。

也就是说，它只关心当前的数据（状态）会渲染出什么样的外观，而不把数据当成一个拥有上下文的状态流来看待。

总结

再次强调，Compose 处于很早期的阶段，API 也好，具体的底层实现也好，都很可能会发生变化。官方的示例 JetNews 也存在一定的性能问题。

所以我觉得普通开发者还不需要去了解具体使用的细节。但还是有几个建议：

• 如果还没学习 Kotlin，快学吧。
• 然后考虑学习一下 Kotlin coroutine。
• 学习已经比较成熟的声明式 UI 框架，比如 React 和 Flutter。考虑了解一下它们的应用和原理，比如状态管理的最佳实践和 virtual DOM 等。这样可以快速掌握同类型的 UI 框架。

链接：https://pan.baidu.com/s/1_4PIUb-Yl68aTW9Bw95iJA
提取码：tnav