Flutter 与 Compose 应该怎么选择?它们冲突吗?

没用的前言

其实自从 Jetpack Compose 面世以来,关于 Flutter 与 Compose 之间的选择问题就开始在 Android 开发中出现,就如同之前有 iOSer 纠结在 Flutter 和 SwiftUI 之间选谁一样, 「对于 Android 开发来说似乎“更头痛”的是 Flutter 与 Compose “同出一爹”」

本来关于这个话题没什么好写的, 「因为这个话题属于“吃力不讨好”的类型」 ,毕竟被原生开发看到了,可能就有人就要痛批我:

「“是我 Andorid 提不动刀了,还是这些一两年的’小框架‘飘了,搞不好我们再等等它们就都凉了,你整天就知道’贩卖焦虑’收割流量。”」

但是看你们讨论得热火朝天,加之时不时要回答类似的问题,实在憋不住了,所以最终还是选择“冒死”输出一波,从我的观点来介绍它们之间的关系和如何选择。

当然,有人说我都不选不行吗?当然可以,因为在目前阶段 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 平台都敢支持选用 CanvaskitWebAssembly 模式。

所以 Flutter 的“任性”从一出来就不被看好,当然至今也有不看好它的人,因为它某种程度很“偏激”和不友好。

所以扯了那么多,总结下就是:

  • 「Compose 是 Android UI 的未来,现阶段你可以不会,但是如果未来你会继续在 Android 平台的话,你就必须会。」

  • 「Flutter 的未来在于多平台,更稳定可靠的多平台 UI 框架。如果你的路线方向不是大前端或者多端开发者,那你不需要会。」

对了,鸿蒙上也是有类似 Flutter 的实现,感兴趣的可以自己关注下。

3

Compose 和 Flutter 未来一致

虽然 Compose 和 Flutter 初始服务的对象并不一致,但是它们未来目标肯定是一致。

为什么这么说? 《Jetpack Compose for Desktop: 里程碑1发布》 不就表明了这一态度么? 「Compose 虽然只是作为 Jetpack 的一个 UI 子集,但是它设计的理念和架构本身就带有跨平台支持的潜力」

本质是 Compose 也是类似于一个 「编译器加上一个 Skia 的工作模式」 ,这和 Flutter 没有什么区别,不说开发方式,仅从控件命名上 Flutter 和 Compose 就不会让你感觉陌生。

不说控件,就说这次 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 了:smirk:

当然大家可能会关心框架是否有坑的问题, 「本质上所有框架都有坑,甚至网络因素都可能会成为你的痛点,问题在于你是否接受这些坑」

跨平台的背后本身就是“脏活”和“累活”, Flutter 的全平台之路很艰难,就像之前写的 《解读 Flutter 全平台开发的误解与偏见》 , 现阶段 Flutter 全平台更多只是噱头,只是提供了“多一种可能”的阶段。

最后还是要例行补充这一点:

「跨平台之所以是跨平台,首先就是要有对应原生平台的存在,」 很多原生平台的问题都需要回归到平台去解决,那些喜欢吹 xxx 制霸原生要凉的节奏,仅仅是因为“你的焦虑会成为它们的利润”。

聊点废话

说点“道理我都懂”的实话,本质是我们作为开发者,其实并 「不应该把自己归纳为于某种语言和特定的框架之下」 ,我们现在被归纳在某个领域仅仅是因为工作需要,而对于未来我们的发展,其实更应该注重的是编程基础和动手能力。

我本身是通过 Weex 接触的 Vue ,也用过 uni-app 做个简单的小程序,用 React Native 开发过两端 App ,也用 Flutter 写过 Web ,甚至手贱地在 SpringBoot 上用 Kotlin 写 API。

所以在我眼中,现在客户端和前端之间的划分已经越来越模糊,我遇到不少 Android 开发写过小程序或者 Vue ,不少前端也通过 uni-app, Taro 和 Flutter 在写 App ,这是很正常的趋势, 「因为平台成熟了,越成熟的平台就会开始和相近的领域融合贯通」

你想说“卷”也行,这种趋势会让一些 「简单、重复或者需要共享」 的内容通过跨平台来得到落地, 「我相信有的人不看好跨平台,但是它存在的场景确实有它关键的价值。」

也许某些领域我的认识不是很深,但是在需要的时候我可以动手满足需求,甚至去深入探索一下,而我也有自己精通的领域,二次并不冲突。

当然你说我只想在某个平台深入研究有没有问题?那肯定没有问题,这是好事, 「因为精通某个领域本来就是非常好的一件事」

但是!对,我还是要说这个但是, 「因为很多时候精通某项技术,是需要业务场景去验证和推进的,如果不是大体量的业务场景,没有经历过各种极端的考验,很多时候所谓的精通只是表层精通。」

为什么说这个?因为在交流过程中经常有一些人说:想要深入xxx去精通某项技术或者领域,但是最终还是“三过门而不入”。

最后的最后,我想说学习其实本身是一件长期投资的事情,我们追求“性价比”和“高回报”很正常,但是这和投资金融一样, 「如果一直想要通过“投机”来获利,那就要有做好韭菜的准备。」

5

你选 Flutter 还是 Compose(单选)?

  • Flutter
  • Compose
  • 小孩子才做选择,成年人两个都要

0 投票者

推荐阅读
作者信息
CarGuo
TA 暂未填写个人简介
文章
7
相关专栏
开源技术
64 文章
本专栏仅用于分享音视频相关的技术文章,与其他开发者和 Agora 研发团队交流、分享行业前沿技术、资讯。发帖前,请参考「社区发帖指南」,方便您更好的展示所发表的文章和内容。