一文快速带你了解 KMM 、 Compose 和 Flutter 的现状

Android 4月前 0 78

又到了脍炙人口的环节，本篇主要是科普 KMM 、 Compose 和 Flutter 的最新现状，关于 Compose 和 Flutter 大家或许并不生疏，可是关于 KMM 或许会存在疑惑，KMM 全称 Kotlin Multiplatform Mobile ，故名思义它是用 Kotlin 完结的跨渠道结构，那为什么今日忽然会聊到它？

原因如下图所示，今日忽然有群友提及了 KMM ，而且用了“变天”的词汇，顿时就勾起了我的兴起，由于 KMM 这些年来一向“不温不火”，能够说许多运用 Kotlin 开发的 “Androider” 对它都很生疏，莫非最近它又有了什么突破性的开展？

而在求证一番之后，原来原因来自 10 月初 Android 官方宣告 Jetpack 开始要支撑 KMM 了，现在 Collections 和 DataStore 现已能够经过依靠 -dev01 版别在多渠道上运用，同时 KMM 进入 Beta 版别阶段。

所以现在 KMM 变不了天，至少它还处于 Beta 阶段，可是 Jetpack 开始支撑 KMM 是个很好的消息，这意味着 KMM 的社区支撑有了官方确保。

好了，介绍完原因，接下来开始进入今日的主题，什么是 KMM 、 Compose 和 Flutter。

KMM

Kotlin Multiplatform Mobile – KMM 是基于 Kotlin 并运用在 iOS 和 Android 的一种跨渠道技能，它的特色是结合了跨渠道和原生开发协同开发的形式，如下图所示，简略的了解便是：从纯原生开发变成了 KMM + 原生 UI 开发。

运用 KMM 能够把你的业务逻辑和基建部分的才能跨渠道化，例如网络恳求、数据存储，状况上报等模块经过 KMM 完结 Android 和 iOS 通用，例如前面介绍的 DataStore 就能够在 iOS 上支撑运用。

在官方的介绍里 KMM 的前期运用者有百度、Netflix、VMWare、Philips 等，现在收到的反馈都挺不错，而 Beta 版别也意味着现在 KMM 现已具备了运用的根底。

那你或许会好奇，KMM 支撑 Web 吗？

聊到这个话题就很有趣，从我的视点上看，我会说 Kotlin Mutiplatform 支撑，可是 KMM 不支撑。

假如你安装过 KMM 插件和创建过 KMM 项目，你会看到 KMM 不管是从 logo 仍是项目创建都只有 Android 和 iOS ，可是，Kotlin Mutiplatform 是支撑 Web 的，经过 Kotlin JS 。

假如接触 Kotlin Mutiplatform 比较早，那你那么或许还听说过 KMP ，KN 之类的缩写，那它们和 KMM 又是什么关系？简略来说：

KMP 一般指的便是 Kotlin Mutiplatform ，我依稀记得 KMP 这个概念是在 Kotlin 1.2 的时分被提出，能够将Kotlin 运转到特定渠道的 JVM 和 JS 代码上
KN 一般指的是 Kotlin Native ，KN 属所以将 Kotlin 编译为 Native 二进制文件的技能，乃至能够在没有虚拟机的情况下运转，例如 KMM 上的 iOS 便是运用了 KN 的才能，
KMM 是利用了 JVM 和 KN 才能完结的针对 Android 和 iOS 渠道的 Kotlin 结构：Android（Kotlin/JVM）和 iOS （Kotlin/Naitve）

别的还有 Kotlin JS 用于 Web 渠道，所以 KMP 能够看作是大集合，而 KMM 是其间针对 Android 和 iOS 的支撑，别的经过 Kotlin Native 和 Kotlin JS 也能够支撑拓宽到 PC 端和 Web 端。

那么到这儿你应该了解：KMM 主要是用来写跨渠道逻辑，涉及到 UI 部分你仍是需求经过原生完结，假如你从别的一个视点看，用 KMM 关于 Android 开发来说几乎等于白送的才能，由于它只需求 Kotlin。

至少 Compose 你还需求适应下呼应式开发形式。

那或许有人就问：那 KMM 这也的含义安在？

事实上还真有，KMM 在 App 的基建上会很有用，比方做数据上报，崩溃统计，数据分析等等，纯逻辑的跨渠道不影响 UI 部分，现在也是在这些场景上 KMM 运用较多。

别的还有人问我，KMM 能够用 Java 开发吗？嗯，这是个好问题，下次不要再问了。

当然，KMM 也存在一些限制，比方运用 ViewModel 和协程如安在 iOS 上运转的问题，不过社区针对这部分也有一些第三方支撑，所以关于 KMM 的未来仍是值得等待。

Compose

Compose 信任大家不会生疏，其实 Compose 也能够分两部分看待， Jetpack Compose 和 Compose Multiplatform：

由 Android 官方保护的 Jetpack Compose
由 JetBrains 保护的 compose-jb 完结的 Compose Multiplatform

假如说 KMM 时用于完结跨渠道的业务逻辑，那么 Compose Multiplatform 便是专注于跨渠道 UI 上的支撑，那 KMM 和 Compose Multiplatform 是什么关系呢？

从项目视点看， compose-jb 和 KMM 其实没有关系，由于 KMM 还在 beta ，可是 Compose Multiplatform 正式现已发布挨近一年的时刻。

可是你要说完全没关系显然是不或许，究竟 Kotlin Native 和 Kotlin JS 的才能其实在 Compose Multiplatform 里很重要。

当然，如下图所示，Compose Multiplatform 在跨渠道开发体会上仍是有所区别，Compose 现在是经过多个模块不同完结来支撑多渠道，所以现在 Jetpack Compose 和 Compose Multiplatform 有一些“分裂”，特别是在 Web 端，想要达到 Flutter 相同共享代码的份额还需求继续尽力。

PS ：图比较老，iOS 其完结在现已进入实验阶段， androidx.compose.ui.main.defaultUIKitMain 相关的支撑距离正式发布能够等待。

别的 Compose Multiplatform 还有的问题便是短少插件社区，这其实是跨渠道范畴必不可少的配置：前端有 npm 、Flutter 有 pub，你能够经过它们的中心官网搜索你想要的库，查看它们的热度，版别，兼容和运用量等等信息，设置官方认证和安全保障，可是 Maven 年代在这方面一向很弱。

另一方面 Compose 的优势也很明显：

Kotlin 生态
Android 开发友爱
打包体积增长不大，代码压缩份额高
功能不错，compose-android 和 compose-desktop 都运用 Skia

而跟着 Jetpack 开始支撑 KMM ，那么 Compose Multiplatform 的社区支撑力度将得到进一步提升，由于变相 Compose Multiplatform 也能够支撑 Jetpack 。

至于前面所说的“分裂”问题，现在能够看到官方也在有序推动，其间就有 desktop 的部分代码现已挪到了androidx 上，从这儿看或许一致的 Compose lib 并不遥远。

PS： JetBrains 现在就现已将 Toolbox 运用经过 Compose Multiplatform 完结而且发布运用。

Flutter

常看我文章的应该对 Flutter 更不生疏，现在 Flutter 现已是 3.3 的版别，Flutter 的特色便是跨渠道，由于它并没有自己的渠道，同时它也是 single codebase 的跨渠道完结。

关于 Flutter 和其他结构的对比或许运用数据这儿就不多赘述，由于这方便之前我现已分享过许多，感兴趣的能够参阅下方链接，这儿介绍一些其他比较有意思的话题。

Flutter VS Other 量化对比

国内大厂运用在移动端 Flutter 结构运用分析

国内大厂在移动端跨渠道的结构接入分析

在 Jetbrains 的开源项目里有一个叫 skiko 的项目，Skiko（Kotlin 的 Skia 的缩写）是一个图形库，它支撑 Kotlin/JVM 、Kotlin/JS 、Kotlin/Native 等相关完结，现在支撑有：

Kotlin/JVM – Linux、Windows、macOS、Android
Kotlin/JS – web
Kotlin/Native – iOS 、macOS

假如从这个视点看 Compose Multiplatform 未来的方向会和 Flutter 很像，乃至由于 Flutter 走过更多的坑，所以 Compose Multiplatform 在对接 Skia 上能够有更多的参阅。

其实未来 Linux、Windows 等渠道也完全能够脱离 JVM 经过 Kotlin/Native + Skiko 完结支撑，仅仅保护成本会变高。

而 Flutter 在自建烘托引擎上其完结已越来越急进，由于直接运用 Skia 现已无法满足日益增长的 Bug 和功能极限，所以官方开始了自研烘托引擎Impeller 。

由于 Flutter 团队现在出现问题每次都要和 Skia 团队沟通，然后等跟进，这样的节奏太慢了，从官方的更新日志上就能够看出现在 Flutter 的迭代速度仍然很夸张。

所以这次自研的 Impeller 本质上是为了处理 Skia 需求运转时遇到的问题， Impeller 能够直接在编译器就完结 GLSL 和 MSL ，不需求 SKSL 从而提高了功能和运转时的稳定性，现在优先在 iOS 渠道上开始支撑，配合 Metal 做优化，后续假如没问题也会同步支撑 Android 和 Vulkan 。