hello 咱们好,我是 Flutter GDE 郭树煜,一起也是 Github GSY 项目的负责人,比方 GSYVideoPlayer ,今日要给咱们共享的主题是 Android 开发者的跨渠道 – Flutter or Compose ? 今日的共享不会是很深化的技能内容,更多或许是科普向,特别是对 Flutter 和 Compose 还不是特别了解的 Androider 们,经过数据协助咱们来了解 Flutter 和 Compose。
一、Android 开发和跨渠道开发的现状
首先咱们聊聊现状,不知道你有没有这种感觉,便是现在的 Android 开发者许多时分不再是 Android 开发,或者说不是纯 Android App 开发,现在简略总结大致能够分为两类:
- 以 Android 为技能栈的嵌入式开发,如电视、手表、教育平板、监控等,这儿面近年来又以车机开发较为杰出。
- 大前端开发,从 Android 、 iOS 、Web 到小程序等各类面向 UI 相关的作业内容
这个现状的具体原因在于:Android 开源让它能够更好地被各行各业消化,一起这些年 App 开发系统越发老练。
我还记得 2015 年那会我带的移动团队开发一款 App ,标配便是 Android 和 iOS 各自 4-5 个人,还经常需求加班加点,项目里会用到大量第三方的开源结构。
而现在跟着官方这些年 Jetpack 系统的老练,Android 开发者更多会聚集到 Jetpack 系统内,比方:Room
、CameraX
、Hilt
、Navigation
、Paging
、WorkManager
、Emoji2
、DataStore
、Media
、Startup
等,而 Compose 便是 Jetpack 里的最大亮点之一,假如说 Android 开发现在进入了 Jetpack 纪元,那 Jetpack Compose 便是 Jetpack 纪元里的超新星。
Jetpack Compose 是 Android 新推出的声明式 UI 工具包,它首要是用于简化和加快 Android 上的 UI 开发,一起 Compose 经过 Jetbrains 开源的 compose-jb 支撑到跨渠道开发的才能。
这儿三个要点:
- Jetpack Compose 是 Android 的 UI 的工具包
- Jetbrains 开源了 compose-jb 支撑跨渠道
- Compose 是声明式开发
从大前端开发的视点看,声明式开发能够说是当今的干流,React、Vue、SwiftUI、Flutter 等都是声明式编程,还有如近期发布的 HarmonyOS 3.1版别,也侧重标示了它将全面进入声明式开发阶段。
所以不论你喜不喜欢,声明式开发是干流,尽管它近期看起来不会彻底代替 Android 的 XML 布局,可是这是干流的趋势。
再说跨渠道,现在跨渠道开发相信咱们都不会陌生,各类跨渠道开发结构都相当老练,可是关于 Android 开发来说, Flutter 和 Compose 的确会显得比较特别,由于它们都是归于 Google 开源的产品,都能支撑跨渠道,所以能够关于部分 Android 开发者来说会堕入困惑:我该选哪个?
针对这个疑惑,咱们先看一些数据比照,首先如下图所示,是 Google Trend 上 Flutter 和 Compose 在全球和国内的一些要害词搜索热度比照,能够看到全球范围内都是在稳步上升,可是在国内是归于激烈波动的状态,也便是国内有许多人关于 Flutter 和 Compose 都还处于徜徉观望状态。
别的也能够看到 , Flutter 出来比较久,所以现在他的热度会比较高,当然这也是现在跨渠道的需求剧增有联系,许多渠道开发人员不再仅仅 ”安居” 于自己的渠道,而且从国内的数据能够看到,国内关于跨渠道的热情其实一向很高。
尽管 Flutter 从发布以来一向争议不断,可是这些年下来 Flutter 也证明了自己的价值,后面咱们会有独自的详细的数据剖析。
再看 StackOverFlow 的数据,能够看到 Flutter 和 Compose 都在稳步上升,这儿面 Compose 相关看起来比较少的原因,和它发布时间还较短有联系,而 Flutter 从现在的占有份额上看其实不算低了。
既然说 Flutter 和 Compose 就不得不说 Dart 和 Kotlin ,相同是 StackOverFlow 的数据,能够看到尽管他们发布都有一段时间了,可是其实是在 2017 年开端它们的占有率才呈现了爆发式的上升,这是为什么呢?
其实这个现象和 2017 Google I/O 大会有直接联系:
-
Kotlin 是 2012 年开源的,而 2017 Google I/O 大会上官方正式支撑将 Kotlin 作为 Android 开发的 First-Class(一等公民)言语
-
Dart 亮相于 2011 年,而 2017 年 Google I/O 正式向外界发布了 Flutter,Dart 是它的首要开发言语
所以 Kotlin 原本不温不火,可是由于 Android 它开端被更多人所运用,相同 Dart 原本已经快被雪藏,却由于 Flutter 而勃发第二春,看起谷歌在这方面运营才能仍是很值得必定的。
咱们再看一份数据,这是现在 Kotlin 和 Dart 在 Github 上关于 PR 和 Star 的数据趋势,能够看到开端增加的时间节点依然是 2017,不过 Dart 的重视度仍是从 Flutter 正式版发布后才有爆发式增加, 而从增加上看,不论是 Kotlin 仍是 Dart 现在都很过得去,不过现在它们的首要运用场景仍是限制在 Android 和 Flutter。
再看国外调研的一份关于 Flutter 和 Compose 在 Droidcon 上有多少次关于这两个项目的讲演主题和成果,尽管数据相对较小和限制,可是能够看到 Flutter 自发布以来每年都在安稳的主题,而 Compose 在安稳版发布后有显着爆发式增加
最终,刚好 GitHub 也发布了 2022年度报告,其间一些数据仍是值得咱们重视,例如在开发言语增加上, Kotlin 排进了前十,别的移动端开发依旧是开源干流之一,其间 Kotlin、Dart 、Flutter 、Android 都是首要的对象。
当然,就像前面说的,不论是 Dart 仍是 Kotlin ,它们首要是场景仍是在于 Flutter 和 Android ,经过 TIOBE 在 2022 年 11 月的编程言语指数上能够看到, Dart 和 Kotlin 仍是未能进入 TIOBE 指数前 20 名,该指数每月更新一次,在编程言语的盛行程度上有比较高的参考价值。
不是说其他范畴不能用,比方 Kotlin 和 Dart 都能写后端,我曾经自己也有一些后端项目,其时为了便利,直接把Android 上 kotlin 的逻辑复用到服务端,而 Dart 自身经过 ffi 直接支撑数据库等的才能,也让它能够脱离 Flutter 作为独自的后台服务运转,这在我曾经的文章也共享过,现在支撑 Dart 的 ffi 数据库也有好几款了,所以不是说不能用不支撑,只是相对仍是少许多。
咱们最终在看一份数据, RedMonk 2022 Q3 的查询里,在 Github 和 StackOverflow 的盛行指数上仍是比较靠前的,Kotin 排在第 17 位,而 Dart 排在第 19 位,从运用范畴看,这两种言语现在的气势仍是不错的。
所以总结来说: **Android 成果了 Kotlin ,而 Kotlin 成果了 Compose ,相同 Flutter 成果了 Dart **。
二、Compose 关于 Android 开发来说是什么
接下来进入第二个主题,Compose 关于 Android 开发来说是什么:
- Compose 对 Android 来说最重要的是新的现代化 UI 开发结构,Compose 供给了 Andorid 声明式的 UI 开发才能,这是中心的要点。
- Jetbrains 开源的 compose-jb 让 Compose 得到了额外的增值,能够把开发才能拓宽到其他渠道,这是附带价值。
所以从这个视点看,假如你持续做 Android 开发,那么学会 Compose 是必须的技能,由于它未来或许会是 Android 上干流的开发形式,尽管它现在还比较年轻。
说他年轻,是由于现在他的正式版发布也就一年的时间,现在 Jetpack Compose 和 compose-jb 的正式版别都在 1.2 ,第一个正式版是都是在 2021 年发布,而且在近一年时间内发布了两个大版别,别的能够看到 compose-jb 都是在 Jetpack Compose 发布之后再跟进版别更新,所以 Jetpack Compose 是一些的基础中心。
那么咱们必定很关心一个问题,有哪些大厂 App 在运用 Compose ?
现在关于 Flutter 的技能文章咱们或许看到过许多大厂的共享,可是 Compose 相关的份额却不多,所以我也只能从我自己手机里一些常用软件的归类,现在刚好能够找到如下图所示的 6 款 App 里有存在 Compose 的痕迹。
当然,运用 Jetpack Compose 和运用 compose-jb 其实是两码事,所以我也不知道上述产品是否也有运用 compose-jb 的场景,由于其实 compose-jb 现在在跨渠道开发上的体会仍是有些差别的。
而作为全新的独立 UI 结构, Compose 自然不会像曾经相同的控件系统,相似的声明式布局方式关于 Android 开发者来说或许会有必定的学习本钱,最直观的便是 Compose 里会运用状态管理和绑定,而不会是像曾经相同拿 view.xxxx
这样的操作方法,这是一个思路改变的进程。
别的从反编译后的代码里能够看到,Compose 里的控件和原生控件并不是一个系统,咱们假如去看编译后的内容,就会发现例如 BOX
这样的控件在编译后是经过 ComposerKt
和 BoxKt
等的 framework 完结来完结的布局与制作。
所以 Compose 编译后不是转化为原生的 Android 上的 View 去显现,而是依靠于渠道的 Canvas
,在这点上和 Flutter 有点相似,简略地说能够了解为 Compose 是全新的一套 View 。
别的友谊提示:尽管是全新的 View ,可是
Compose
的组件在 Android 上是能够显现了布局鸿沟。
别的 Compose 里的代码根本都是能够被混淆的,所以敞开混淆之后代码的压缩率也很高。
在 Compose 里两棵树的设计,虚拟 Dom 风格的 SlotTable 和 React 设计相似,从而保证了 LayoutNode 的性能,Compose 的中心设计开发人员 Jim Sproch 之前是 React 的中心开发。
其实这也是一种大前端的趋势,不论你是客户端仍是前端开发,你的才能都应该能够得到运用。
再说 compose-jb ,如下图所示, compose-jb 在跨渠道开发体会上仍是有所区别,Compose 现在是经过多个模块完结来支撑多渠道,所以现在 Jetpack Compose 和 compose-jb 有一些“割裂”, compose-jb 本质上是将 compose-desktop,compose-web 以及 compose-android 进行了整合,特别是在 Web 端,想要达到 Flutter 相同共享代码的份额还需求持续努力。
如上图所示的 iOS 其完结在也已经进入实验阶段 , androidx.compose.ui.main.defaultUIKitMain
相关的支撑间隔正式发布能够等待,而 compose-jb 现在对跨渠道的支撑的 “割裂” 也来自于此,比方 Web 下的代码会是这种感觉。
import org.jetbrains.compose.web.dom.*
import org.jetbrains.compose.web.css.*
fun main() {
var count: Int by mutableStateOf(0)
renderComposable(rootElementId = "root") {
Div({ style { padding(25.px) } }) {
Button(attrs = {
onClick { count -= 1 }
}) {
Text("-")
}
Span({ style { padding(15.px) } }) {
Text("$count")
}
Button(attrs = {
onClick { count += 1 }
}) {
Text("+")
}
}
}
}
别的值得一提的是,Compose for Wear OS 的 1.0 安稳版也发布了。
还有一个要害点便是,假如运用 compose-jb ,你或许还会接触到 Kotlin/JS 、Kotlin/Native、KMM 等对应的名词,这部分关于 Android 开发来说也算是额外的学习本钱,所以在跨渠道体会上现在 compose-jb 的路才刚刚开端,一致性的跨渠道开发体会相信会是 compose-jb 努力的方向。
其实前面所说的“割裂”问题,现在能够看到官方也在有序推动,其间就有 desktop 的部分代码已经挪到了androidx 上,从这儿看或者一致的 Compose lib 并不悠远。
别的 Jetpack Compose 现在针对 Compose 系统的官方依靠支撑,也推出了 Gradle BOM (Bill of Materials) 依靠形式,用于指定每个 Compose 库的安稳版别。
现在第一个版别是 Compose 2022 年 10 月版,现在最新的应该是 2022.11.00。
那么 Gradle BOM 的效果是什么?如下图所示,简略说便是不用再独自写依靠版别, 咱们能够经过仅指定 BOM 的版别管理一切 Compose 库版别,BOM 自身具有指向不同 Compose 库的安稳版别的链接,所以它们能够很好地协同作业。
当然,聊到这个就趁便聊一聊约束 compose-jb 的问题:缺少插件社区。
这其实是跨渠道范畴必不可少的配置:前端有 npm 、Flutter 有 pub,你能够经过它们的中心官网搜索你想要的库,查看它们的热度,版别,兼容和运用量等等信息,设置官方认证和安全保证,乃至还有趋势引荐,库支撑的渠道有哪些等等,可是 Maven 年代在这方面一向很弱,这是 compose-jb 后续发展需求处理的最大问题之一。
最终提到 Compose 就不得不说 Android Studio :Compose 和 Android Studio 版别其实有很强的依靠联系,例如:
1、Android Studio Arctic Fox (白狐狸) 开端支撑 Compose preview 、 Interactive preview 和 Deploy to Device ,并开端支撑 Live Edit of literals 和 Layout Inspector 。
2、Android Studio Bumblebee (小蜜蜂) Layout Inspector 才支撑查看 Compose 布局中的语义信息,而且默许启用 interactive preview,interactive preview 答应在预览时进行交互,就像是已经运转到设备上作业相同。
这儿的 Preview interactive 形式直接在 Android Studio 中运转,无需运转模拟器,这会导致一些约束:没有网络拜访权限、没有文件拜访权限、某些上下文 API 或许不彻底可用。
值得一提的是, Compose 现在不支撑 hotload,Android Studio 的 apply code 的有用程度相信咱们深有体会,不过 Compose 有支撑 preview 时的文本 Live Edit of literals ,这也算是一个可将一下的工具。
3、Android Studio Chipmunk (小松鼠) 开端支撑 animatedVisibility
的动画预览,动画预览和animatedVisibility
需求运用 Compose 1.1.0 或更高版别。
4、Android Studio Dolphin (海豚) 支撑 Compose Animation Coordination,假如你的动画是用于 composable preview,那么能够运用 Animation Preview 来一起查看和协调一切动画,乃至还能够冻结特定的动画,而且支撑 composables 何时进行或不进行重构
最终,假如你猎奇现在哪些大厂在运用 compose-jb ,现在我还没找到比较有价值的数据,不过据称 JetBrains 现在就已经将 Toolbox 运用经过 compose-jb 完结而且发布运用。
三、 Flutter 关于 Android 开发来说是什么
接下来咱们聊聊 Flutter 关于 Android 开发者来说又是什么?你假如挑选仍是只做 Android ,那么 Flutter 对你来说或许意义不大,Flutter 其实起源于 Chrome 内部团队,所示它其实和 Android 没什么联系,可是假如你对其他渠道感兴趣,那么 Flutter 绝对是你不错的挑选。
Flutter 正式版是在 2018 年发布,发布之后简直便是每个季度都会更新一个大版别,如下图所示能够看到 Flutter 的推动和迭代速度是很快的,这也旁边面反映了 Flutter 社区的生机。
假如大版还不行有说服力,那么近期的小版别迭代速度,这也能够体现 Flutter 社区的生命力,当然也旁边面反映出全渠道支撑的困难,需求处理的问题许多,由于跨渠道需求兼容处理的问题会更多,这也是 Flutter 坑多的原因。
咱们再从 Github 发布的 2022 年度报告上看,在各项开源数据里 Flutter 都名列前矛:
- 顶级开源项目里按贡献者排序 Flutter 排第三
- 顶级开源项目里按初次贡献者统计的,Flutter 在获取贡献“一血”里排名第四
- 在每个项目的贡献者数量里 Flutter 排名第二
- 在外部贡献者百分比里 Flutter 排名第三
由此能够看到 Flutter 强壮的生命力,特别是来自社区的活跃,Flutter 每个版别发布都会合并大量来着社区的 PR ,这也是 Flutter 这些年来快速发展的原因,一起也是在本次 Github 发布的报告里,到处能够见 Flutter 的原因。
那么说一千道一万,现在有哪些咱们熟知的企业在运用 Flutter 呢?
如下图所示是现在我手机里有 Flutter 存在的 App ,别的还有曩昔三年里 Flutter 在跨渠道范畴的占有率增加,能够看到 Flutter 现在在跨渠道范畴的存在感并不低,其实介绍这么多数据,只是为了和咱们阐明一个问题:Flutter 已经不算小众了。
百度网盘、转转、阿里云盘、闲鱼、微信、、企业微信、微博、B站漫画、阿里云、 UC浏览器、优酷视频、钉钉、360摄像头、网易邮箱、天猫精灵、链家、美团众包、凤凰新闻、腾讯课堂、喜马拉雅、携程旅行、贝壳找房、WPS、学习强国、唯品会、同花顺
回到 Flutter 自身上,Flutter 的优势体现在于 single codebase ,它是真的做道一套代码编译成不同渠道的 native 代码运转,Flutter 跨渠道最特别在于它不依靠渠道控件,控件最终都是使用 Skia 经过渠道 GPU 烘托出来。
所以 Flutter 里的控件根本和渠道无关,这关于跨渠道来说有很大优势,由于控件只和 Flutter 结构有联系,在 Andriod 上得到的效果,在 iOS 上也能够得到相同的成果,所见即所得,这对开发功率有很高的协助。
可是这也大大供给了结构维护的作业量,例如文本输入框
TextFiled
和Text
都针对移动渠道和 PC 渠道,需求在控件内部兼容手势接触和键鼠操作,,这也是为什么相似 Global Selection 等功能会到 3.3 才开端有官方支撑。
一切 Flutter 需求面临的 Bug 也许多,在面临越来越多不可控的底层烘托问题之后,Flutter 开端自建烘托引擎,由于直接运用 Skia 已经无法满意日益增加的 Bug 和性能极限,所以官方开端了自研烘托引擎Impeller 。
由于 Flutter 团队现在呈现问题每次都要和 Skia 团队交流,然后等跟进,这样的节奏太慢了,从前面官方的小版别更新日志上就能够看出现在 Flutter 的迭代速度依然很夸大。
这次自研的 Impeller 本质上是为了处理 Skia 需求运转时遇到的问题,让 Impeller 能够直接在编译器就完结 GLSL 和 MSL ,不需求 SKSL 从而提高了性能和运转时的安稳性 ,现在优先在 iOS 渠道上开端支撑 ,配合 Metal 做优化,后续假如没问题也会同步支撑 Android 和 Vulkan 。
从这个视点猜想,Flutter 在 Skia 遇到的问题 compose-jb 也很或许会遇上,而假如后续 Impeller 项目进展顺利,那它或者并不会限制在 Flutter ,也许也能够拓宽支撑到 compose-jb上,
其实在 Jetbrains 的开源项目里有一个叫 skiko 的项目,Skiko(Kotlin 的 Skia 的缩写)是一个图形库,它支撑 Kotlin/JVM 、Kotlin/JS 、Kotlin/Native 等相关完结。
所以自研发引擎的形式并不古怪,跟着项目的发展和深化,许多底层问题没办法快速推动就会反推自研,例如 Hermes 在 RN 0.7 成为默许 Engine 也是相似问题的体现,自研底层归所以一个负责任的开源团队的必经之路。
最终,假如真要总结 Flutter 关于 Android 开发者最大的意义,便是具有开发其他渠道的才能,经过 Flutter 去了解和接触开发其他渠道的,一起还能提早习得大部分 Compose 的开发才能,如下图所示是 Compose 和 Flutter 的代码比照:
所以这也是 Andorid 开发会了 Flutter 就离 Compose 不远的原因,反过来也是。
这儿能够趁便引荐下大佬的 Flutter 和 Compose 入门项目 FlutterUnit 和 ComposeUnit ,上面的代码便是来自这两个项目,里边列举了许多事例,特别适合入门的小伙伴。
最终
本次共享的中心还行想告知咱们,现在 Compose 和 Flutter 老练度已经不错了,当你的领导和你说,Kotlin、Dart 还不行遍及,Flutter 和 Compose 还太小众的时分,或者你就可有一些数据依据。
最终能够总结的是:
- Compose 的中心仍是 Android 的 UI 库,做 Android 的必须把握这个未来的才能,至于 compose-jb 的跨渠道增值才能,还有一段路要走。
- Flutter 的中心是全渠道更安稳的支撑,更有社区生机,特别是在相对“冷清”的桌面端上的优势,在现在揭露信息上,钉钉、字节和企业微信都在 Flutter 桌面端开端有投入。
所以结合自己的路线,选哪个应该就很清楚了,而不论挑选哪一个,都会对别的一个结构有提早衬托的效果,所以也不用担心得此失彼,感兴趣的小伙伴能够开端动起来了~