Kotlin Multiplatform 是迄今为止最优秀的跨平台方案
Kotlin Multiplatform 是迄今为止最优秀的跨平台方案
背景介绍
从时间角度
- 计算机诞生之初。C 语言主导的跨平台,以及 QT 等跨平台 UI 框架
- 计算机发展中期,智能手机诞生初期。类似于 Java 的虚拟机跨平台等方案,有 swing、J2ME 等新奇产物,一套 Java 逻辑可以用在移动端和桌面端,编译成相同的 Java 字节码,不同平台依赖虚拟机完成跨平台执行。
当然,还有 JS 生态也靠着 Google V8 引擎实现了跨平台,同时伴随着各种大厂也开始集成 chromium 进入手机 App,比如流行的腾讯 X5(TBS) 引擎 - 移动互联网时代。RN、weex、lynx 等方案实现的用前端代码写原生组件,也有用 MAUI,C# 写原生的
- 当下。有 Flutter,Compose 代表的自绘方案
对于国内互联网,还有小程序的时期,以微信为首,支付宝随后,同时也有 uni-app 等的助攻,目前也是国内非常主流的跨平台实现。
从技术角度
- 直接编译成原生二进制产物的,框架全方位的适配各个平台不同的 Native 实现的。这方面的代表者就是 c/cpp 语言,甚至这几年较火的 rust,都是类似的思路。
- JS 生态
- 偏浏览器方向,小程序是这一领域的典型代表,同时也有 Electron,Tauri 等桌面端跨平台方案
- 偏原生方向,仅仅把语言当做一个工具,兼容现有 js 生态,但渲染为原生组件,RN 是其中典型的代表,近期较火的鸿蒙 arkui 理论上也算一种
- 自建生态方案,Flutter 就是典型的代表,Dart 属于是彻底想重建一套生态,保证了多平台的 UI 一致性,但比较愚蠢的是放弃了现有 js/java 等完整的生态链
总结
现有的跨平台框架让事情变得更复杂了。
方案 | 新语言 | 生态 | 性能 | 包体积 | 跨了哪些平台 | 开发效率 | 一致性 |
---|---|---|---|---|---|---|---|
C | 否 | 褒贬不一 | 好 | 低 | all | 低 | 好 |
JVM | 否 | 好 | 较好 | 在 Android 平台低,因为 Android 自带 JRE,其他平台需要下载或内置 JRE,体积较大 | 能运行 JVM 的,除了 iOS 和一些低性能嵌入式设备,基本都行 | 高 | 好 |
WebView 方案 小程序,uni-app, electron,tauri | 否 | 好 | 差 | 大 有些选择内置 webview 方案,但都不可避免引入了一些 js runtime | 能跑浏览器的都行 | 高 | 好 |
类 RN 方案 week,lynx,MAUI 等 arkUI/arkTS | 否 | 较好 | 较好 | 大 有些选择内置 webview 方案,但都不可避免引入了一些 js runtime | 偏向于更支持移动端,桌面端都比较实验性或社区支持不如移动端 | 高,但排障能力可能会由于多端不同组件的特性产生差异 | 差 |
Flutter/Dart 方案 | 是 | 差 | 褒贬不一,但官方宣传好 | 大 | 偏向于更支持移动端,桌面端都比较实验性或社区支持不如移动端 | 中 | 好 |
跨平台一直以来都是失败的,JVM 尝试一套字节码多平台执行,Web 尝试网页但性能差,后来渲染为 Native View 却很容易导致多平台体验不一致,再到后来 flutter 引入自定义的渲染引擎自绘 UI
但为什么说其一直以来都是失败的呢?因为 Kotlin Multiplatform 的出现
Kotlin Multiplatform
旧有开发分层
- 机器码层。理论上来说,越接近机器码的语言执行效率越高,C 方案就是这方面的代表,包括类似于 cpp/rust 等这些直接编译为机器码执行的语言,这些语言的特点普遍就是高性能、无 VM,所以对于绝对的性能,他们是不错的选择。
- 常规应用层。而再往上一层,就是各个系统提供的应用层开发工具,主打的就是一个高开发效率简单易学不容易出错,比如 Android 可以在 jvm 上开发,苹果有 OC/Swift,微软也在主推使用 .Net 的 C# 编程。这一层通常是系统面向大多数开发者提供的应用运行环境层,通常性能也是比较好的,能够最便捷的享受操作系统各种 api 的便利,加速应用的开发,相对于直接面向机器码层面编程要简单许多,开发也更不容易出错。
KM 改变了什么
常规跨平台方案总会想着要么自己搞一个新的应用层,开发者用系统能力时只能用孱弱的相对底层提供的能力,要么提供丑陋的 FFI 跨语言调用。
但 KM 不是前面哪些丑陋的方案,Kotlin Multiplatform 的处理是在编译期执行的,运行则直接依赖对应宿主提供的常规应用层能力,我总结就是:
NO FFI,NO VM,FULL API
- NO FFI:没有跨语言调用开销,不需要桥梁,直接访问系统提供的常规应用层 API,直接与对应平台常规应用层代码交互
- NO VM:不需要额外运行环境,Kotlin 代码编译完成后变成对应平台可执行代码,Android 编译为 jvm bytecode,Android NDK 编译为机器码(so/a),Windows 编译为 lib/exe,Apple 编译为 dylib 等
- FULL API:使用 Kotlin 代码 0 开销的访问全部的给常规应用层提供的 API,编译后就是平台可执行代码之间的互相调用
同时由于使用 Kotlin 编写,原有的 Android 资产能高度复用,iOS 由于 Swift 和 Kotlin 语言设计思路非常相似,因此大多数 iOS 研发也比较认可这种多平台方案。
当然,Kotlin 还有 Native 方向,还能和 Multiplatform 复用代码,这一点完全碾压所有跨平台方案。举个例子,Android 基于 NDK 的开发竟然能和基于常规 SDK 的开发共享代码!这就出现了:
C/CPP/Rust 与 Kotlin Native 能够 0 损耗互交互,KN 和 KM 复用代码,KM 和 Java,Swift 等语言也能够 0 损耗互交互来访问平台特殊 API
其他
结语:
- React Native:Learn once, write anywhere
- Flutter:Write once, run anywhere
- Kotlin:Write once, compile anywhere, run (actually) everywhere(这个是编的)
相关参考:https://www.bilibili.com/video/BV12a4y1V7EC
个人主页原文:Kotlin Multiplatform 是迄今为止最优秀的跨平台方案
我在公司提出 KMM 只会被反对,他们没有对这个东西进行了解就直接拒绝,他们不配使用如此优雅的解决方案,所以我只选择自己去探索这个优雅的解决方案,这是我的热情