Kotlin Multiplatform (KMP) 介绍 – wiki基地

Kotlin Multiplatform (KMP): 跨越平台界限的现代化开发利器

在软件开发领域，尤其是移动应用开发，开发者们长期以来都面临着一个巨大的挑战：如何高效地同时为多个平台（如 Android 和 iOS）构建应用？传统的解决方案是为每个平台维护一个独立的、由原生语言编写的代码库。这种方法虽然能够充分利用各平台的特性和性能，但也带来了显著的成本：冗余的代码、不同步的功能、增加的维护负担以及对不同技术栈专业人才的需求。

为了解决这些痛点，跨平台开发框架应运而生。从早期的 Xamarin、Ionic，到后来的 React Native、Flutter，它们都尝试通过不同的策略（如 WebView、虚拟机、自绘 UI）来实现代码共享。这些框架在一定程度上缓解了平台壁垒，但也往往伴随着各自的权衡：性能、原生体验的损失、依赖特定框架的生态系统，或者在处理复杂原生功能时的额外开销。

正是在这样的背景下，JetBrains 推出了 Kotlin Multiplatform (KMP)。KMP 提供了一种独特且强大的解决方案，它不是一个强制统一 UI 的框架，而是一个旨在让开发者能够共享应用程序中非 UI 部分的代码的技术。这意味着开发者可以使用 Kotlin 编写业务逻辑、数据模型、网络层、数据存储等核心代码，并在 Android、iOS、Web (浏览器/Node.js)、桌面甚至后端等不同平台复用这些代码，同时允许每个平台继续使用其原生的 UI 框架来构建用户界面，从而兼顾了开发效率和原生体验。

一、KMP 解决的核心问题：代码冗余与平台割裂

在深入探讨 KMP 的技术细节之前，我们先更详细地剖析一下传统多平台开发的困境：

重复开发与维护的成本高昂： 对于同一个功能，开发者不得不在 Android (Kotlin/Java) 和 iOS (Swift/Objective-C) 上分别实现一遍业务逻辑、数据处理、API 调用等。这意味着双倍甚至多倍的开发工作量。当需求变更或发现 bug 时，同样需要同步修改多个代码库，极易出现不同平台行为不一致的问题。
功能迭代速度慢： 新功能上线需要投入更多资源在不同平台同步开发，导致发布周期变长，无法快速响应市场变化。
平台间功能不一致： 由于开发者、实现方式、排期等差异，不同平台上的同一功能可能会存在细微甚至明显的行为差异，影响用户体验和品牌一致性。
招聘与团队管理复杂： 需要招聘和管理精通不同平台技术的工程师团队，增加了沟通协调和知识共享的难度。
资源浪费： 大量重复的业务逻辑代码、测试用例、文档等，构成了资源的巨大浪费。

KMP 的核心理念正是针对这些问题：通过最大化地共享非 UI 逻辑代码，大幅减少重复工作，提高开发效率，确保平台间行为一致，并降低维护成本。

二、什么是 Kotlin Multiplatform (KMP)?

Kotlin Multiplatform 是 Kotlin 语言的一个特性集合，它允许开发者在同一个项目中定义一个共享模块 (Shared Module)，这个模块使用 Kotlin 编写，并且可以编译成适用于不同平台的代码。

与一些“一次编写，到处运行”的框架不同，KMP 的目标是“一次编写，多次复用” (Write Once, Run Anywhere)，但这里的“运行”主要指的是业务逻辑和数据处理。KMP 的独特之处在于它能够编译成各种不同的目标平台代码：

JVM (Java Virtual Machine): 用于 Android 应用、后端服务 (如使用 Spring、Ktor) 以及桌面应用。
JS (JavaScript): 用于前端 Web 应用、Node.js 后端，甚至可以通过一些工具实现桌面应用。
Native (通过 Kotlin/Native 技术): 直接编译成平台相关的二进制代码，无需虚拟机。这对于针对 iOS (ARM64, x64)、macOS (ARM64, x64)、Linux (x64, ARM64)、Windows (x64) 等平台生成可执行文件或库至关重要。Kotlin/Native 运行时轻量且不包含垃圾收集器，可以与原生代码无缝交互。

一个典型的 KMP 项目结构通常包含：

commonMain: 共享模块的核心部分，存放通用的业务逻辑、数据模型、接口定义等与具体平台无关的代码。这些代码可以在所有目标平台上编译和运行。
androidMain: 存放 Android 平台的特定代码，比如实现 commonMain 中定义的平台相关接口，或者调用 Android SDK API。
iosMain: 存放 iOS 平台的特定代码，比如实现 commonMain 中定义的平台相关接口，或者调用 iOS (Objective-C/Swift) 的 API。通过 Kotlin/Native 的互操作性，Kotlin 代码可以轻松调用 Swift/Objective-C 代码，反之亦然。
其他平台模块 (e.g., jsMain, jvmMain, desktopMain): 根据需要支持的其他平台，创建相应的平台特定模块。

KMP 并非是一个独立的框架，它是 Kotlin 语言及其编译器的能力延伸。它与 Gradle 构建系统深度集成，通过 Gradle 脚本配置项目的多平台依赖和编译任务。

三、KMP 的核心机制：`expect` 和 `actual`

KMP 实现平台代码共享与平台特性访问的关键机制是 expect 和 actual 关键字。

expect: 在 commonMain 模块中，当你需要调用一个在不同平台上具有不同实现（或者需要调用平台原生 API）的功能时，你可以在 commonMain 中使用 expect 关键字来声明这个功能（如一个类、接口、函数、属性等）。expect 声明只定义了功能的签名，而不包含具体的实现。它表示“我期望在每个目标平台上都能找到这个功能的具体实现”。

kotlin // commonMain/kotlin/com/example/kmp/Platform.kt expect class Platform { fun getName(): String fun getVersion(): String }
actual: 在每个平台特定的模块 (如 androidMain, iosMain) 中，你需要使用 actual 关键字来提供 expect 声明对应的具体实现。编译器会检查每个目标平台是否都提供了所有 expect 声明的 actual 实现。

“`kotlin
// androidMain/kotlin/com/example/kmp/Platform.android.kt
import android.os.Build // Android Specific Import

actual class Platform actual constructor() { // actual constructor might be needed
actual fun getName(): String {
return “Android”
}
actual fun getVersion(): String {
return Build.VERSION.SDK_INT.toString() // Using Android SDK
}
}
“`

“`kotlin
// iosMain/kotlin/com/example/kmp/Platform.ios.kt
import platform.UIKit.UIDevice // iOS Specific Import

actual class Platform actual constructor() { // actual constructor might be needed
actual fun getName(): String {
return UIDevice.currentDevice.systemName() // Using iOS SDK
}
actual fun getVersion(): String {
return UIDevice.currentDevice.systemVersion() // Using iOS SDK
}
}
“`

通过 expect/actual 机制，commonMain 中的代码可以调用 expect 声明的功能，而在编译时，根据目标平台的不同，会自动链接到相应的 actual 实现。这使得开发者可以在共享模块中编写通用的逻辑，并在需要与平台交互时，通过 expect/actual 桥梁来实现平台特异性。

四、KMP 的优势

采用 KMP 进行开发，可以带来多方面的优势：

最大化代码共享，提高开发效率： 业务逻辑、数据层、网络层、数据模型等核心代码只需编写一次，可以在多个平台复用，显著减少了重复工作量。据 JetBrains 和社区的实践，可以共享 60% – 80% 甚至更多的非 UI 代码。
确保平台间行为一致性： 共享同一份业务逻辑代码，从根本上消除了因平台实现差异导致的行为不一致问题，提高了产品质量和用户体验。
降低维护成本： bug 修复、功能改进或重构只需在一处（共享模块）进行，修改和测试的工作量大大减少。
保留原生用户体验： KMP 允许每个平台继续使用其成熟的原生 UI 框架（Android 的 Jetpack Compose/Views，iOS 的 SwiftUI/UIKit）。这意味着应用的界面和交互能够充分遵循各平台的设计规范，提供用户熟悉和喜爱的高性能原生体验，避免了某些跨平台框架可能带来的“异物感”或性能瓶颈。
利用 Kotlin 语言的优势： Kotlin 语言本身具有现代、简洁、安全、互操作性好等优点，使用 Kotlin 进行多平台开发，可以充分利用这些语言特性，提高代码质量和开发效率。
增量采纳，风险可控： KMP 项目可以很方便地集成到现有的原生 Android 和 iOS 应用中。你可以选择先将某个模块（如网络层或某个核心业务逻辑）迁移到 KMP 共享模块，逐步扩大共享范围，而无需重写整个应用。这种增量式的迁移方式降低了技术转换的风险。
性能接近原生： KMP 编译到 JVM 或通过 Kotlin/Native 直接编译成二进制代码，其性能表现通常非常接近原生代码。对于计算密集型任务，KMP 的性能远超依赖 JavaScript 虚拟机或解释器的方案。
庞大的 Kotlin 生态系统： 虽然 KMP 生态系统仍在成长，但许多流行的 Kotlin 库已经支持或正在支持 KMP，如 kotlinx.serialization (序列化)、kotlinx.coroutines (并发)、Ktor (网络)、SQLDelight (数据库)、Koin (依赖注入) 等。

五、KMP 的局限性与挑战

没有任何技术是完美的，KMP 也不例外。在采用 KMP 之前，需要了解其潜在的挑战：

UI 层仍需分开开发 (传统模式下): KMP 的核心在于共享逻辑，UI 层传统上是分开开发的。这意味着开发者仍然需要了解并使用 Android 和 iOS 各自的 UI 开发技术。虽然这保证了原生体验，但也意味着 UI 代码本身无法共享。（但请注意：Jetpack Compose Multiplatform 的出现正在改变这一现状，详见下文）
平台互操作性的复杂度： 虽然 Kotlin/Native 提供了与 Objective-C/Swift 的良好互操作性，但在共享代码中调用复杂的原生 API 或库时，可能需要编写一些平台特定的胶水代码，特别是处理数据类型转换、异步调用等。expect/actual 模式在需要大量平台特定功能时，可能会导致 actual 实现的代码量增加。
工具链与生态的成熟度： 尽管 KMP 发展迅速，但相较于成熟的 Android 或 iOS 原生开发环境，KMP 的工具链（IDE 支持、调试器、构建速度等）和第三方库生态系统仍在不断完善中。一些小众的原生库可能还没有 KMP 版本，需要通过平台互操作性桥接，这可能会带来一些额外工作。
构建配置的复杂性： 多平台项目的 Gradle 配置比单平台项目更复杂，尤其是在设置不同的目标、依赖管理、发布共享库等方面，需要一定的学习成本。特别是为 iOS 构建并集成到 Xcode 项目中，有时会遇到一些配置上的挑战。
学习曲线： 对于习惯了单一平台开发的开发者来说，理解 KMP 的多模块结构、expect/actual 机制、Kotlin/Native 的工作原理以及跨平台思维方式需要一定的学习和适应过程。
部分平台特性支持差异： 虽然核心语言和标准库是共享的，但涉及到一些高度依赖平台能力的特性（如文件系统访问、网络请求、传感器、权限管理等），虽然 KMP 提供了对应的多平台 API (如 kotlinx-io, kotlinx-coroutines-core 中的调度器)，但在实现细节或高级用法上可能仍需要通过 expect/actual 或平台特定代码来处理。

六、KMP 生态系统：共享模块的基石

共享模块的强大之处不仅在于语言本身，还在于其不断壮大的多平台库生态。许多重要的功能性库都已经提供了对 KMP 的支持：

kotlinx.serialization: Kotlin 官方提供的序列化库，支持 JSON, Protobuf 等格式，是 KMP 中处理数据模型、网络请求和本地存储的标准方式。
kotlinx.coroutines: Kotlin 官方提供的协程库，用于简化异步编程。它提供了 KMP 支持，可以在不同平台使用相同的协程 API 来管理并发任务，极大地提高了异步代码的可读性和可维护性。
Ktor: JetBrains 开发的异步框架，支持构建客户端和服务器端应用。其客户端部分完全支持 KMP，可以用于在共享模块中处理网络请求。
SQLDelight: Square 开源的 SQL 数据库访问库，可以通过 SQL 语句生成类型安全的 Kotlin 代码。它支持 KMP，使得在共享模块中进行本地数据库操作成为可能。
Realm (MongoDB): 另一个流行的移动数据库，也提供了对 KMP 的支持。
Koin/Kodein: 依赖注入框架，部分支持 KMP，可以在共享模块中管理依赖关系。
Lifecycle/Stateflow (Kotlinx.coroutines): Coroutines 的 StateFlow 和 SharedFlow 非常适合在 KMP 中作为状态管理和数据流的工具。Kotlin 官方也在推动建立多平台生命周期管理机制。

这个生态系统的成熟度直接影响了 KMP 开发的效率。随着更多库的支持，开发者在共享模块中可以完成的功能也越多。

七、KMP 与 Jetpack Compose Multiplatform (Compose MP)

了解 KMP 时，常常会听到 Jetpack Compose Multiplatform。这是需要澄清的一个重要概念：

Kotlin Multiplatform (KMP): 是一种代码共享技术，主要用于共享非 UI 逻辑。它是 Compose MP 的基础。
Jetpack Compose Multiplatform (Compose MP): 是 JetBrains 基于 Google 开源的 Android UI 框架 Jetpack Compose 构建的跨平台声明式 UI 框架。它使用 Kotlin 和 Compose 工具包，旨在让开发者能够使用同一份代码为 Android、iOS、Desktop (Windows, macOS, Linux) 和 Web 构建用户界面。

关系： Compose MP 是构建在 KMP 之上的。它利用 KMP 的多平台能力来编译和运行 UI 代码。当你使用 Compose MP 时，你实际上是在一个 KMP 项目中，将 Compose UI 代码放在共享模块 (commonMain) 中，然后 Compose MP 编译器会将这些声明式 UI 代码编译成对应平台的 UI 元素或渲染指令。

这意味着什么？

如果你只关心共享业务逻辑而希望保留原生 UI，那么你使用 KMP 的核心能力，UI 代码分开写。
如果你希望连 UI 代码也共享，那么你可以使用 Compose MP。在这种模式下，你的共享模块不仅包含业务逻辑，还包含共享的 Compose UI 代码。平台模块主要用于启动 Compose UI 容器、处理平台特定集成等。

Compose MP 的出现极大地扩展了 KMP 的应用场景，让 KMP 不再仅仅是“共享逻辑”，而是向“逻辑 + UI 共享”迈进，成为一个更全面的跨平台解决方案。然而，Compose MP 作为一个相对年轻的技术，其生态和工具仍在快速发展中，尤其是在 iOS 平台的成熟度和性能优化方面。

八、KMP 的典型应用场景

KMP 在多种场景下都能发挥其价值：

移动应用开发 (Android + iOS): 这是 KMP 最主要的应用场景。将网络层、数据存储、业务核心逻辑、数据验证、状态管理等共享，UI 层使用原生技术或 Compose MP。
共享库开发： 构建一个可以被多个平台（移动、后端、桌面、前端）使用的功能库，如一个日期时间处理库、一个加密算法库、一个通信协议实现等。
后端与前端/移动端的数据模型共享： 在 KMP 共享模块中定义数据模型（使用 kotlinx.serialization），后端 (JVM/Native/JS) 和客户端 (Android/iOS/Web) 都可以直接使用这份模型，避免了手动同步模型定义和序列化代码。
桌面应用开发： 结合 Compose Multiplatform，可以为 Windows、macOS 和 Linux 构建拥有现代 UI 的桌面应用。
命令行工具： 使用 Kotlin/Native 可以轻松创建跨平台的命令行工具。

九、如何开始使用 KMP?

开始使用 KMP 并不困难，JetBrains 提供了良好的支持：

安装工具： 确保安装了最新版本的 Android Studio 或 IntelliJ IDEA (Ultimate 版本对 KMP 支持更佳)。确保安装了 Kotlin Plugin。
创建新项目： 在 IDE 中创建新项目时，可以选择 Kotlin Multiplatform Application 或 Kotlin Multiplatform Library 模板。这些模板会帮你自动生成基础的项目结构和 Gradle 配置。
配置 Gradle： 了解 build.gradle.kts (或 build.gradle) 文件，配置目标平台 (targets)、依赖 (dependencies) 和编译选项。
编写共享代码： 在 commonMain 模块中编写与平台无关的业务逻辑、数据模型等。
实现平台特定代码： 在 androidMain、iosMain 等模块中实现 expect 声明，或编写调用平台 SDK 的代码。
集成到原生项目： 对于现有的 Android 和 iOS 项目，可以将 KMP 共享模块构建成 Android AAR 库和 iOS Framework (或 CocoaPod、Swift Package Manager)。然后在各自的原生项目中引用和使用这个库。
构建和运行： 使用 Gradle 命令或 IDE 的构建功能编译 KMP 项目。对于 iOS，通常需要在 Xcode 项目中集成构建好的 Framework。

JetBrains 官方文档和社区资源提供了丰富的教程和示例，帮助开发者入门和解决问题。

十、KMP vs. 其他跨平台方案

简单对比一下 KMP 与一些主流跨平台方案的区别：

原生开发： 最高性能和平台特性访问，但代码冗余，成本最高。KMP 通过共享逻辑降低成本，同时保留原生 UI 的优势。
React Native/Flutter： 提供共享 UI 的能力，开发者主要编写 JavaScript/Dart 代码。性能通常通过桥接或自绘 UI 实现。KMP 侧重共享逻辑，UI 可选原生或 Compose MP，性能更接近原生。KMP 更容易增量集成到现有原生项目。
Xamarin： 使用 C# 编写代码，通过 Mono 运行时和平台绑定的方式实现跨平台。KMP 使用 Kotlin，技术栈与 Android 开发更接近，对 Android 开发者更友好。

KMP 的独特之处在于其灵活性：开发者可以选择共享多少代码（仅逻辑，或逻辑+UI），以及如何集成到现有项目（增量或全新）。它更像是一个“多平台能力”，而不是一个强制的“跨平台框架”。

十一、未来展望

Kotlin Multiplatform 技术正在迅速发展，JetBrains 和社区持续投入资源改进工具链、库生态和文档。特别是 Jetpack Compose Multiplatform 的快速演进，预示着 KMP 在未来不仅是共享逻辑的利器，也可能成为构建真正多平台应用的强大全栈框架。随着技术的成熟和社区的壮大，KMP 有望成为解决多平台开发挑战的主流解决方案之一。

结论

Kotlin Multiplatform (KMP) 是一种革命性的多平台开发技术，它通过允许开发者使用 Kotlin 语言共享核心业务逻辑和非 UI 代码，极大地提高了开发效率，保证了平台间的一致性，并降低了维护成本。与一些传统的跨平台框架不同，KMP 更加灵活，它允许开发者根据需求选择共享的深度，并且能够与各平台的原生 UI 技术无缝集成，从而在效率和原生体验之间取得了良好的平衡。

虽然 KMP 在工具链成熟度和生态系统方面仍在发展，并且面临平台互操作性等方面的挑战，但其核心理念——最大化共享非 UI 代码——以及不断壮大的社区和生态支持，使其成为构建现代化、高效且高性能多平台应用的有力选择。结合 Jetpack Compose Multiplatform 的发展，KMP 正逐步拓展其能力边界，为开发者开启了构建跨越各种设备和平台界限的崭新篇章。如果你正在寻找一种既能提高开发效率又能兼顾原生体验的多平台解决方案，那么 Kotlin Multiplatform 绝对值得深入探索和尝试。