Kotlin Multiplatform：为 iOS、Android 及更多平台构建应用 – wiki基地

作者： /

Kotlin Multiplatform：跨越边界，为 iOS、Android 及更多平台构建应用的未来

在当今快速发展的软件开发领域，覆盖尽可能多的用户和平台是许多企业和开发团队的核心目标。然而，为不同的平台（如 iOS 和 Android）独立开发和维护应用程序，往往意味着代码重复、资源浪费、功能不同步以及更高的维护成本。多年来，业界一直在探索各种跨平台解决方案，从早期的 Web 封装技术到后来的 React Native、Flutter 等框架，每种方案都有其优势和权衡。近年来，由 JetBrains 推出并积极发展的 Kotlin Multiplatform (KMP) 提供了一种新颖且强大的方法，它专注于共享业务逻辑而非 UI，旨在实现代码复用、原生性能和卓越开发者体验的平衡。本文将深入探讨 Kotlin Multiplatform 的概念、优势、工作原理、实际应用以及它为跨平台开发带来的变革。

一、 什么是 Kotlin Multiplatform (KMP)？

Kotlin Multiplatform (KMP) 是 Kotlin 语言的一项特性，允许开发者使用 Kotlin 编写可在多个目标平台上运行的代码。与一些试图用一套 UI 代码库覆盖所有平台的框架不同，KMP 的核心理念是共享非 UI 相关的代码，例如：

  1. 业务逻辑 (Business Logic): 应用程序的核心规则、计算、数据处理流程等。
  2. 数据层 (Data Layer): 数据模型（DTOs）、数据源接口、仓库 (Repositories)、网络请求 (Networking)、数据序列化/反序列化、本地缓存逻辑等。
  3. 表示逻辑 (Presentation Logic): ViewModel 或 Presenter 中的部分逻辑，特别是状态管理和与数据层的交互。
  4. 领域模型 (Domain Model): 应用核心概念的抽象表示。
  5. 通用工具和算法 (Utilities & Algorithms): 日期处理、字符串操作、加密、自定义算法等不依赖特定平台的代码。

KMP 项目通常包含以下类型的模块：

  • commonMain 模块: 包含纯 Kotlin 代码，不依赖任何特定平台 API。这是代码共享的核心区域。
  • 平台特定模块 (androidMain, iosMain, jsMain, jvmMain, nativeMain 等): 包含针对特定平台的 Kotlin 代码。这些模块可以访问各自平台的原生 API，并可以实现 commonMain 中定义的预期声明（expect declarations）。

KMP 的编译过程会将 commonMain 中的代码以及相应的平台特定模块代码，编译成对应平台可以理解和执行的格式：

  • Android: 编译成 JVM 字节码，可以像普通的 Kotlin/Java 库一样集成到 Android 应用中。
  • iOS: 通过 Kotlin/Native 编译器，将 Kotlin 代码编译成原生的二进制代码（通常是 Objective-C 或 Swift 框架），可以直接在 iOS 项目中调用。
  • Web: 通过 Kotlin/JS 编译器，将 Kotlin 代码编译成 JavaScript，可在浏览器或 Node.js 环境中运行。
  • 桌面 (Desktop): 编译成 JVM 字节码（可与 Compose for Desktop 结合）或原生可执行文件 (Kotlin/Native)。
  • 服务器端 (Server-side): 编译成 JVM 字节码 (Kotlin/JVM)，可用于构建后端服务（例如使用 Ktor 框架）。

关键在于，KMP 允许开发者选择性地共享代码。你可以只共享数据模型和网络层，也可以共享整个业务逻辑层，甚至结合 Compose Multiplatform 实现跨平台 UI（但这超出了 KMP 核心的范畴，是另一个强大的技术栈）。这种灵活性使得 KMP 既适用于从头开始构建的新项目，也适用于逐步引入到现有的原生应用中。

二、 为什么选择 Kotlin Multiplatform？—— KMP 的核心优势

采用 KMP 进行跨平台开发带来了诸多显著的好处：

  1. 显著的代码共享与效率提升: 这是 KMP 最直接的价值。通过在 commonMain 中编写一次核心逻辑，可以避免在 iOS (Swift/Objective-C) 和 Android (Kotlin/Java) 中重复实现相同的功能。这不仅减少了初始开发时间，还极大地降低了后续维护成本——修复一个 Bug 或添加一个新特性只需修改共享代码库，所有平台都能受益。代码库的减少也意味着更少的测试工作量和更低的潜在错误率。据一些采用 KMP 的团队报告，可以共享高达 50%-70% 的非 UI 代码。

  2. 保持原生性能与用户体验: 与一些使用 WebView 或自定义渲染引擎的跨平台方案不同，KMP 并不强制共享 UI 层。应用程序的界面（View 层）仍然使用各自平台的原生技术栈构建（例如 Android 的 Jetpack Compose 或 XML/View 体系，iOS 的 SwiftUI 或 UIKit）。这意味着用户可以获得完全符合平台规范、流畅自然的交互体验和最佳性能，避免了非原生 UI 可能带来的卡顿、不一致或平台特性缺失的问题。

  3. 利用 Kotlin 语言的先进特性: Kotlin 是一种现代、简洁、安全且富有表现力的编程语言。选择 KMP 意味着你可以在所有目标平台上享受 Kotlin 带来的好处，包括：

    • 空安全 (Null Safety): 在编译时消除空指针异常的风险。
    • 协程 (Coroutines): 以简洁、高效的方式处理异步编程，非常适合处理网络请求、数据库操作等耗时任务。KMP 提供了跨平台的协程支持。
    • 扩展函数 (Extension Functions): 无需继承即可为现有类添加新功能。
    • 数据类 (Data Classes): 轻松创建用于持有数据的类。
    • 函数式编程特性: 支持 Lambda 表达式、高阶函数等。
    • 与 Java 的良好互操作性 (JVM Target): 在 Android 平台上无缝集成。
    • 与 Objective-C/Swift 的互操作性 (Native Target): Kotlin/Native 提供了生成框架并与 Apple 平台代码交互的能力。

  4. 灵活的架构与渐进式采用: KMP 并非“要么全有，要么全无”的方案。你可以根据项目需求，决定共享哪些部分的代码。对于已有的大型原生应用，可以先从共享一小部分逻辑（如网络请求或数据模型）开始，逐步将更多通用逻辑迁移到共享模块中，风险可控。这种灵活性使得 KMP 适用于各种规模和阶段的项目。

  5. 统一的技术栈与团队协作: 对于已经在使用 Kotlin 进行 Android 开发的团队来说，引入 KMP 可以让团队成员更容易地参与到 iOS 或其他平台的逻辑开发中，减少了学习新语言（如 Swift）的认知负荷。虽然仍需了解目标平台的特定知识，但核心逻辑使用同一种语言编写，有助于知识共享和团队协作。

  6. 强大的生态系统与 JetBrains 的支持: Kotlin 由 JetBrains 开发并大力支持，JetBrains 拥有丰富的 IDE 和开发者工具经验（如 IntelliJ IDEA, Android Studio）。KMP 的工具链正在不断完善。同时，围绕 KMP 的生态系统也在快速成长，涌现出许多优秀的跨平台库，例如：

    • Ktor: 用于构建异步客户端和服务器的网络框架。
    • kotlinx.serialization: 用于 Kotlin 对象与 JSON、Protobuf 等格式之间序列化的库。
    • SQLDelight: 生成类型安全的 Kotlin API 来操作 SQL 数据库。
    • Realm Kotlin SDK: 提供跨平台的移动数据库解决方案。
    • kotlinx-datetime: 提供跨平台的日期和时间处理能力。
    • Multiplatform Settings: 简单的键值存储库。
    • Koin / Kodein-DI: 依赖注入框架。

  7. 面向未来: Kotlin 语言本身在不断发展，其应用范围已从 Android 扩展到服务器端、Web 前端、数据科学等多个领域。投资于 Kotlin 和 KMP 技术栈，可能为未来的技术选型和扩展带来更多可能性。

三、 Kotlin Multiplatform 是如何工作的？—— 技术原理剖析

理解 KMP 的工作机制，需要关注以下几个关键概念：

  1. expect 和 actual 机制: 这是 KMP 实现平台特定功能的核心。当共享代码 (commonMain) 需要访问某个特定于平台的功能（例如获取设备唯一标识符、文件系统访问、日期格式化等平台相关行为）时，它会声明一个 expect 类、函数、属性或注解。这个声明只定义了 API 的“期望”形态，没有具体实现。

    kotlin
    // In commonMain
    expect fun generateUUID(): String
    expect class PlatformSpecificData() {
    fun getInfo(): String
    }

    然后，在每个支持的平台特定模块（如 androidMain, iosMain）中，必须提供对应的 actual 实现。actual 实现会使用该平台的原生 API 来完成 expect 声明所要求的功能。

    “`kotlin
    // In androidMain
    import java.util.UUID
    actual fun generateUUID(): String = UUID.randomUUID().toString()
    actual class PlatformSpecificData {
    actual fun getInfo(): String = “Android Platform Info: ${android.os.Build.VERSION.SDK_INT}”
    }

    // In iosMain
    import platform.Foundation.NSUUID
    actual fun generateUUID(): String = NSUUID().UUIDString()
    actual class PlatformSpecificData {
    actual fun getInfo(): String = “iOS Platform Info: ${platform.UIKit.UIDevice.currentDevice.systemVersion}”
    }
    “`

    编译器会确保 commonMain 中的 expect 声明在所有目标平台都有对应的 actual 实现。这样，commonMain 中的代码就可以像调用普通函数或类一样调用 expect 声明，而 KMP 工具链会在编译时将其链接到对应平台的 actual 实现上。

  2. 项目结构与 Gradle 配置: KMP 项目通常使用 Gradle 作为构建工具。项目结构清晰地分离了共享代码和平台特定代码。一个典型的 KMP 库模块结构可能如下：

    my-shared-library/
    ├── build.gradle.kts
    └── src/
    ├── commonMain/
    │ └── kotlin/
    │ └── com/example/common/CommonCode.kt
    ├── androidMain/
    │ ├── AndroidManifest.xml
    │ └── kotlin/
    │ └── com/example/android/PlatformSpecificAndroid.kt
    ├── iosMain/
    │ └── kotlin/
    │ └── com/example/ios/PlatformSpecificIOS.kt
    └── ... (jvmMain, jsMain, etc. if needed)

    build.gradle.kts 文件是配置 KMP 的关键。在这里，你需要定义目标平台（targets）、源集（sourceSets）之间的依赖关系，以及如何编译和打包每个平台的产物（例如为 Android 生成 AAR 文件，为 iOS 生成 Framework）。

  3. Kotlin/Native: 这是 KMP 支持 iOS、macOS、Linux、Windows 等原生平台的关键技术。Kotlin/Native 使用 LLVM 后端将 Kotlin 代码直接编译成目标平台的机器码，无需虚拟机。它提供了与 C、Objective-C 的互操作性，使得 Kotlin 代码可以调用原生库，反之亦然。对于 iOS 开发，Kotlin/Native 会生成一个标准的 iOS Framework，可以方便地集成到 Xcode 项目中，供 Swift 或 Objective-C 代码调用。

  4. 并发模型: Kotlin Coroutines 是 KMP 中处理并发和异步操作的首选方式。kotlinx.coroutines 库提供了跨平台的实现。然而，在与原生平台交互时，尤其是在 iOS 上，需要注意线程模型和并发处理的差异。Kotlin/Native 早期有较严格的内存管理和并发模型，虽然新版内存管理器（默认启用）大大简化了跨线程对象共享，但开发者仍需理解如何在 Kotlin 协程与 iOS 的 Grand Central Dispatch (GCD) 或 Swift 的 async/await 之间进行转换和交互。通常，共享模块会暴露挂起函数（suspend fun），在 iOS 端通过特定的转换机制（如使用 KMP-NativeCoroutines 库或手动包装）将其适配为 Swift 的 async/await 或带有回调的函数。

四、 在 iOS 和 Android 上构建 KMP 应用

让我们具体看看 KMP 在最常见的移动平台 iOS 和 Android 上的应用流程：

  1. 创建共享模块: 使用 IntelliJ IDEA 或 Android Studio 中的 KMP 模板创建一个新的共享模块，或者在现有项目中添加 KMP 支持。定义 commonMain 源集，并根据需要添加 androidMain 和 iosMain 源集。

  2. 编写共享代码: 在 commonMain 中实现业务逻辑、数据模型、网络请求、数据库交互等。使用 expect/actual 处理平台差异。利用跨平台库简化开发。

  3. Android 集成:

    • 在 Android 应用模块的 build.gradle.kts 文件中，将共享模块添加为依赖项 (implementation(project(":shared")))。
    • 共享模块会被编译成一个标准的 Android 库 (AAR)。
    • 在 Android 的 Activity, Fragment, ViewModel 中，可以直接像调用其他 Kotlin/Java 库一样，导入并使用共享模块中的类和函数。
    • 可以使用 Jetpack Compose 或 XML 来构建 UI，并从 ViewModel 调用共享逻辑。

  4. iOS 集成:

    • 配置 Gradle 任务以将共享模块编译成 iOS Framework。可以选择生成通用框架（支持模拟器和真机）或特定架构的框架。
    • 集成方式:
      • CocoaPods: 可以配置 Gradle 将生成的 Framework 发布为一个本地 Pod 或远程 Pod，然后在 iOS 项目的 Podfile 中依赖它。这是目前比较流行和方便的方式。
      • 直接链接 Framework: 手动将生成的 .framework 文件拖入 Xcode 项目，并配置好链接和嵌入设置。
      • Swift Package Manager (SPM): KMP 对 SPM 的支持正在逐步完善，未来可能成为更主流的选择。
    • 在 Swift/Objective-C 中调用 Kotlin 代码:
      • Xcode 会识别 Framework 中的 Kotlin 类和函数（它们会被暴露为 Objective-C 兼容的接口）。
      • 基本数据类型、集合等通常能良好地映射。
      • 对于 Kotlin 协程（挂起函数），需要进行转换。可以使用社区库如 KMP-NativeCoroutines 自动生成 async/await 兼容的 Swift 接口，或者手动编写包装器将 suspend 函数转换为接受回调或返回 Combine Publisher / async 函数的形式。
      • 注意处理 Kotlin 的 sealed class 和 enum 在 Swift 中的映射。
    • 使用 SwiftUI 或 UIKit 构建原生 iOS UI，并通过 ViewModel 或 Presenter 调用从共享框架暴露出来的 Kotlin 逻辑。

五、 KMP 的适用场景与局限性

理想场景:

  • 需要同时开发 iOS 和 Android 应用，且有大量共享业务逻辑、数据处理或网络交互的应用。
  • 希望最大化代码复用，同时保证原生 UI/UX 和性能。
  • 团队熟悉 Kotlin 语言，特别是已有 Android 开发背景的团队。
  • 需要逐步将共享逻辑引入现有大型原生项目的场景。
  • 希望将逻辑扩展到 Web、桌面或服务器端的项目。

需要考虑的挑战与局限性:

  • 学习曲线: 虽然核心是 Kotlin，但开发者仍需理解 KMP 的项目结构、expect/actual 机制、Gradle 配置以及 Kotlin/Native 的工作原理和与目标平台的互操作性细节。
  • 工具链成熟度: KMP 的工具链（尤其是 Kotlin/Native 和 iOS 集成方面）虽然发展迅速，但相较于纯原生开发或一些更成熟的跨平台方案，可能在某些方面（如构建速度、调试体验、IDE 集成）还有提升空间。
  • 生态系统: 虽然核心库很强大，但某些特定功能的跨平台库可能仍在发展中或尚未出现，有时需要自己编写 expect/actual 实现。
  • iOS 集成复杂性: 相对于 Android 集成（同为 Kotlin/JVM 生态），将 Kotlin/Native 编译的 Framework 集成到 Xcode 项目并处理好互操作性（尤其是异步代码）会更复杂一些。
  • 需要原生平台知识: KMP 共享的是逻辑，UI 仍需原生开发。因此团队中仍需要具备 iOS (Swift/UIKit/SwiftUI) 和 Android (Kotlin/Compose/XML) 的开发能力。
  • 编译时间: 多目标编译可能会增加项目的整体构建时间。

六、 超越移动：KMP 的更广阔前景

KMP 的能力并不仅限于 iOS 和 Android。它的多目标编译能力开启了更广泛的可能性：

  • Web 前端 (Kotlin/JS): 可以将数据模型、验证逻辑甚至部分 ViewModel 逻辑共享给使用 React, Vue, Angular 或 Compose for Web 构建的 Web 应用。
  • 桌面应用 (Compose Multiplatform for Desktop): 结合 Jetpack Compose 的跨平台能力，KMP 可以实现不仅共享逻辑，还共享大部分 UI 代码，构建运行在 macOS, Windows 和 Linux 上的桌面应用。
  • 服务器端 (Kotlin/JVM): 与 Ktor 等框架结合，可以在服务器端重用移动应用中的数据模型、验证规则等，实现前后端代码共享。

这种跨越移动、Web、桌面和服务器端的能力，使得 KMP 成为构建全栈应用和统一技术生态的有力工具。

七、 结论：拥抱 Kotlin Multiplatform，迎接务实的跨平台未来

Kotlin Multiplatform 不是又一个试图用一套代码完全取代原生开发的“银弹”，而是一种更加务实和灵活的跨平台开发策略。它精准地抓住了跨平台开发的核心痛点——逻辑重复，并通过共享非 UI 代码，在代码复用、开发效率、原生体验和性能之间取得了巧妙的平衡。

KMP 赋予开发者选择权：共享多少，取决于项目的具体需求。它让开发者能够继续利用各个平台的最佳原生 UI 技术，同时享受 Kotlin 语言的现代特性和共享逻辑带来的巨大优势。虽然 KMP 仍在不断发展成熟，面临一些挑战，但其强大的潜力、JetBrains 的持续投入以及日益壮大的社区和生态系统，都预示着它将在未来的软件开发领域扮演越来越重要的角色。

对于希望在保持原生质量的同时，提高开发效率、降低维护成本、统一技术栈的团队而言，Kotlin Multiplatform 提供了一个值得深入研究和采用的强大选项。它正在重新定义我们构建跨平台应用的方式，引领着一个代码共享更智能、开发体验更统一、应用质量不妥协的新时代。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部