原文地址：jakewharton.com/a-jetpack-c…
原文作者：jakewharton.com/
发布时间：2020年12月30日
我非常喜欢Jetpack Compose。在工作和个人事务之间，我有三个项目，每个项目都建立在它的基础上。它非常棒！目前我最大的问题是它的名字...
到目前为止，我最大的问题是它的名字......但这需要一些解释。欢迎来到我会死的山丘之一!
什么是Jetpack Compose?
如果你已经对它很熟悉了，当你被问到时，你的脑海中应该会出现一些东西。什么是Jetpack Compose?
一个全新的安卓系统的UI工具包？是的，没错。一个声明式的Android UI框架？当然，没错。一个多平台的应用UI？感谢JetBrains，这也是真的。
如果你对香肠的制作方式有点了解，你可能还会参考它是一个Kotlin编译器插件和DSL来构建Android UI或多平台UI。也就是这些东西。
这些答案都没有错。然而，他们对Compose的内部结构和它未被发掘的潜力有点不利。
血统
我们现在所知道的Jetpack Compose是作为两个独立的项目开始的。
第一个是使用现有的平台UI工具箱 编写声明式Android用户界面的解决方案。把React的声明式组件，用Svelte这样的超前编译器包裹起来，用Kotlin瞄准Android的UI工具包。所有现有的基于View的UI都可以通过将其编程范式从命令式转变为声明式来突然提升水平。
另外，工具包团队即将加紧将尽可能多的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相关。这棵树可以作为视图状态对象存在于presenter层，也可以作为模型对象存在于数据层，或者仅仅是一棵纯数据的值树。
Compose并不在意! 这是我真正喜欢的部分。这是很棒的部分。
不过，单独来说，Compose也是一个新的UI工具包和DSL，可以在Android和桌面上渲染应用。Compose的这部分是建立在上述核心之上的，作为一棵节点树，而这些节点恰好能够将自己渲染到画布上。
这两部分分别称为Compose编译器/运行时和Compose UI。
这种关注点的分离是非常受欢迎的。在我看来，将这两部分混同在Compose这个名字下是不受欢迎的。
命名
调整这里的命名可以解决两个问题：特殊性和鸽子群。
把一个通用的编译器和运行时与一个特定的UI工具包实现放在一个总名下，意味着关于它们的讨论本质上是不精确的。这篇文章一开始就说我正在做三个基于 Compose 的项目......你以为我说的是 Compose UI 吗？你几乎肯定是。
Compose这个名字更像是Jetpack而不是AppCompat。我们并没有这样对待它，也没有迹象表明Google会纠正我们的看法。所以，现在我必须无休止地澄清，我正在做三个基于Compose编译器/运行时构建的项目，这些项目并没有使用Compose UI工具包，哦，顺便说一下，是的，这些都是独立的东西。
也许你不认为这是一个足够好的理由来拥有两个名字。毕竟，有多少人会只靠编译器和运行时来构建一些东西呢？
然而，这就更应该给它重新命名了。你只是把这个项目束之高阁，让它不可能成为更多的东西--一个很酷的技术，而 Compose UI 就是建立在这个技术之上的。通用的 Compose 编译器/运行时可能的应用是广泛的，应该得到鼓励。现在感觉就像Google埋下了伏笔。
一个单独的名字是一个简单的方式来吸引人们对伟大工作的关注，这就是Compose的编译器和运行时。有关于它的罕见的推特，在演讲中偶然提到，偶尔有博客文章展示不同的用途，但除此之外，没有太多的呼吸空间。围绕Compose UI的兴奋（这也是当之无愧的）将其淹没。
Compose编译器/运行时比Compose UI支持更多的平台和目标。除了Android之外，我还在JVM上运行过基于Compose的项目（在服务器上，而不是在桌面上），并在非浏览器的JS引擎中瘸了一个。这些地方，Compose UI是不可能的，但Compose不是!
我很高兴我的这三个项目能够进入开源领域，以展示 Compose 编译器和运行时能够独立完成的任务。我并不为必须不断地澄清 Compose 编译器/运行时二重奏与 Compose UI 或 Android 无关而感到兴奋。
鹤
新UI工具包的内部代号是 "crane"。在它公开之前，我表示支持保留这个名字。在Compose公开后，我表示支持使用两个名字，Compose UI使用 "crane"。但聊天室里的留言很容易被忽略--即使有人同意。
不幸的是，很多时间过去了，茶叶显示Compose即将进入测试版。现在为Compose UI做这个命名的改变已经太晚了。甚至没有人叫它Compose UI。它一直都只是Compose。
因此，这篇博文是对Google的万福式恳求：请将编译器和运行时改名为别的名字吧!
反正 Compose 是个很平淡的名字。把它命名为Evergreen（像树一样）。命名为Juliet（写博客标题的人）。该死的，给它起个名字叫Crane（为了最大限度的内部混淆）。给它取一个它应得的不同名字，这样它就可以独立存在了。
但是，请不要把这个神奇的、通用的、多平台的编译器和运行时放在Compose这个空泛的命名法后面。
—— Jake Wharton
通过www.DeepL.com/Translator （免费版）翻译
