解读

国内面试场景下，这道题常出现在“跨平台”或“架构演进”环节，面试官想验证三点：

1. 你是否把 KMP 当成“又一个 Flutter/RN”，能否说清它与 Compose Multiplatform、Flutter、RN 的本质差异；
2. 你是否理解 KMP 对现有 Android 工程链路的真实侵入度——Gradle 插件、源码集、Cinterop、expect/actual 机制；
3. 你是否能结合国内合规、双端人力配比、模块复用 ROI 给出落地路径，而不是空谈“一套代码跑全端”。
   答得好，可以直接把话题引到“我们首页业务层 30% 代码已下沉到 KMP commonMain，包体积只涨了 0.8 MB，双端迭代人日节省 25%”——这是面试官最想听到的量化结果。

知识点

1. KMP 技术定位：Kotlin 官方提供的“语言级”跨平台编译链，编译产物为各平台原生二进制（JVM bytecode、Native、JS/Wasm、LLVM），不自带渲染管线，因此与 Flutter 的 Skia 自绘有本质区别。
2. 分层架构：commonMain / androidMain / iosMain / desktopMain 等多源集；expect 声明平台无关 API，actual 在各源集提供平台实现；通过 kotlin.mpp.androidSourceSetLayout 与 AGP 7.0+ 无缝集成。
3. 构建链路：Gradle Kotlin Multiplatform Plugin → KAPT/KSP 生成代码 → Cinterop 把 iOS 系统 Framework 或私有 .a/.h 包装成 Kotlin 接口 → XCFramework 输出供 Xcode 链接；国内上架 App Store 需验证 bitcode 与签名兼容性。
4. 内存与线程模型：Native 端采用 ARC + 周期检测，与 JVM GC 并存；kotlinx.coroutines 1.7+ 提供多线程调度器，但需在 nativeMain 里显式使用 freeze/Worker 机制避免并发冻结；面试常追问“为什么挂起函数在 iOS 会触发 InvalidMutabilityException”。
5. 与 Jetpack 生态关系：ViewModel、Room、WorkManager 仍仅支持 Android；KMP 侧推荐用 SQLDelight、Ktor、Koin-Multiplatform、Apollo-KMP 做网络/数据库/依赖注入；Compose Multiplatform 目前处于 beta，国内落地案例集中在工具类桌面端，手机端仍用原生 UI。
6. 国内合规点：KMP 产物不含 Google GMS，因此华为、荣耀、小米渠道无政策风险；但若 commonMain 里引入 SQLCipher、OpenSSL 等三方 C 库，需走网信安 SDK 备案并出具《密码产品声明》。
7. 技能栈迁移：
   • Gradle 脚本能力从 Groovy 全面转向 Kotlin DSL，需掌握 sourceSets、presets、cinterop 配置；
   • 必须熟悉 Swift/ObjC 的模块映射与头文件搜索路径，才能写 actual 实现；
   • 调试工具链从 Android Studio 扩展到 AppCode/CLion，需掌握 LLDB 与 Kotlin/Native 的 DWARF 符号映射；
   • 性能调优指标新增“二进制体积”与“动态库启动耗时”，需用 bloaty-android 与 Instruments 双重验证。

答案

Kotlin Multiplatform（KMP）是 JetBrains 推出的语言级跨平台方案，它复用 Kotlin 编译器前端，把同一份 common 代码编译成各平台原生指令：Android 侧为 JVM bytecode，iOS 侧为 LLVM 静态库或 XCFramework，桌面侧为 Native 或 JVM。与 Flutter 的自绘渲染不同，KMP 只共享业务逻辑与数据层，UI 仍由各自原生框架实现，因此包体积增量小、性能损耗接近 0，且能直接调用平台私有 API，天然适合国内“双端原生迭代 + 核心逻辑复用”的场景。
对 Android 开发者而言，KMP 把技能栈从“纯 Android Jetpack”推向“双端底层通吃”：

1. 构建脚本必须掌握 Kotlin DSL 与 MPP 插件，熟悉 presets、sourceSets、Cinterop 配置；
2. 代码组织需理解 expect/actual 机制，能写平台无关接口并在 iOS 侧用 Swift/ObjC 实现；
3. 并发模型要掌握 Kotlin/Native 的冻结与 Worker 机制，避免挂起函数在多线程场景触发 InvalidMutabilityException；
4. 调试与性能工具从单一的 Android Studio Profiler 扩展到 Instruments、LLDB、bloaty-android，需同时关注二进制体积与动态库启动耗时；
5. 第三方库选型从 Jetpack 迁移到 SQLDelight、Ktor、Koin-Multiplatform 等支持 KMP 的替代品；
6. 合规层面需额外走 SDK 备案，尤其是引入 C 加密库时出具《密码产品声明》。
   落地路径上，国内团队通常采用“数据层+网络层”先行下沉，commonMain 占比 30% 即可节省 20–30% 双端人力，包体积增量控制在 1 MB 以内；UI 层与系统能力仍保持原生，以通过厂商安全审核与折叠屏适配。掌握 KMP 后，Android 开发者不再只是“Android 专家”，而是“移动跨平台架构师”，在简历与面试中可直接量化“复用率、包体积、迭代人日”三大指标，形成差异化竞争力。

拓展思考

1. 如果公司明年计划把视频编解码算法下沉到 KMP，你会如何设计 Cinterop 层，以保证 NEON 指令在 iOS 侧与 ARM64 Android 侧零损耗调用？
2. 国内厂商要求 SDK 必须提供符号表以便国安溯源，KMP 生成的 XCFramework 默认裁剪了 DWARF，你如何在 release 构建中保留符号并单独上传？
3. 当 commonMain 依赖的 SQLDelight 升级 2.0，生成代码把 kotlinx.coroutines 升级到 1.8，而 Android 主工程仍停留在 1.6，你会用哪种 Gradle 特性隔离版本冲突？