Flutter 与 Compose 应该怎么选择？它们冲突吗？
没用的前言
其实自从 Jetpack Compose 面世以来，关于 Flutter 与 Compose 之间的选择问题就开始在 Android 开发中出现，就如同之前有 iOSer 纠结在 Flutter 和 SwiftUI 之间选谁一样，对于 Android 开发来说似乎“更头痛”的是 Flutter 与 Compose “同出一爹”。
image
本来关于这个话题没什么好写的，因为这个话题属于“吃力不讨好”的类型 ，毕竟被原生开发看到了，可能就有人就要痛批我：
“是我 Andorid 提不动刀了，还是这些一两年的’小框架‘飘了，搞不好我们再等等它们就都凉了，你整天就知道’贩卖焦虑’收割流量。”
但是看你们讨论得热火朝天，加之时不时要回答类似的问题，实在憋不住了，所以最终还是选择“冒死”输出一波，从我的观点来介绍它们之间的关系和如何选择。
image
当然，有人说我都不选不行吗？当然可以，因为在目前阶段 Flutter 和 Compose 都不影响你的 Android 开发地位，它们最多只是属于竞争工具。
Flutter 和 Compose 初衷
Flutter 和 Compose 的未来目标会比较一致，但是至少它们出现的初衷是不一样。
首先 Compose 是 Jetpack 系列的全新 UI 库，理解下这点！Compose 是 Jetpack 系列的成员之一，所以可以被应用到 Android 界面开发中，所以你也可以选择不用，用不用都能开发 Android 的 UI 。
然后再说 Compose 出生的目的：就是为了重新定义 Android 上 UI 的编写方式，为了提高 Android 原生的 UI 开发效率，让 Android 的 UI 开发方式能跟上时代的步伐。
不管你喜不喜欢，声明式的界面开发就是如今的潮流，不管是 React 、SwiftUI 、Flutter 等都在表明这一点。
而对于 Flutter 而言就是跨平台，因为 Flutter 没有自己的平台 ，有人说 Fuchsia 会是 Flutter 的家，但那已经属于后话，毕竟 Fuchsia 要先能养活自己。
因为 Flutter 出生就是为了跨平台存在的全新 UI 框架，从底层到上层都是“创新”和“大胆”的设计，就选择 Dart 本身就是一项很“大胆”的决定，甚至在 Web 平台都敢支持选用 Canvaskit 的 WebAssembly 模式。
所以 Flutter 的“任性”从一出来就不被看好，当然至今也有不看好它的人，因为它某种程度很“偏激”和不友好。
所以扯了那么多，总结下就是：
-
Compose 是 Android UI 的未来，现阶段你可以不会，但是如果未来你会继续在 Android 平台的话，你就必须会。
-
Flutter 的未来在于多平台，更稳定可靠的多平台 UI 框架。如果你的路线方向不是大前端或者多端开发者，那你不需要会。
对了，鸿蒙上也是有类似 Flutter 的实现，感兴趣的可以自己关注下。
image
Compose 和 Flutter 未来一致
虽然 Compose 和 Flutter 初始服务的对象并不一致，但是它们未来目标肯定是一致。
为什么这么说？《Jetpack Compose for Desktop: 里程碑1发布》 不就表明了这一态度么？ Compose 虽然只是作为 Jetpack 的一个 UI 子集，但是它设计的理念和架构本身就带有跨平台支持的潜力。
本质是 Compose 也是类似于一个编译器加上一个 Skia 的工作模式，这和 Flutter 没有什么区别，不说开发方式，仅从控件命名上 Flutter 和 Compose 就不会让你感觉陌生。
image
不说控件，就说这次 Flutter 2.0 更新中 Dart 1.12 的 null-safety 和 Kotlin 像不像？
所以回归到主题的另外一个问题， Flutter 和 Compose 冲突吗？
从立项的意义上看 Flutter 和 Compose 好像是冲突的，但是从使用者的角度看，它们并不冲突。
因为对于开发者而言，不管你是先学会 Compose 还是先学会 Flutter，对于你掌握另外一项技能都有帮助，相当于学会一种就等于学会另一种的 70%
从未来的角度看：
-
如果你是原生开发，还没接触过 Flutter ， 那先去学 Compose ，这对你的 Android 生涯更有帮助，然后再学 Flutter 也不难。
-
如果你已经在使用或者学习 Flutter ，那么请继续深造，不必因为担心 Compose 而停滞不前，当你掌握了 Flutter 后其实离 Compose 也不远了。
它们二者的未来都会是多平台，而我认为的冲突主要是在于动手学起来，而不是在二者之间徘徊纠结。
从现实角度出发：目前 Flutter 2.0 下的 Android 和 iOS 已经趋向稳定，Web 已经进入 Stable 分支，而 Macos/Linux/Win 也进入了 Beta 阶段，并且可以在 Stable 分支通过 snapshot 预览。所以从这个阶段考虑，如果你需要跨平台开发，甚至 PC 平台，那么优先考虑 Flutter 吧。
你选择 React Native 也没问题，说起来最近 React Native 的版本号已经到了 0.64 了😏
当然大家可能会关心框架是否有坑的问题，本质上所有框架都有坑，甚至网络因素都可能会成为你的痛点，问题在于你是否接受这些坑。
跨平台的背后本身就是“脏活”和“累活”， Flutter 的全平台之路很艰难，就像之前写的《解读 Flutter 全平台开发的误解与偏见》， 现阶段 Flutter 全平台更多只是噱头，只是提供了“多一种可能”的阶段。
最后还是要例行补充这一点：
跨平台之所以是跨平台，首先就是要有对应原生平台的存在， 很多原生平台的问题都需要回归到平台去解决，那些喜欢吹 xxx 制霸原生要凉的节奏，仅仅是因为“你的焦虑会成为它们的利润”。
聊点废话
说点“道理我都懂”的实话，本质是我们作为开发者，其实并不应该把自己归纳为于某种语言和特定的框架之下，我们现在被归纳在某个领域仅仅是因为工作需要，而对于未来我们的发展，其实更应该注重的是编程基础和动手能力。
我本身是通过 Weex 接触的 Vue ，也用过 uni-app 做个简单的小程序，用 React Native 开发过两端 App ，也用 Flutter 写过 Web ，甚至手贱地在 SpringBoot 上用 Kotlin 写 API。
所以在我眼中，现在客户端和前端之间的划分已经越来越模糊，我遇到不少 Android 开发写过小程序或者 Vue ，不少前端也通过 uni-app， RN 和 Flutter 在写 App ，这是很正常的趋势，因为平台成熟了，越成熟的平台就会开始和相近的领域融合贯通。
你想说“卷”也行，这种趋势会让一些简单、重复或者需要共享的内容通过跨平台来得到落地，我相信有的人不看好跨平台，但是它存在的场景确实有它关键的价值。
也许某些领域我的认识不是很深，但是在需要的时候我可以动手满足需求，甚至去深入探索一下，而我也有自己精通的领域，二次并不冲突。
当然你说我只想在某个平台深入研究有没有问题？那肯定没有问题，这是好事，因为精通某个领域本来就是非常好的一件事。
但是！对，我还是要说这个但是，因为很多时候精通某项技术，是需要业务场景去验证和推进的，如果不是大体量的业务场景，没有经历过各种极端的考验，很多时候所谓的精通只是表层精通。
为什么说这个？因为在交流过程中经常有一些人说：想要深入xxx去精通某项技术或者领域，但是最终还是“三过门而不入”。
最后的最后，我想说学习其实本身是一件长期投资的事情，我们追求“性价比”和“高回报”很正常，但是这和投资金融一样，如果一直想要通过“投机”来获利，那就要有做好韭菜的准备。
image
