很久没新写博客了，近来的新项目都是用 Flutter，或者是旧有原生项目上增加新功能，所以基本没啥机会用 Compose，虽然一直有拿 Compose 练手，终究不及实际项目开发来的好。终于最近用 Compose 写了一个公司的小项目，很大的感受就是和 Flutter 的布局开发很像，而且它的语法糖比起 Flutter 更加贴近函数式。这里就想写写关于 Compose 的一些内容，也没什么具体的技术点，可能算一篇杂谈。
Android Compose VS Flutter
这个问题在使用 Compose 开发经常会在脑海中出现，首先，它们俩太像了，都是声明式UI，出处都是 Google，都能跨平台。
当然 Compose 目前来说跨平台的能力 —— KPM，比起 Flutter略显稚嫩，毕竟生存之道不一样，Compose 一开始就是为了取缔 Android View 那种命令式编程框架而设计的全新 UI 框架，它的基本盘就是 Android；而 Flutter 貌似是一个没面世的 Fuchsia，它的基本盘就得是跨平台，不然没市场。
单从 Android 平台角度来看，Compose 是对 View UI 架构的重写，它的渲染机制还是 Android Framework 层的 Choreographer；而 Flutter 是完全脱离 Android Framework 层，自建的一套渲染机制。
所以 Compose 其实最底层的渲染机制没变，但是上层的架构通过 compose-complier <-> compse-runtime <-> compose-ui ，在 UI 编写形式上有了焕然一新的改变，官方在Compare Compose and View metrics 中提到会更有效率，比如：Compose 使用 recompose 可以很好的避免过度重绘和多次布局传递等问题。
在 Android中，Compose 和传统的 View 相比，个人认为其实带来的性能提升其实有限，使用传统的 View 只要写法上没大问题，基本性能应该相差不大，主要还是编程理念上带来的进化。
综上总的来说，Flutter 的普及动力是要强烈些的，Flutter 对于公司和团队的收益显然是要比 Compose 大的。
但是对于 Android 原生开发人员来说 Compose 也是很值得掌握的，由于平台的初衷不同，实现响应式编程背后的任务并发机制、状态管理机制还是很大不同的，需要花精力去学习，毕竟 Android 系统的市场存量是巨大的。
另一方面，Flutter 的跨平台特质，对于状态管理的框架的设计思想会来自各个平台，这一点和 Compose 比起来是完全不同的，Compose 的状态管理的设计来自官方，十分有借鉴意义，所以学习 Compose 进而与 Flutter 对比，就可以加深对状态管理设计的理解和精进。
并发机制
状态管理
（Gap buffer、slotTable、RememberObserver）
