asp网站301百度识图 上传图片
Compose 于2019年的 Google IO大会首次发布，当时感觉前景并不乐观，想推翻已存在10年之久的现有视图体系谈何容易，更何况将来与 Flutter 等同门兄弟的关系又该如何相处？
没想到时隔仅两年，本届 IO 大会上就宣布 Compose 1.0 即将到来。其实从年初 Beta 版的一系列造势活动就能看出 Google 在 Compose 推广上的决心之大，只要官方发力编程语言都可以短期内切换，更何况一个UI框架？ 所以不必怀疑， Compose 必将成为新的UI开发标准。
随着稳定版的到来，现在正是学习 Compose 的好时机。让我们借本次 GoogleIO 上的内容，了解一下 Compose 将为 Android 开发带来哪些变化
1. 为什么要用 Compose ？
Jetpack Compose is Android’s modern toolkit for building native UI.
这是官方对 Compose 的定义。通过与 Android 现有视图体系对比就能理解为什么 Compose 更加 “现代”
现有的 Android 视图体系从 2010年 以来没有发生太大变化，10年间无论从硬件规格还是 APP 复杂度都发生了极大变化，这套已经跑了10年的技术体系也已经显得有些落伍。
近年来，React等声明式框架的出现改变了前端的开发方式，Android 借鉴了 React 的思想为打造了用于 Native 开发的声明式UI框架 - Jetpack Compose。 使用 Compose 可以显著减少创建页面的时间，提高UI开发效率。
2. 声明式 VS 命令式
现行的 Andoird 视图体系属于传统的命令式开发方式，一般使用XML布局，而后通过 findViewById 获取控件的引用，命令式地更新状态、刷新UI。命令式的视图体系有以下特性：
- UI是可变的：控件接受命令后通过变化自身刷新UI
- UI持有State：控件的变化正是通过改变自身状态实现的
随着界面越来越复杂，控件越来越多，各控件 State 难以保持同步，UI显示不一致的Bug频发。我们的很多精力花费在了如何能准确且不遗漏地更新所有该更新的控件上。
声明式UI与命令式UI的特点截然相反，正好可以弥补命令式的缺陷：
- UI不可变 :
@Composable函数不返回任何可引用句柄，无法被外界改变。 - UI不持有State:
@Composable函数无法持有状态的，显示的数据都需要通过参数传入。
声明式UI以一个“纯函数”的方式运行，当 State 变化时函数重新执行刷新UI。
KeyPoint: Compose使用 @Composable 函数来构建UI可以更好地贯彻声明式UI的特点
3. 基于 Kotin 的 DSL
声明式UI需要有一个与之匹配的 DSL 语言做支持，例如 React 中的 JSX。在 Android 全面拥抱 Kotlin 的今天，基于 Kotlin 的 DSL 几乎是唯一选项，庆幸的是 Kotlin 语法优势使得其DSL足够强大和好用。
KeyPoint: 使用 DSL 组装 UI 的过程其实就是对 @Composable 函数的定义过程。
@Composable
fun MessageList(messages: List<String>) {Column {if (message.size == 0) {Text("No messages"）} else {message.forEach { message ->Text(text=messag)}}}
}
上面例子中 MessageList 是一个展示消息列表的UI组件， 参数 message 即展示的数据。DSL 让我们可以很直观地书写多层嵌套UI ，例如在 MessageList 中嵌套 Column、Text 等。
基于高级语言的 DSL 是图灵完备的。我们在构建UI的同时，同步添加逻辑：当没有消息时显示 ”NO message“ 。 这是 JSX 这类标记型的 DSL 所无法完成的。
当 message 发生变化时，MessageList 重新执行，这个过程叫重组（recomposition）。 Composee 的 UI 正是通过不断重组来实现刷新。
4. 高性能的重组
当数据变化时会触发重组，很多人担心大面积的重组是否会影响性能。
React 每次 render 会生成 VirtualDom，通过 diff算