本文由个人翻译, 来源 Jake Wharton https://jakewharton.com/a-jetpack-compose-by-any-other-name/
我非常喜欢 Jetpack Compose. 我的工作和个人项目中有三个都是基于这个, 强的一笔.
到现在，有个关于这个含义的大问题，需要很多信息来表述. 欢迎来听其中一个我非常认同的观点.
什么是 Jetpack Compose
如果你早就熟悉这个，看到这个 "什么是 Jetpack Compose？"，你脑子里就会冒出些想法.
一个新的 UI toolkit for Android？ 没错.
一个申明式 Android UI framework？ 确实.
一个跨平台 multiplatform application UI？冇错，这得谢一下 JetBrains.
如果你对香肠的制作方式有所了解，你还可以提下面说法：它是一个 Kotlin 编译器插件和 DSL，用于构建 Android UI 或多平台 UI. 它也是这些东西.
这些回答都没有问题，但是这些说法对 Compose 发挥它的潜力有害.
由来
我们现在知道 Jetpack Compose 来源于两个独立的项目：
其中一个，是解决申明式 Android UI 用现有平台的 UI toolkit. 以 React 的声明式组件为例, 包装后运行前编译（像 Svelte 这样），用 kotlin 生成 Android UI toolkit. 所有现有基于视图的 UI 都可以通过将编程范式（Programming paradigm）从命令式更改为声明式来直接升级.
另一个，工具包团队迅速从操作系统中分拆尽可能多的 UI 小部件，这是继 ViewPager、RecyclerView 的成功，AppCompat 和 Design 库就是学的这个； 通过删除大量 OEM 接触点并规范所有 Android 版本的行为，减少构建优秀 UI 所要的工作量.
随时间发展，对这些项目努力不可避免地联系在一起.
如果你正在构建平台 UI 小部件的独立版本，那么为什么不借此机会纠正 API 中的错误并克服资源系统的局限？如果您要更改他们的 API，为什么不让新的声明式系统仅针对这些未捆绑的小部件？每个项目只有在彼此更加紧密地结合在一起时才会赋予彼此权力.
事后看来，它们似乎不可避免地会成为一项单一努力. 然而，单一努力并不一定意味着紧密联系.
分层
我在 Compose 上构建的三个项目都没使用新的 Compose UI 工具包. 即使对于那些做过许多 Compose 工作的人来说，这也可能是一个令人纳闷的说法. 我们不是说它们有着不可避免的联系吗？我们之前不是把它定义为 UI 工具包吗？
虽然 Compose 成为从两个项目开始的单一工作，但与原始项目类似的分层和责任划分仍然存在. 事实上，这种分离只会变得更加明确.
这意味着 Compose 的核心是一个用于管理任何类型的节点树的通用工具. "节点树"几乎可以描述任何事物，因此 Compose 可以针对任何事物.
这些树节点可能是新的 Compose UI 工具包内部结构. 但它也可能是 ViewGroup 树中的旧 View 节点，也可能是 RemoteView 及其树中的各种远程视图，或者是通知及其中的内容.
节点根本不必与 UI 相关. 该树可以作为视图状态对象存在于表示层，作为模型对象存在于数据层，或者只是简单的纯数据的数值树.
Compose doesn't care! 这是我真正喜欢的部分. 这很强.
不过，Compose 也是一个新的 UI 工具包和 DSL，可在 Android 和桌面上呈现应用程序. Compose 的这一部分构建在上述核心之上，作为节点树，这些节点能够将自身渲染到画布上.
这两部分分别称为 Compose 编译/运行时和 Compose UI.
命名
调整此处的命名将解决两个问题：特异性和分类.
将通用编译和运行时与特定 UI 工具包实现放在一个总称下意味着对它们的讨论本质上是不精确的. 这篇文章首先说我正在开发三个基于 Compose 的项目......你认为我指的是 Compose UI 吗？你应该是这样想的.
Compose 名称更类似于 Jetpack，而不是 AppCompat. 我们不会这样对待它，也没有迹象表明谷歌会纠正我们的看法. 所以现在我必须不断地澄清，我正在开发三个基于 Compose 编译器/运行时构建的项目，它们不使用 Compose UI 工具包，顺带强调下, 这些是不同的事情.
也许你认为这拥有两个含义的理由不够充分. 毕竟，有多少人会仅在编译器和运行时上构建某些东西呢？
但这正是重命名它的理由！你刚刚将该项目归类为它已经是一个很强的技术，Compose UI 就建立在它的基础上. 通用 Compose 编译器/运行时的可能应用很广泛，应该得到挖掘. 现在感觉谷歌淹没了它的才能.
单独的名称是吸引人们注意 Compose 编译器和运行时这一伟大工作的简单方法. 关于它的推文很少见，演讲中偶尔提到，偶尔也会有博客文章展示它的不同用途，但除此之外，没有太多的喘息空间. 围绕 Compose UI 的兴奋（这也是当之无愧的）淹没了它.
Compose 编译器/运行时支持比 Compose UI 更多的平台和目标. 除了 Android 之外，我还在 JVM 上运行了基于 Compose 的项目（在服务器中，而不是在桌面上），并且在非浏览器 JS 引擎中运行过一个项目. 这些是 Compose UI 不可能涉及的，但 Compose 却不是！
这三个项目能够开源我蛮高兴，来展示 Compose 编译器和运行时可以做什么. 但对必须不断扯 Compose 编译器/运行时组合与 Compose UI 或 Android 无关这一点很没劲.
代号
新 UI 工具包的内部代号是 "crane". 在公开之前，我表示支持保留该名称. Compose 公开后，我表示支持使用两个名称并使用 "crane" 作为 Compose UI. 但聊天室中的消息很容易被忽略------即使有些人同意.
坑爹的是，蛮久了，茶叶已舒展开 Compose 即将进入测试阶段.
因此，这篇博文是对 Google 的强烈恳求：将编译器和运行时重命名为其他名称！
无论如何，Compose 是一个平常的名字. 将其命名为常青树（就像树木一样）. 将其命名为朱丽叶（博客标题的作者）. 但把它命名为 Crane 非常受不了（只会有内部更加混乱）. 给它一个它应得的不同名称，这样它就可以独立存在.
But please, don't relegate this amazing, general-purpose, multiplatform compiler and runtime to live behind the blanket nomenclature that is just Compose!
但是，请不要将这个强的一笔的通用多平台编译器和运行时能力，被命名耽搁！
译者注
如果你对香肠的制作方式有所了解 可能是作者的一种比喻, 形容只吃香肠，不管这个香肠的制作
命令式更改为声明式 设计思想，声明式UI 更注重描述界面的最终展现是怎么样的，而不关注如何实现它；命令式UI 则更加关注实现的具体步骤和过程. 其次就是代码风格，声明式UI 使用更抽象、更高级的语法，通常使用配置、声明或描述来构建用户界面；命令式UI 更侧重于编写详细的指令和操作来控制用户界面的构建和交互
茶叶已舒展开 原文 and the tea leaves are showing that Compose is about to enter beta 可能指的是观察泡好的茶叶展开情况，以茶快泡好了，来形容进度