做 Android 久了，面对跨平台需求，心里总会有点抵触。毕竟，从 XML 到 Compose，我们已经习惯了 Android 的原生生态，难道为了跨端就得彻底转向 Flutter 或 React Native，把积累的经验推倒重来吗？其实大可不必。Kotlin Multiplatform (KMP) 正在悄然改变游戏规则：它不碰 UI，只做一件事——让核心业务代码在不同平台间自由流动。这种方式既保留了原生应用的流畅体验，又解决了代码复用的痛点。今天，我们就抛开概念，聊聊如何用 KMP 优雅地重构你的业务逻辑。

一、为什么 KMP 是 Android 工程师的最佳跳板？

回想一下我们的日常开发：同样的登录校验、订单处理逻辑，在 Android 和 iOS 端往往要写两套，不仅费时，后期维护更是噩梦。每次需求变更，都需要同步修改两套代码，测试工作量翻倍，还极易因沟通不畅或理解偏差引入隐蔽 Bug。KMP 的核心思想不是“替代”，而是“共享”。它依托 Kotlin 强大的编译器，允许我们将与平台无关的“纯 Kotlin”代码（我们称之为“业务内核”）抽离出来，编译成不同平台的原生库（如 Android 的 JAR/AAR，iOS 的 Framework），供各自的 UI 层调用。

这种“共享内核，原生 UI”的模式，为 Android 工程师带来了三重独特优势：

1. 技术栈零切换，平滑过渡：你不需要去学 Dart 或 JavaScript。你依然在用最熟悉的 Kotlin，依然可以集成 Jetpack Compose、ViewModel、LiveData/Flow 等原生组件。KMP 的 commonMain 源码就是标准的 Kotlin，支持协程、序列化（kotlinx.serialization）、依赖注入（Koin/Kodein）等生态。这意味着你现有的代码资产和开发经验几乎可以无损迁移，学习成本极低。

2. 守住性能与体验的底线：与 Flutter/RN 自绘 UI 不同，KMP 不插手 UI 渲染。Android 端依然使用原生 View 系统或 Compose，iOS 端使用 SwiftUI 或 UIKit，从而保证了应用能获得各平台最新的系统特性、最流畅的动画交互和最一致的用户体验。对于性能敏感或交互复杂的场景，这是至关重要的优势。

3. 提升工程效率与质量：在实际落地中，核心业务层（领域层、数据层）的复用率通常能达到 70% 以上。JetBrains 的官方案例显示，像 Cash App、VMware 等团队，在业务逻辑上甚至做到了 90% 以上的代码复用。这意味着：

   • 开发提速：功能实现一次，双端同时可用。
   • 维护减负：Bug 修复、逻辑变更只需在一处修改。
   • 质量加固：从根本上杜绝了因双端实现不一致导致的逻辑分歧，保证业务行为统一。
   • 团队协作升级：Android 和 iOS 开发者可以基于同一套 Kotlin 业务 API 进行对接，沟通成本大幅降低。

更重要的是，KMP 的采用是一个渐进的过程。你不需要重写整个应用，可以从一个独立的工具模块（如网络客户端、缓存管理、数据模型）开始，逐步将稳定的业务逻辑下沉。这种低风险的演进路径，让 Android 工程师可以在保障现有项目稳定的前提下，稳步拓展自己的技术边界和能力栈。

所以，KMP 不是让你放弃 Android 转投其他阵营，而是为你装备了一件“跨端复制器”，让你能用最熟悉的武器，去解决更广阔战场上的问题。它是一次高回报、低风险的技术投资。
二、拆解 KMP 项目架构：各司其职才是硬道理

一个成熟的 KMP 工程，关键在于目录结构的清晰划分。我们不需要关心 UI 怎么画，只需要专注于下面这几层的设计：

1. 表现层：坚持原生信仰
位置：androidMain / iosMain
做法：Android 端继续用 Jetpack Compose 或 View System，iOS 端交给 SwiftUI 或 UIKit。这样做的好处是，你能永远调用平台最新的系统 API，动画和交互体验没有任何妥协。
*
2. 桥梁层：抹平平台差异
位置：androidMain / iosMain
核心技术：expect 和 actual 关键字。
场景与示：比如获取设备 ID 或存储本地文件。我们在公共模块定义一个 expect class PlatformStorage()，然后在 Android 端用 SharedPreferences实现（actual），在 iOS 端用 NSUserDefaults实现（actual）。业务层完全不需要知道底层的实现细节。

3. 领域层：业务的归宿
位置：commonMain（这是最重要的部分）
内容：所有的业务逻辑、实体类（Data Class）、用例（Use Cases）都放在这里。
利器：Kotlin Coroutines 和 Flow。这是 KMP 的灵魂。我们可以用协程处理异步任务，用 StateFlow 在共享模块中管理状态，然后在两端的 UI 层去订阅这些状态。

4. 数据层：通用的数据管道
位置：commonMain
选型：网络请求推荐使用 Ktor Client，它天生支持多平台；数据库则首选 SQLDelight，它能生成类型安全的 Kotlin API，比手写 SQL 更安全高效。

三、落地指南：五步开启你的第一个 KMP 模块
如果你已经跃跃欲试，可以按照这个流程在你的现有项目中尝试：
新建模块：在 Android Studio 中使用 KMM Plugin 创建一个新的 Shared Module。
迁移代码：别急着全量迁移。先从最独立的工具类（如日期格式化、校验器）开始，逐步过渡到网络请求和数据模型。
定义接口：遇到需要系统能力的代码（如蓝牙、GPS），使用 expect定义接口，分别在双端实现 actual。
连接 UI：在 Android App 中直接依赖这个 Shared Module，像调用普通 Kotlin 代码一样调用共享逻辑。
持续迭代：随着业务稳定，逐步将更多逻辑下沉到 commonMain，直到达到理想的复用比例。

KMP 并不是为了消灭原生开发，相反，它是原生开发的强力辅助。它让我们从枯燥的重复劳动中解脱出来，将精力集中在真正有价值的产品逻辑上。对于 Android 开发者而言，KMP 是一扇门，推开它，你会发现世界更大了——不仅能守住现有的技术阵地，还能无缝延伸到 iOS 乃至桌面端。与其在技术选型中纠结，不如现在就开始尝试，用 KMP 构建属于你的高效开发闭环。