Docs

Kotlin Multiplatform 是迄今为止最优秀的跨平台方案

输入“/”快速插入

Kotlin Multiplatform 是迄今为止最优秀的跨平台方案

飞书用户7241

2023年12月2日创建

背景介绍

从时间角度

1.
计算机诞生之初。C 语言主导的跨平台，以及 QT 等跨平台 UI 框架​

2.
计算机发展中期，智能手机诞生初期。类似于 Java 的虚拟机跨平台等方案，有 swing、J2ME 等新奇产物，一套 Java 逻辑可以用在移动端和桌面端，编译成相同的 Java 字节码，不同平台依赖虚拟机完成跨平台执行。​
当然，还有 JS 生态也靠着 Google V8 引擎实现了跨平台，同时伴随着各种大厂也开始集成 chromium 进入手机 App，比如流行的腾讯 X5(TBS) 引擎​

3.
移动互联网时代。RN、weex、lynx 等方案实现的用前端代码写原生组件，也有用 MAUI，C# 写原生的​

4.
后来。有 Flutter，Compose 代表的自绘方案​

对于国内互联网，还有小程序的时期，以微信为首，支付宝随后，同时也有 uni-app 等的助攻，目前也是国内非常主流的跨平台实现。​

从技术角度

1.
直接编译成原生二进制产物的，框架全方位的适配各个平台不同的 Native 实现的。这方面的代表者就是 c/cpp 语言，甚至这几年较火的 rust，都是类似的思路。​

2.
JS 生态​
a.
偏浏览器方向，小程序是这一领域的典型代表，同时也有 Electron，Tauri 等桌面端跨平台方案​
b.
偏原生方向，仅仅把语言当做一个工具，兼容现有 js 生态，但渲染为原生组件，RN 是其中典型的代表，近期较火的鸿蒙 arkui 理论上也算一种​

3.
自建生态方案，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

[Kotlin Multiplatform](https://kotlinlang.org/docs/multiplatform.html)

旧有开发分层

1.
机器码层。理论上来说，越接近机器码的语言执行效率越高，C 方案就是这方面的代表，包括类似于 cpp/rust 等这些直接编译为机器码执行的语言，这些语言的特点普遍就是高性能、无 VM，所以对于绝对的性能，他们是不错的选择。​

2.
常规应用层。而再往上一层，就是各个系统提供的应用层开发工具，主打的就是一个高开发效率简单易学不容易出错，比如 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​