Jetpack Compose

compose是android官方推出的声明式UI框架，其中最新版本的android studio中创建的empty project已经默认使用compose替代了原有的android view体系。可以看出对于android官方来说应该是把compose作为android未来原生主推的view体系，类似于kotlin的地位，所以个人认为紧跟官方的脚步学习探索一下compose是比较有必要的。

同时个人过去两年的工作和flutter保持强相关，也非常好奇这两款声明式UI框架有何异同。

个人compose认知

compose思想上与flutter基本一致，舍弃xml，所有的view用kt ”描述“ 出来，只不过对于flutter来说是用dart ”描述“。这个对于初次接触声明式UI的同学可能需要一段时间适应，因为这套体系需要你抛弃过往对Android VIew系统的使用观念，至少在UI这一层上是不互通的。需要用一种编写 ”配置“ 的思想进行编程，与其说在写代码，说自己在描述用户的UI需要什么配置可能更加恰当，这一点在flutter和compose上是一致的。

状态管理

这点是compose对比flutter最有优势的点——在compose推出之初就有官方较为成熟的状态管理方案Jetpack Compose 中的状态  |  Android Developers，有官方的最佳实践可以让开发者少走不少弯路。而flutter至今还没有一个官方较为成熟的状态管理方案，需要依靠社区的Provider或者bloc等第三方开发者贡献，一个全新的框架却没有一个合适的最佳实践是很容易跑歪的，开发者只能在坑中积累经验，这样一来新手就很容易写出非常垃圾的代码，而且flutter老手也很难说服初入坑的同学为什么某种写法会有大问题，因为你其实没有一个官方的论据去支撑你的论点，这点对于新引入flutter框架的同学来说应该有不少体会。

开发体验

compose采用直接在as上预览的方式”试图“提高开发体验，当然，对比起过去android view的构建方式，这个理论上是会带来更好的开发体验。但是对比flutter一键热更新就能在真机上体验最新的代码，compose的预览更新速度较慢，和“丝滑”不太搭边，而且要预览的话需要额外编写@Preview的测试代码，这个操作其实比较笨重，所以这里的 试图 是带双引号的。

控件管理

不同于flutter强制定义好有状态和无状态的widget，compose目前还是依靠开发者 “自觉” 去编写无状态widget，尽管有最佳实践的例子，但是这种依靠开发者自觉的东西我觉得都不可靠，不然kotlin也不会把所有类和方法默认final，需要开发者自己明确这玩意是要被继承或者重写才open，算是用一种强制的方法尽可能地让大家写出符合开闭原则的代码。compose这里如果妄想通过开发者自觉去实现无状态的控件可能真就有些痴心妄想了。

compose好处

说了这么多，感觉其实除了他有官方社区支撑做背书外，其他体验好像都不如flutter。但技术选型不止是看现状，也要看潜力。上述描述的缺点其实都能看到可优化的影子，并非都是不能解决的问题，尤其是有android官方做支撑。而且使用compose不止是对ui有影响，未来可能会有更多的机会和jetpack系列的产品联动，这是相当于使用了一整个生态圈的东西，和单一的flutter还是不同的。所以如果只是某个android端的应用，没有跨端需求的话，compose还是可以和flutter平分秋色，毕竟引入flutter搞路由栈这一套东西也够开发者喝一壶了。