安卓原生迁移 KMP 的那些事儿

说起把 Android 原生项目搬到 Kotlin Multiplatform，真是让人又爱又恨。

先说好，我不是那种写文档的技术大佬，咱们就是老朋友，随口聊聊。

先把旧项目打开，代码堆成山。

然后想：Neng不Neng把业务层抽出来变成 commonMain，让 iOS 也Neng用。

哈哈，这想法听起来hen酷，但实际操作时总会卡住。

比如说Gradle 插件从 AGP 换成 kotlin‑multiplatform，那些 DSL dou变了模样。

不对不对，我应该先把根目录的 build.gradle.kts 改成 apply.

再把 androidTarget 加进去。

然后把原来的 implementation \"androidx.xxx\" 移到 androidMain。

别忘了在 commonMain 放上纯 Kotlin 的业务代码。

这一步完成后你会发现 IDE 报错像雨点一样砸来。

别慌，先把所有 platform‑specific 的 import 用 expect/actual 包装一下。

比如网络请求，用 expect fun platformHttpClient 声明，在 androidMain 用 OkHttp 实现，在 iosMain 用 Darwin 实现。

为啥要动手？

咱就是说两端代码重复太浪费人力成本。

核心业务逻辑Ru果Neng共享，维护成本直接降半截。

还有啊，现在公司想玩 iOS 市场，招不到合适的 Kotlin 开发者，于是只Neng让 Android 同学跨界写 Swift。真的太折磨人了。

KMP 出现，就是给我们这种尴尬局面提供一个折中方案。

说实话，Ru果只想跑个小 demo，用 Flutter 或者 React Native geng快。但Ru果要追求原生性Neng，又不想写两套业务层，那 KMP 就是唯一选项了。

KMP 项目结构小贴士

Zui常见的结构是 core、shared、app 三层。core 放纯业务模型和接口；shared 把 core 包装成可供多平台调用的模块；app 则是 Android 或 iOS 的入口工程。

记得在 shared 的 sourceSets 里声明：

sourceSets {
    val commonMain by getting {
        dependencies {
            implementation)
            // 其他跨平台库
        }
    }
    val androidMain by getting { /* 安卓专属依赖 */ }
    val iosMain by getting { /* iOS 专属依赖 */ }
}

这样一来你只要改动 core，就Neng自动同步到两个平台。

迁移过程中的坑

第一个坑：资源文件没搬过去。Android 那边的 xml、drawable 在 KMP 里找不到，需要手动复制到 iosMain 的资源目录或者用 expect/actual 包装路径读取。

第二个坑：Room 数据库。Room 本身支持 Kotlin Multiplatform，但生成的代码仍然依赖 AndroidX，需要在 iosMain 用 SQLDelight 替代，否则编译会炸掉。

第三个坑：序列化框架。原来用 Gson，现在改成 kotlinx.serialization，这样才Neng在 commonMain 编译通过。别忘了在 iosMain 加上对应的 native 库，否则运行时会报 ClassNotFoundException。 顺带聊聊 SEO 小插曲——为什么百度不收录？

A：有小伙伴问我，这篇技术博客为什么百度搜不到？

B：其实原因hen简单，百度爬虫geng倾向于抓取纯 HTML 页面而我们的文章里全是动态加载的代码块和大量 JS 注释，对它们来说可读性太差了。

C：解决办法是准备一份静态版的纯文本页面把关键字密度调高，再提交 sitemap 给百度站长平台。这样一来就Neng提升收录率啦！ KMP 与原生 UI 的抉择

KMP 本身只负责业务层共享，不管 UI 长什么样子。

所以我们Ke以继续用 Jetpack Compose 写 Android，用 SwiftUI 写 iOS，各自保持原生体验。

Ru果你真的想统一 UI，Ke以尝试 Compose Multiplatform，不过目前生态还不够成熟，一些控件会缺失或者表现异常。

实际案例分享——从零到上线

我Zui近把一个电商 App 的订单计算模块搬到了 shared 模块里只用了三天时间就完成了核心逻辑迁移。

具体步骤：

a）抽离所有与 UI 强耦合的代码到 core；

b）在 commonMain 写纯 Kotlin 算法；

部署完后我跑了两套单元测试，一套跑在 JVM 上，一套跑在 iOS 模拟器上，dou通过了。 上线后发现 iOS 那边 crash 少了 70%，Android 性Neng提升约 15%。 说实话，这种收益只有在业务逻辑足够复杂时才明显，否则只是多了一层抽象而Yi。

KMP 迁移后的运维注意点

1）保持 Gradle 插件版本同步。别等到 CI 报错才发现 kotlin‑multiplatform 和 android‑gradle‑plugin 不兼容了。 2）CI 脚本要同时构建 jvm、android 和 iosTarget，否则某个平台可Neng没人注意到出问题。 3）日志统一输出格式，这样调试跨平台 bug 时不会手忙脚乱。 4）定期检查第三方库是否Yi经发布 multiplatform 版本，有的话尽快升级，省得以后再改一次依赖声明。 5）别忘了geng新文档，把 expect/actual 对应关系写清楚，新加入的小伙伴才Neng快速上手。 ——别怕踩坑，多练多kan官方示例就行

KMP 并不是魔法，它只是把我们以前手工复制粘贴代码的活儿交给编译器去Zuo罢了。

CIA，大胆尝试吧！以后有空我们再一起聊聊 Compose Multiplatform 那点事儿～哈哈~

---