Kotlin Multiplatform Mobile — 什么是它，关键概念及KMM架构

什么是Kotlin Multiplatform Mobile？

Kotlin Multiplatform Mobile（KMM）——是一种技术，允许用Kotlin编写移动应用程序的通用业务逻辑，并在iOS和Android上使用它而无需重复代码。与Ionic或Cordova不同，KMM不在WebView中渲染界面——UI完全保持原生，并在SwiftUI（iOS）和Jetpack Compose（Android）中编写。

KMM于2019年由JetBrains作为Kotlin Multiplatform战略的一部分宣布。与其他跨平台解决方案的关键区别在于——该框架不试图统一UI，而是专注于共享那些对两个平台真正相同的代码：网络请求、数据模型、表单验证、业务规则和数据库操作。

根据JetBrains Developer Survey（2025），14%的移动开发者使用KMM，并且这一比例每年增长5%。该技术被对性能和原生用户体验有高要求的公司所选择，对于它们来说，混合解决方案是不可接受的。

KMM架构：shared模块和平台实现

KMM架构由三个模块组成：shared（Kotlin中的共享代码）、iosApp（Swift中的原生iOS应用程序）和androidApp（Kotlin中的原生Android应用程序）。Shared模块编译为Android的JAR和iOS的通用框架（Apple Framework）。

Shared模块：什么纳入共享代码

Shared模块包含所有独立于平台的层：网络层基于Ktor Client，通过kotlinx.serialization进行序列化的数据模型，用于数据管理的存储库，表单验证和业务规则（例如，计算运费或检查访问权限）。

Shared模块使用Gradle Multiplatform Plugin，并包含三个源代码集：commonMain（共享代码）、androidMain（Android特定实现）和iosMain（iOS特定实现）。Kotlin/Native编译器将共享代码转换为iOS的原生库，通过XCFramework连接到Swift项目。

平台模块

Android模块——是使用Jetpack Compose或ViewBinding的Kotlin标准Android应用程序。Shared模块作为普通的Gradle依赖项连接，commonMain中的所有类都直接可用。

iOS模块——是Swift或Objective-C的Xcode项目。Shared模块通过CocoaPods、Swift Package Manager或XCFramework连接。Kotlin/Native生成Objective-C头文件以导出Kotlin类型，使它们可以从Swift访问。

KMM中的expect/actual机制

expect/actual——是Kotlin Multiplatform的一种机制，允许在共享代码中声明API（expect declaration），并为每个平台单独提供其实现（actual declaration）。编译器确保每个目标平台都存在相应的actual。

expect/actual的典型使用场景：获取考虑时区的当前时间，使用SharedPreferences（Android）/ UserDefaults（iOS），加密函数和UUID生成。在每个平台上使用自己的系统API。

没有expect/actual，就不可能拥有统一的业务逻辑代码，因为用于文件系统、网络和存储的API在iOS和Android之间在系统调用级别上有所不同。该机制确保开发人员不会忘记实现平台部分。

对于平台调用，如相机或生物识别，KMM提供expect/actual库，结合类似Cordova的插件，但在Kotlin/Native中。JetBrains还发布了kotlinx-datetime库，用于抽象日期处理。

KMM代码示例

让我们看一下KMM项目的基本结构，包括用于生成UUID的expect函数声明及其在iOS和Android上的实现。

// commonMain——通用声明
expect fun generateUUID(): String

// androidMain——Android实现
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain——iOS实现
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

在共享代码中声明expect fun generateUUID()。对于Android使用java.util.UUID，对于iOS使用Foundation框架中的NSUUID。在shared模块的其余代码中，此函数被调用时不考虑平台。

在共享代码中使用Ktor Client进行网络请求的示例：

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

这段代码在两个平台上都无需修改即可运行。Ktor Client在Android上自动使用OkHttp，在iOS上自动使用NSURLSession，无需额外配置。通过kotlinx.serialization进行的JSON序列化也是跨平台的。

KMM与Flutter和React Native的比较

KMM在跨平台技术中占有独特地位，因为与Flutter和React Native不同，它不试图取代原生UI。KMM——是用于共享逻辑的解决方案，而不是用于统一界面。

KMM的主要优势——对UI的完全控制。如果应用程序需要在每个平台上看起来和行为都像原生（例如，使用带有平台动画的iOS TabBar和Android BottomNavigation），KMM是唯一无需变通方法即可实现这一点的跨平台解决方案。

缺点——团队必须同时掌握Kotlin、Swift、Jetpack Compose和SwiftUI，这增加了招聘难度。Flutter和React Native只需要掌握一种语言和一个框架。

KMM实施的优点和挑战

Kotlin Multiplatform Mobile——是一项强大的技术，但其实施需要平衡的方法。让我们看看团队面临的关键优势和典型挑战。

KMM的优点

第一个也是最重要的优点——减少代码重复。根据JetBrains Case Studies（2024），实施KMM的团队将网络层的重复代码量减少60–80%，将整体业务逻辑的重复代码减少40–50%。这直接影响开发速度和错误数量。

第二个优点——原生应用程序级别的性能。与混合框架不同，KMM不会在UI和系统之间添加抽象层。业务逻辑代码的执行速度与分别为每个平台用Swift或Kotlin编写时一样快。

实施挑战

主要挑战——团队资质。开发者必须掌握Kotlin（用于shared模块）以及Swift和Jetpack Compose（用于UI）。找到全能型专家很困难，因此通常由Android和iOS开发者组成团队共同管理shared模块。

第二个挑战——工具。KMM需要配置Gradle、CocoaPods或Swift Package Manager，以及与Xcode的集成。在项目的早期阶段，构建配置问题很常见，尤其是在使用C库时。

第三个挑战——调试。当错误出现在Kotlin/Native和Swift的交界处时，确定其原因比在单体应用程序中更困难。JetBrains不断改进调试工具，但在实践中，团队不得不花费高达20%的时间在基础设施任务上。