节选自：对Jetpack Compose设计的初步解读与思考
Jetpack Compose前段时间进入了Alpha阶段。经过去年年底至今剧烈的api变化后，现在Compose整体上大致稳定，所以我们也能对于Compose的设计进行初步的解读和评价了。
Compose从整体技术风格上来说是这样一个产物：在语法上激进模仿SwiftUI，编译/运行过程充满Svelte风格，同时也综合了各方包括Android开发组自身对UI框架的思考结果。
使用Compose时，最值得关注的就是Compose的编译器插件。可以这么说，Compose的runtime、api都是依附于编译器插件的，那个巨大而无所不包的编译器插件才是Compose的本体。Compose插件强势的入侵了原版Kotlin的语法，导致包含了Compose的Kotlin基本上可以算作新语言（算成个新虚拟机都不过分）。初次了解的时候确实让我很困惑，因为这与React，Flutter推崇的趋势简直是背道而驰。但是了解了Svelte，SwiftUI之后，Compose显得没有那么突兀了。
Svelte
Svelte试图解决的问题是：如何用声明式的代码书写风格，一对一直接翻译成纯粹命令式的DOM操作，从而达到无额外开销+极小runtime的效果。最终Svelte选择发明一套自制的模板语法来翻译到Javascript上。这个好理解，因为大家很熟悉，显然javascript以及其工具链没有任何实现这个目标的可能。
Compose
Compose在框架设计方面的野心明显超越Flutter。Compose团队多次表示Compose就是对Android SDK的重写。Compose对自身的定位估计类似于SwiftUI在苹果系生态中的定位，那就是高层次、生态内通用、外加依靠自身定位尽可能挖掘以及定制工具链以实现先进的开发模式。Compose使用了语法上和Swift神似的Kotlin，也面临相似的问题，于是Compose（出于一些原因）选择了简单粗暴的魔改Kotlin编译器（而不是模仿SwiftUI玩类型系统杂耍）。
Compose团队解释过Compose的出发点：构建一个通用的、描述树状结构渲染过程的框架，不管是是手机UI组件树或者是浏览器HTML Element。
Compose一不做二不休，直接把Kotlin编译器魔改到底。最后利用编译器魔改实现了几大功能。
对Compose设计的思考
目前Compose的官方资料仍然较为缺乏，因此很难知道Compose除此之外的优化设计以及runtime具体调度机制。但总体来说，我认为
- Compose的编译期优化潜力较为巨大，在未来完全有实现SwiftUI所有编译期优化的潜力，尽管没有使用类型系统可能会导致某些实现更为困难。
- Compose对于原版Kotlin的强势侵入是其得以实现设计目标的重要原因。但也是一个隐患，Compose对语义的入侵过深，我们可以看看Compose的编译器可能会干什么事情
- 对每个树的节点，按照源代码位置，生成一个唯一的int型ID
- 插入start和group来表明节点的边界
- 收集向函数传递的参数，参数的性质
- 根据收集的信息指导一个指令机的工作，那个指令机工作在一个无类型的纸带上
这个已经可以算作在Kotlin/JVM上重新发明了一个虚拟机了。结构化的执行流程，内存，ABI，call site，复杂的调度策略都有了，我觉得就差来个人来证明能跑操作系统了。在已经因为DSL特性高度特化的Kotlin语言上继续发明新虚拟机，总归是有点奇怪的事情。与此对比，SwiftUI对语言的入侵很少而且是隐式的。
- 作为未来取代Android SDK的候选者，有强烈的风格取向，opinionated。为了实现对树状渲染结构“通用”的描述，Compose捆绑了一整套非常新的解决方案，从Positional Memoization，到安卓上第xxxxxxx个响应式数据解决方案@State（目前仍然缺乏资料以证明其通用性）。好是好，但是Angular前车之鉴在那里。公平的来说，SwiftUI也是强烈的风格取向，但SwiftUI在苹果生态中的地位个人觉得谷歌没法在Compose上复刻。而且加上强势侵入原语言语义，一旦要调整估计就要大调整。
- Compose大量功能处于编译器层，导致这些功能其实是没办法灵活调节的。Flutter我觉得官方的xxx不好还可以自己重写一个发布出去，才有了一堆群魔乱舞的东西，engine虽大但除了engine以外都可以自己写。Compose感觉很容易就会碰到编译器层。
- Compose由于基于编译器，很多的优化都是类似于编译器过一个pass的模式来的，尤其是Diff和常量消除那些地方，比较细碎，不容易归档解释，给人一种“想到哪里写到哪里”的感觉，目前官方的文档就有很多这种问题。
- 总之，非常期待以后真正理想的“通用”编程语言配上先进的前端框架。也许就是swift加上MPS。