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 只会被反对，他们没有对这个东西进行了解就直接拒绝，他们不配使用如此优雅的解决方案，所以我只选择自己去探索这个优雅的解决方案，这是我的热情