1. 为什么KMP会出现在面试题里——先搞懂技术背景和市场需求过去一年我面过不少安卓岗位也帮朋友做模拟面试发现一个很明显的趋势Kotlin Multiplatform简称KMP不再只是技术大会上的概念而是切切实实进入了面试官的题库。我最早接触KMP是2022年底那会儿社区讨论还停留在“能不能用”“坑多不多”的阶段到2023年下半年已经有公司把KMP作为跨平台方案的备选项写进技术规划甚至有小团队已经上线了KMP混合开发的App。如果你的简历里出现“跨平台”“代码共享”“Kotlin”这些词面试官大概率会追问一句“KMP你了解多少和Flutter、RN比怎么选”问得深一点的还会直接扔一个场景题登录模块的校验逻辑怎么在双端复用网络层封装怎么做平台差异化很多安卓开发对KMP有误解觉得它是“又要学一套新框架”。实际上KMP的核心理念不是让你重新发明轮子而是把业务逻辑层——数据校验、状态管理、网络请求、持久化——用Kotlin统一实现UI层仍然走各自平台的原生方案。这一点对安卓工程师非常友好因为Kotlin本来就是安卓开发的第一语言你不需要切换语言只需要理解“如何划分共享边界”。面试里如果你能把这一点讲清楚就已经胜过了80%只背概念的人。这篇文章的内容来自我自己的KMP实践笔记和面试复盘。我不是要给你一份面试八股文而是想带你过一遍KMP到底怎么落地、代码边界怎么切、哪些地方容易翻车、面试官真正会追问哪些细节。想要在简历上写KMP或者正在准备安卓面试的朋友这篇值得认真看两遍。2. KMP的技术核心共享代码的边界怎么划2.1 三层架构commonMain / androidMain / iosMain第一次接触KMP项目最容易懵的是目录结构。官方脚手架创建出来的项目默认有三个源集commonMain、androidMain、iosMain加上各自的测试源集。理解这三个目录的职责基本就理解了KMP的一半。commonMain放的是不依赖任何平台的纯Kotlin代码比如数据模型data class、业务校验逻辑、接口定义、使用expect声明的抽象。这里的代码原则是“只使用Kotlin标准库和跨平台库”。androidMain和iosMain则放平台相关实现包括actual实现、平台API调用、第三方SDK接入。我在第一版项目里犯过一个典型错误试图把Room数据库也塞进commonMain。理论上Room从2.5.0开始支持KMP但在当时版本下实际跑起来折腾了三天最后还是退回androidMain单独用Room、iosMain用SQLDelight的方案。这件事给我的教训是架构上哪层放什么不能只看技术可行性还要考虑团队维护能力和当前项目阶段。即使官方支持也不代表你立刻就要用。2.2 expect/actual机制跨平台抽象的真正解法expect和actual是KMP最核心的语言级机制。简单说你在commonMain里写一个函数声明不写实现然后在每个平台源集里写对应的actual实现。这个机制很像接口但比接口更彻底——它不光能抽象函数还能抽象属性、类、注解甚至连object单例都能做。举个例子获取设备唯一标识// commonMain expect fun getDeviceId(): String // androidMain actual fun getDeviceId(): String { return Settings.Secure.getString( context.contentResolver, Settings.Secure.ANDROID_ID ) } // iosMain actual fun getDeviceId(): String { return UIDevice.currentDevice.identifierForVendor?.UUIDString ?: unknown }看起来很简单对吧但里面有个大坑expect声明的函数在commonMain里被调用时Kotlin/Native编译期会对不上平台API的差异。如果两个平台返回类型不一致需要做类型映射。面试官特别喜欢在这里设陷阱——比如问你“expect/actual和依赖注入有什么区别”“如果Android的actual实现需要Context怎么办”。第二个问题的经典解法是不要直接传Context而是用一个接口封装在App启动时初始化。比如定义PlatformContextProviderAndroid端传入ApplicationiOS端传入一个空实现。这样你可以在commonMain里安全地调用expect fun getPlatformContext(): PlatformContext而不用把平台对象暴露给共享逻辑。这个方法我在面试中讲出来时面试官明显眼睛亮了一下。2.3 网络层与数据解析Ktor kotlinx.serialization组合KMP项目里网络层几乎标配Ktor Client因为Ktor本身就是Kotlin官方出的跨平台HTTP客户端。配合kotlinx.serialization做JSON解析可以让网络请求和模型类老老实实待在commonMain里两端共用一套代码。这一步是整个KMP实践中最能直接感受到“爽”的地方同样的接口返回结构Android和iOS都不用各写一套解析代码。但这里有个细节很多人没注意Ktor Client在不同平台的引擎不同Android上通常是OkHttpiOS上是Darwin引擎。引擎的差异会导致部分参数表现不一致。比如超时时间设置在HttpTimeout插件里两端表现基本一致但连接池复用策略、DNS解析行为Android和iOS就有区别。我的习惯是把网络层公共配置超时时间、重试机制、Header注入统一写在commonMain的HttpClient工厂函数里但保留一个platformConfig扩展点让两端按需微调。// commonMain expect fun platformHttpClientConfig(): HttpClientConfig*.() - Unit fun createHttpClient(): HttpClient { return HttpClient { install(ContentNegotiation) { json(Json { ignoreUnknownKeys true explicitNulls false }) } install(HttpTimeout) { requestTimeoutMillis 15_000 connectTimeoutMillis 10_000 } expectSuccess true platformHttpClientConfig() } }数据解析这块kotlinx.serialization比Gson要严格得多。如果你之前在Android上用Gson习惯了SerializedName注解切到KMP要注意SerialName的语义虽然类似但ignoreUnknownKeys默认是false所以后端多返回字段直接崩给你看。我第一次接老项目接口时就因为这个线上炸了一回后来才把这两行配置写死在项目里谁都不许改。3. 从零搭建一个KMP项目实操流程全记录3.1 工程初始化与Gradle配置先别急着写代码你得搞明白KMP的构建基础。最常见的项目形态是先用Android空的单模块工程跑通再逐步把共享逻辑抽取到独立模块。还有一种是直接用官方KMP Wizard生成多模块项目里面已经有shared模块和Compose Multiplatform的依赖。我推荐第二种起步方式——官方脚手架能规避90%的“Gradle配置地狱”。踏踏实实把生成的项目结构看懂比从零配Gradle省一星期时间。生成之后的第一件事不是改代码而是跑通双层构建./gradlew :shared:assembleDebug和iOS端的linkDebugFrameworkIosSimulatorArm64。如果这两个任务都过了说明你的KMP环境基本OK。Gradle配置里最关键的一个坑是Kotlin版本对齐。KMP对Kotlin版本非常敏感Ktor、kotlinx.serialization、Compose Multiplatform这些库的版本都必须和Kotlin版本兼容。我吃过最大的亏是Kotlin 1.9.20配Ktor 2.3.5编译倒是能过但一跑iOS测试就各种UnsupportedOperationException。后来对齐到官方版本矩阵才消停。结论先看依赖库的版本说明文档再挑Kotlin版本没有把握就用脚手架默认版本不要自己乱升。3.2 编写共享模块从登录校验到业务闭环我拿一个登录模块做例子讲清楚shared模块怎么组织。需求很简单手机号验证码登录客户端拿到验证码后提交后端返回token和用户资料。放在纯Android项目里这个流程大概要写Activity、ViewModel、Repository三个类。在KMP里ViewModel和Repository可以挪到commonMainActivity只负责UI和调用ViewModel。共享模块里要做的核心事情是状态管理。官方推荐用StateFlow它的跨平台支持很完善Android端可以配合Google的ViewModel使用iOS端也有相应的Collector桥接方案。我常用的模式是commonMain里定义业务状态Sealed类配合StateFlow暴露状态平台侧只订阅状态渲染UI。// commonMain sealed class LoginUiState { data object Idle : LoginUiState() data object Loading : LoginUiState() data class Success(val userInfo: UserInfo) : LoginUiState() data class Error(val message: String) : LoginUiState() } class LoginViewModel(private val repository: LoginRepository) { private val _uiState MutableStateFlowLoginUiState(LoginUiState.Idle) val uiState: StateFlowLoginUiState _uiState.asStateFlow() fun requestCode(phone: String) { val validateResult PhoneValidator.validate(phone) if (!validateResult.isValid) { _uiState.value LoginUiState.Error(validateResult.message) return } viewModelScope.launch { _uiState.value LoginUiState.Loading // 调用网络接口 } } }重点是校验逻辑和网络请求全部复用。安卓端接入理论上只写UI绑定iOS端也是。我自己做完这一套发现共享代码行数占比能到60%左右还不算上面向UI的部分。面试里提到这个数字不仅展示你有真实经验还说明你关注落地效果。3.3 平台端接入Android和iOS如何消费共享模块Android端接入KMP共享模块非常顺滑因为本质就是依赖一个Android Library。你在build.gradle.kts里依赖shared模块然后Activity/Fragment里得到LoginViewModel的实例收集StateFlow更新UI。需要注意的点是协程调度KMP共享代码里的Dispatchers.Main能在Android上正确映射到主线程问题不大。iOS端麻烦一点。KMP编译出的framework通过Swift Package Manager或CocoaPods集成进Xcode工程Swift侧通过桥接头文件访问Kotlin类。Kotlin的StateFlow在Swift里不能直接collect要先通过collect扩展封装成一个Swift可调用的回调闭包或者用官方提供的CMPCallbackFlow工具。一个比较干净的解法是在shared模块里针对iOS写一个actual fun collectFlow(flow: StateFlowT, onEach: (T) - Unit)Swift侧传入闭包即可。这里还要提一个容易踩的坑Kotlin协程在iOS上用Dispatchers.Main默认走主队列但如果你的单元测试是用Dispatchers.Default在iOS模拟器里跑会闪退提示Fatal error: try! expression unexpectedly raised an error。这个问题的根因是Kotlin/Native的协程调度器没有像JVM那样统一管理未捕获异常。排查了整整一个下午最后就是给所有协程统一加CoroutineExceptionHandler并在测试里改用Dispatchers.Unconfined。这个细节如果你想在面试里作为“踩坑案例”讲效果很好——因为它足够真实不是网上找的套话。4. 面试官真正会问的KMP问题——高频考点拆解4.1 概念层面为什么用KMP而不用Flutter或RN这是我被问过最多次的开场问题没有之一。给出的答案要体现你的技术判断力而不是背优劣表。我习惯从三个维度拆团队技术栈、性能敏感度、UI复用期望。如果团队主语言是Kotlin或SwiftKMP的侵入感最小——你复用的是业务逻辑UI还走原生团队不需要重学UI框架。Flutter和RN要求UI层也跨平台换句话说你要接受一套渲染引擎包住整个App遇到特别复杂的列表交互或地图组件时还是会绕回平台通道。性能维度上KMP共享的是逻辑层代码编译产物要么是JVM字节码要么是原生二进制没有解释器介入逻辑运算性能跟两端原生代码几乎没有区别。Flutter因为是自绘引擎UI渲染性能优秀但业务逻辑层的Dart代码性能并不比原生强。RN则需要通过JS Bridge和原生通信在数据量大的场景下瓶颈明显。面试官会追问“那为什么很多大厂没大规模用KMP”这个问题很关键别落入“KMP不好”的陷阱。真实原因是很多业务团队Android和iOS是独立BU代码共享意味着要打破组织边界两边统一规划上层依赖这对管理层的推动力要求很高。换句话说KMP的技术壁垒已经不高了真正的门槛在团队协作模式。你把这个说出来面试官会觉得你有架构思维。4.2 实践层面你对KMP的缺陷了解多少面试官特别喜欢通过“你遇到了什么问题”来考察你的真实水平。我当时面的那轮考官直接打开IDE让我现场指出KMP工程的编译错误。虽然我准备得算充分但看到那一堆红标还是愣了一下。所以如果你写简历说“熟悉KMP”至少要知道下面这几个高频缺陷。iPhone和iPad等不同iOS设备的API差异导致actual实现不好写。Kotlin/Native提供的UIKit接口映射已经比较完善但某些方法签名和Swift有差异比如枚举的关联值、闭包逃逸语义、可变参数的接收方式。如果你不了解这些差异iOS端的目标代码很容易编译失败而且还很难排查。KMP的编译速度是另一个硬伤。增量编译在Android端没问题但iOS端第一次编译framework可能要好几分钟改造一个大工程动不动五六分钟。这对调试节奏影响很大。官方推荐用Kotlin/Native的缓存机制和Gradle构建缓存能缓解但别指望完全解决。我之前用一台旧款Mac跑iOS编译那个等待时间足够我写完一屏代码。还有包体积问题。KMP共享模块生成的framework静态链接后会让App体积增加约5MB到15MB不等具体取决于你依赖了多少库。如果接入了Ktor、Serialization、Coroutines三大件体积会明显变大。团队在做包体积优化时往往会质疑“为了这点代码共享体积换来换去值不值”面试时你可以主动提及这个问题并给出“按需引入、Abi稳定性和屏蔽无用依赖”的思路面试官会立刻意识到你踩过真坑。4.3 综合设计题某模块要不要抽到共享层这道题通常是“项目架构设计”的变种。面试官描述一个功能模块比如“埋点统计”“推送管理”“用户设置页”问你如何决策是否用KMP共享。我的回答框架是四步列出这个模块的逻辑复杂度。如果逻辑简单到只有三五个函数共享的收益就不明显反而增加构建成本。如果逻辑复杂、两端实现几乎一样且需要快速迭代那共享就很合适。分析平台差异化程度。UI展示层的差异天然存在但数据解析、加密、校验、状态机这些与UI无关的部分往往是共享的好目标。比如用户设置页的数据模型和存取逻辑适合共享但设置页的列表Cells和点击交互必须留给原生。评估依赖风险。如果模块已经依赖了某个Android专属库比如用到了WebView缓存机制那强行拉进commonMain就要做大量的expect/actual适配。与其硬抽不如先留一个扩展点慢慢迁移。回答的时候态度要务实别喊口号。我原话是“模块抽取不是一次性完成的事我会先在commonMain里建好业务模型和接口定义再逐步把Repository实现挪进去确保任何时刻两端都可以独立构建发布。”这个答案兼顾了工程可执行性和对持续重构的理解比那些一上来就画架构图的人扎实得多。5. 常见问题与踩坑记录——KMP实操避坑指南5.1 构建与依赖相关配置不对寸步难行KMP环境搭建的各类“怪病”通常可以归为三类。第一类是Gradle同步失败报错信息指向“Kotlin Multiplatform Plugin”无法识别。这种情况先检查Android Studio版本是否过旧建议用最新稳定版再检查Gradle版本和AGP版本是否符合KMP官方要求。第二类是依赖拉不下来常见于网络环境受限或者仓库地址配置不全。除了mavenCentral和google()KMP还依赖空间包的仓库如果缺了某些跨平台库就找不到。添加完仓库后建议做一次--refresh-dependencies强制刷新确定能拉到正确版本的依赖。第三类是版本冲突错误信息多为“Cannot choose between...”这是依赖传递导致多个版本并存。优先在根项目build.gradle.kts里统一配置Kotlin版本和常用库版本然后用resolutionStrategy强制指定版本。我建议你的共享模块里所有依赖都写明确版本号别用也别依赖传递。5.2 iOS端编译链接问题让人头皮发麻的符号缺失iOS侧编译失败有一部分能通过linker error看出端倪这类错误的典型场景是某个库在commonMain里可用但iOS端没有对应的.framework或静态库导致符号找不到。解决方法是检查该库是否真支持iosArm64和iosSimulatorArm64两个目标。一些老牌的JVM-only库比如旧版某些加密库在iOS目标下就是跑不了这是硬限制。还有一类诡异问题模拟器编译通过真机编译失败或者反过来。这是因为模拟器和真机的CPU架构不同而Kotlin/Native需要分别编译对应架构的bitcode。检查工程里有没有同时声明iosX64Intel模拟器、iosArm64真机和iosSimulatorArm64Apple Silicon模拟器。如果你只在共享模块里声明了iosArm64那么M系列芯片的模拟器编译直接挂。遇到这类问题不要慌先跑./gradlew :shared:iosSimulatorArm64Test这种单一目标的测试任务逐层缩小范围再看build/reports里的编译记录。盲改Gradle配置只会越改越乱。5.3 性能与包体积共享代码也有代价很多人以为KMP只共享逻辑运行时开销应该跟原生一样。这个说法大体成立但要注意对象序列化的开销。Kotlin数据类通过kotlinx.serialization序列化时在Android上走反射优化在iOS上则走编译期生成的序列化器性能表现都不错。但如果你在共享代码里用了大量泛型和嵌套结构编译期生成的代码会显著增加包体积。我另一个性能经验是尽量不要在共享代码里做敏感的IO密集操作。KMP的协程在Android上能利用JVM的线程池在iOS上则直接映射到GCD队列线程切换开销比想象中明显。如果某个算法函数在两端频繁调用、耗时小于1毫秒这种细粒度共享反而可能因调度开销适得其反。说到底KMP适合共享体重较大的业务逻辑不适合共享高频微小的底层工具函数。6. 面试前的最后准备除了KMP还要看什么6.1 Kotlin语言本身永远是地基KMP面试中很大一部分问题会在考题背景里预先假设你会用Kotlin。而很多人的Kotlin其实停留在“用Java写少写分号”的阶段。这里有几个Kotlin考点如果掌握透了KMP面试会更从容。协程是重中之重不只是launch和async要理解Dispatchers的切换原理、CoroutineScope的结构化并发以及Flow的冷热流区别。面KMP的考官经常把协程和KMP的跨平台调度结合起来考比如“Kotlin协程在iOS上的线程模型和Android有何不同”如果对协程调度器设计没有概念基本答不了。sealed class和密封接口在KMP里用来表示状态机和结果类型特别顺手面试写代码时如果能自然用出sealed interface加分明显。另外kotlinx.serialization的Serializable注解机制、泛型和类型变体reified也要了解写共享模块代码时几乎天天遇到。6.2 Linux查看系统状态和容器化基础KMP并不是一个孤岛技术安卓原生的基本功同样绕不开。准备面试时要记住面试官不会因为你是“KMP候选人”就降低Android基础要求。Activity的启动模式和保存恢复机制、Handler和Looper的原理、自定义View的测量布局绘制过程这些还是高频考核点。我建议按“Android四大组件生命周期、事件分发、消息机制、Binder通信、Jetpack核心组件”的顺序做一次系统复习。再贴上一个真题某面试官问“如果某个页面需要兼容低端机如何减少卡顿”这种题其实就是在考Memory和渲染性能优化。你把KMP的“共享逻辑不共享UI”理念套进去讲出“重逻辑原生实现、轻逻辑共享处理”的策略就形成了自己的特色答案。6.3 如何讲好你的KMP项目STAR原则的变体项目经历在面试中占比极大很多人做完了KMP项目却讲不出亮点。我的建议是不要按“需求-实现-难点-效果”套路机械复述而要讲决策过程。比如“我当时面对的问题是两端登录逻辑重复率超过70%团队目标是降低开发成本。我评估了Flutter、RN、KMP三种方案最终选择KMP因为团队全员是Kotlin背景且iOS端已有原生UI沉淀不需要重写UI。实施中最大的坑是iOS编译链接问题我通过拆分模块、统一版本矩阵解决了。最终共享代码占比约60%登录模块两端开发工作量下降约35%。”面试官听到这种带着数据和决策链的表述基本不会再追问“你在这项目里具体干了什么”因为答案已经比大多数候选人清晰了。讲项目不是念流水账是讲你如何分析问题、评估方案、排除障碍这是KMP实践里最能沉淀的部分。7. 写在最后的一点个人建议别把KMP当成“银弹”去背面试题。真正面试时考官只花几句话就能听出你是“动手做过”还是“看博客了解过”。我在模拟面试时遇到过不少候选人能把expect/actual原理说得头头是道但一问到“项目里KMP和原生如何协作调优”就瞬间失了底气。你缺的往往不是知识点而是把知识点串起来的实操线索。如果你现在正好准备面试我建议找个周末花一天时间从官方脚手架搭个KMP项目把登录模块的“校验网络请求状态管理”写完再试着在模拟器上跑通双端最后回头把踩坑经历复盘成自己的语言。这个过程耗时不多但足够让你在面试里面对KMP问题时不再心慌。技术面试最本质的就是想看到一个能独立解决问题的人而KMP正好提供了一堆正宗又新鲜的“问题”。 
长河君 · 2026/10/16 3:59:43 · 阅读 1.2k KMP面试实战指南：Kotlin Multiplatform跨平台开发核心要点
1. 为什么KMP会出现在面试题里——先搞懂技术背景和市场需求过去一年我面过不少安卓岗位也帮朋友做模拟面试发现一个很明显的趋势Kotlin Multiplatform简称KMP不再只是技术大会上的概念而是切切实实进入了面试官的题库。我最早接触KMP是2022年底那会儿社区讨论还停留在“能不能用”“坑多不多”的阶段到2023年下半年已经有公司把KMP作为跨平台方案的备选项写进技术规划甚至有小团队已经上线了KMP混合开发的App。如果你的简历里出现“跨平台”“代码共享”“Kotlin”这些词面试官大概率会追问一句“KMP你了解多少和Flutter、RN比怎么选”问得深一点的还会直接扔一个场景题登录模块的校验逻辑怎么在双端复用网络层封装怎么做平台差异化很多安卓开发对KMP有误解觉得它是“又要学一套新框架”。实际上KMP的核心理念不是让你重新发明轮子而是把业务逻辑层——数据校验、状态管理、网络请求、持久化——用Kotlin统一实现UI层仍然走各自平台的原生方案。这一点对安卓工程师非常友好因为Kotlin本来就是安卓开发的第一语言你不需要切换语言只需要理解“如何划分共享边界”。面试里如果你能把这一点讲清楚就已经胜过了80%只背概念的人。这篇文章的内容来自我自己的KMP实践笔记和面试复盘。我不是要给你一份面试八股文而是想带你过一遍KMP到底怎么落地、代码边界怎么切、哪些地方容易翻车、面试官真正会追问哪些细节。想要在简历上写KMP或者正在准备安卓面试的朋友这篇值得认真看两遍。2. KMP的技术核心共享代码的边界怎么划2.1 三层架构commonMain / androidMain / iosMain第一次接触KMP项目最容易懵的是目录结构。官方脚手架创建出来的项目默认有三个源集commonMain、androidMain、iosMain加上各自的测试源集。理解这三个目录的职责基本就理解了KMP的一半。commonMain放的是不依赖任何平台的纯Kotlin代码比如数据模型data class、业务校验逻辑、接口定义、使用expect声明的抽象。这里的代码原则是“只使用Kotlin标准库和跨平台库”。androidMain和iosMain则放平台相关实现包括actual实现、平台API调用、第三方SDK接入。我在第一版项目里犯过一个典型错误试图把Room数据库也塞进commonMain。理论上Room从2.5.0开始支持KMP但在当时版本下实际跑起来折腾了三天最后还是退回androidMain单独用Room、iosMain用SQLDelight的方案。这件事给我的教训是架构上哪层放什么不能只看技术可行性还要考虑团队维护能力和当前项目阶段。即使官方支持也不代表你立刻就要用。2.2 expect/actual机制跨平台抽象的真正解法expect和actual是KMP最核心的语言级机制。简单说你在commonMain里写一个函数声明不写实现然后在每个平台源集里写对应的actual实现。这个机制很像接口但比接口更彻底——它不光能抽象函数还能抽象属性、类、注解甚至连object单例都能做。举个例子获取设备唯一标识// commonMain expect fun getDeviceId(): String // androidMain actual fun getDeviceId(): String { return Settings.Secure.getString( context.contentResolver, Settings.Secure.ANDROID_ID ) } // iosMain actual fun getDeviceId(): String { return UIDevice.currentDevice.identifierForVendor?.UUIDString ?: unknown }看起来很简单对吧但里面有个大坑expect声明的函数在commonMain里被调用时Kotlin/Native编译期会对不上平台API的差异。如果两个平台返回类型不一致需要做类型映射。面试官特别喜欢在这里设陷阱——比如问你“expect/actual和依赖注入有什么区别”“如果Android的actual实现需要Context怎么办”。第二个问题的经典解法是不要直接传Context而是用一个接口封装在App启动时初始化。比如定义PlatformContextProviderAndroid端传入ApplicationiOS端传入一个空实现。这样你可以在commonMain里安全地调用expect fun getPlatformContext(): PlatformContext而不用把平台对象暴露给共享逻辑。这个方法我在面试中讲出来时面试官明显眼睛亮了一下。2.3 网络层与数据解析Ktor kotlinx.serialization组合KMP项目里网络层几乎标配Ktor Client因为Ktor本身就是Kotlin官方出的跨平台HTTP客户端。配合kotlinx.serialization做JSON解析可以让网络请求和模型类老老实实待在commonMain里两端共用一套代码。这一步是整个KMP实践中最能直接感受到“爽”的地方同样的接口返回结构Android和iOS都不用各写一套解析代码。但这里有个细节很多人没注意Ktor Client在不同平台的引擎不同Android上通常是OkHttpiOS上是Darwin引擎。引擎的差异会导致部分参数表现不一致。比如超时时间设置在HttpTimeout插件里两端表现基本一致但连接池复用策略、DNS解析行为Android和iOS就有区别。我的习惯是把网络层公共配置超时时间、重试机制、Header注入统一写在commonMain的HttpClient工厂函数里但保留一个platformConfig扩展点让两端按需微调。// commonMain expect fun platformHttpClientConfig(): HttpClientConfig*.() - Unit fun createHttpClient(): HttpClient { return HttpClient { install(ContentNegotiation) { json(Json { ignoreUnknownKeys true explicitNulls false }) } install(HttpTimeout) { requestTimeoutMillis 15_000 connectTimeoutMillis 10_000 } expectSuccess true platformHttpClientConfig() } }数据解析这块kotlinx.serialization比Gson要严格得多。如果你之前在Android上用Gson习惯了SerializedName注解切到KMP要注意SerialName的语义虽然类似但ignoreUnknownKeys默认是false所以后端多返回字段直接崩给你看。我第一次接老项目接口时就因为这个线上炸了一回后来才把这两行配置写死在项目里谁都不许改。3. 从零搭建一个KMP项目实操流程全记录3.1 工程初始化与Gradle配置先别急着写代码你得搞明白KMP的构建基础。最常见的项目形态是先用Android空的单模块工程跑通再逐步把共享逻辑抽取到独立模块。还有一种是直接用官方KMP Wizard生成多模块项目里面已经有shared模块和Compose Multiplatform的依赖。我推荐第二种起步方式——官方脚手架能规避90%的“Gradle配置地狱”。踏踏实实把生成的项目结构看懂比从零配Gradle省一星期时间。生成之后的第一件事不是改代码而是跑通双层构建./gradlew :shared:assembleDebug和iOS端的linkDebugFrameworkIosSimulatorArm64。如果这两个任务都过了说明你的KMP环境基本OK。Gradle配置里最关键的一个坑是Kotlin版本对齐。KMP对Kotlin版本非常敏感Ktor、kotlinx.serialization、Compose Multiplatform这些库的版本都必须和Kotlin版本兼容。我吃过最大的亏是Kotlin 1.9.20配Ktor 2.3.5编译倒是能过但一跑iOS测试就各种UnsupportedOperationException。后来对齐到官方版本矩阵才消停。结论先看依赖库的版本说明文档再挑Kotlin版本没有把握就用脚手架默认版本不要自己乱升。3.2 编写共享模块从登录校验到业务闭环我拿一个登录模块做例子讲清楚shared模块怎么组织。需求很简单手机号验证码登录客户端拿到验证码后提交后端返回token和用户资料。放在纯Android项目里这个流程大概要写Activity、ViewModel、Repository三个类。在KMP里ViewModel和Repository可以挪到commonMainActivity只负责UI和调用ViewModel。共享模块里要做的核心事情是状态管理。官方推荐用StateFlow它的跨平台支持很完善Android端可以配合Google的ViewModel使用iOS端也有相应的Collector桥接方案。我常用的模式是commonMain里定义业务状态Sealed类配合StateFlow暴露状态平台侧只订阅状态渲染UI。// commonMain sealed class LoginUiState { data object Idle : LoginUiState() data object Loading : LoginUiState() data class Success(val userInfo: UserInfo) : LoginUiState() data class Error(val message: String) : LoginUiState() } class LoginViewModel(private val repository: LoginRepository) { private val _uiState MutableStateFlowLoginUiState(LoginUiState.Idle) val uiState: StateFlowLoginUiState _uiState.asStateFlow() fun requestCode(phone: String) { val validateResult PhoneValidator.validate(phone) if (!validateResult.isValid) { _uiState.value LoginUiState.Error(validateResult.message) return } viewModelScope.launch { _uiState.value LoginUiState.Loading // 调用网络接口 } } }重点是校验逻辑和网络请求全部复用。安卓端接入理论上只写UI绑定iOS端也是。我自己做完这一套发现共享代码行数占比能到60%左右还不算上面向UI的部分。面试里提到这个数字不仅展示你有真实经验还说明你关注落地效果。3.3 平台端接入Android和iOS如何消费共享模块Android端接入KMP共享模块非常顺滑因为本质就是依赖一个Android Library。你在build.gradle.kts里依赖shared模块然后Activity/Fragment里得到LoginViewModel的实例收集StateFlow更新UI。需要注意的点是协程调度KMP共享代码里的Dispatchers.Main能在Android上正确映射到主线程问题不大。iOS端麻烦一点。KMP编译出的framework通过Swift Package Manager或CocoaPods集成进Xcode工程Swift侧通过桥接头文件访问Kotlin类。Kotlin的StateFlow在Swift里不能直接collect要先通过collect扩展封装成一个Swift可调用的回调闭包或者用官方提供的CMPCallbackFlow工具。一个比较干净的解法是在shared模块里针对iOS写一个actual fun collectFlow(flow: StateFlowT, onEach: (T) - Unit)Swift侧传入闭包即可。这里还要提一个容易踩的坑Kotlin协程在iOS上用Dispatchers.Main默认走主队列但如果你的单元测试是用Dispatchers.Default在iOS模拟器里跑会闪退提示Fatal error: try! expression unexpectedly raised an error。这个问题的根因是Kotlin/Native的协程调度器没有像JVM那样统一管理未捕获异常。排查了整整一个下午最后就是给所有协程统一加CoroutineExceptionHandler并在测试里改用Dispatchers.Unconfined。这个细节如果你想在面试里作为“踩坑案例”讲效果很好——因为它足够真实不是网上找的套话。4. 面试官真正会问的KMP问题——高频考点拆解4.1 概念层面为什么用KMP而不用Flutter或RN这是我被问过最多次的开场问题没有之一。给出的答案要体现你的技术判断力而不是背优劣表。我习惯从三个维度拆团队技术栈、性能敏感度、UI复用期望。如果团队主语言是Kotlin或SwiftKMP的侵入感最小——你复用的是业务逻辑UI还走原生团队不需要重学UI框架。Flutter和RN要求UI层也跨平台换句话说你要接受一套渲染引擎包住整个App遇到特别复杂的列表交互或地图组件时还是会绕回平台通道。性能维度上KMP共享的是逻辑层代码编译产物要么是JVM字节码要么是原生二进制没有解释器介入逻辑运算性能跟两端原生代码几乎没有区别。Flutter因为是自绘引擎UI渲染性能优秀但业务逻辑层的Dart代码性能并不比原生强。RN则需要通过JS Bridge和原生通信在数据量大的场景下瓶颈明显。面试官会追问“那为什么很多大厂没大规模用KMP”这个问题很关键别落入“KMP不好”的陷阱。真实原因是很多业务团队Android和iOS是独立BU代码共享意味着要打破组织边界两边统一规划上层依赖这对管理层的推动力要求很高。换句话说KMP的技术壁垒已经不高了真正的门槛在团队协作模式。你把这个说出来面试官会觉得你有架构思维。4.2 实践层面你对KMP的缺陷了解多少面试官特别喜欢通过“你遇到了什么问题”来考察你的真实水平。我当时面的那轮考官直接打开IDE让我现场指出KMP工程的编译错误。虽然我准备得算充分但看到那一堆红标还是愣了一下。所以如果你写简历说“熟悉KMP”至少要知道下面这几个高频缺陷。iPhone和iPad等不同iOS设备的API差异导致actual实现不好写。Kotlin/Native提供的UIKit接口映射已经比较完善但某些方法签名和Swift有差异比如枚举的关联值、闭包逃逸语义、可变参数的接收方式。如果你不了解这些差异iOS端的目标代码很容易编译失败而且还很难排查。KMP的编译速度是另一个硬伤。增量编译在Android端没问题但iOS端第一次编译framework可能要好几分钟改造一个大工程动不动五六分钟。这对调试节奏影响很大。官方推荐用Kotlin/Native的缓存机制和Gradle构建缓存能缓解但别指望完全解决。我之前用一台旧款Mac跑iOS编译那个等待时间足够我写完一屏代码。还有包体积问题。KMP共享模块生成的framework静态链接后会让App体积增加约5MB到15MB不等具体取决于你依赖了多少库。如果接入了Ktor、Serialization、Coroutines三大件体积会明显变大。团队在做包体积优化时往往会质疑“为了这点代码共享体积换来换去值不值”面试时你可以主动提及这个问题并给出“按需引入、Abi稳定性和屏蔽无用依赖”的思路面试官会立刻意识到你踩过真坑。4.3 综合设计题某模块要不要抽到共享层这道题通常是“项目架构设计”的变种。面试官描述一个功能模块比如“埋点统计”“推送管理”“用户设置页”问你如何决策是否用KMP共享。我的回答框架是四步列出这个模块的逻辑复杂度。如果逻辑简单到只有三五个函数共享的收益就不明显反而增加构建成本。如果逻辑复杂、两端实现几乎一样且需要快速迭代那共享就很合适。分析平台差异化程度。UI展示层的差异天然存在但数据解析、加密、校验、状态机这些与UI无关的部分往往是共享的好目标。比如用户设置页的数据模型和存取逻辑适合共享但设置页的列表Cells和点击交互必须留给原生。评估依赖风险。如果模块已经依赖了某个Android专属库比如用到了WebView缓存机制那强行拉进commonMain就要做大量的expect/actual适配。与其硬抽不如先留一个扩展点慢慢迁移。回答的时候态度要务实别喊口号。我原话是“模块抽取不是一次性完成的事我会先在commonMain里建好业务模型和接口定义再逐步把Repository实现挪进去确保任何时刻两端都可以独立构建发布。”这个答案兼顾了工程可执行性和对持续重构的理解比那些一上来就画架构图的人扎实得多。5. 常见问题与踩坑记录——KMP实操避坑指南5.1 构建与依赖相关配置不对寸步难行KMP环境搭建的各类“怪病”通常可以归为三类。第一类是Gradle同步失败报错信息指向“Kotlin Multiplatform Plugin”无法识别。这种情况先检查Android Studio版本是否过旧建议用最新稳定版再检查Gradle版本和AGP版本是否符合KMP官方要求。第二类是依赖拉不下来常见于网络环境受限或者仓库地址配置不全。除了mavenCentral和google()KMP还依赖空间包的仓库如果缺了某些跨平台库就找不到。添加完仓库后建议做一次--refresh-dependencies强制刷新确定能拉到正确版本的依赖。第三类是版本冲突错误信息多为“Cannot choose between...”这是依赖传递导致多个版本并存。优先在根项目build.gradle.kts里统一配置Kotlin版本和常用库版本然后用resolutionStrategy强制指定版本。我建议你的共享模块里所有依赖都写明确版本号别用也别依赖传递。5.2 iOS端编译链接问题让人头皮发麻的符号缺失iOS侧编译失败有一部分能通过linker error看出端倪这类错误的典型场景是某个库在commonMain里可用但iOS端没有对应的.framework或静态库导致符号找不到。解决方法是检查该库是否真支持iosArm64和iosSimulatorArm64两个目标。一些老牌的JVM-only库比如旧版某些加密库在iOS目标下就是跑不了这是硬限制。还有一类诡异问题模拟器编译通过真机编译失败或者反过来。这是因为模拟器和真机的CPU架构不同而Kotlin/Native需要分别编译对应架构的bitcode。检查工程里有没有同时声明iosX64Intel模拟器、iosArm64真机和iosSimulatorArm64Apple Silicon模拟器。如果你只在共享模块里声明了iosArm64那么M系列芯片的模拟器编译直接挂。遇到这类问题不要慌先跑./gradlew :shared:iosSimulatorArm64Test这种单一目标的测试任务逐层缩小范围再看build/reports里的编译记录。盲改Gradle配置只会越改越乱。5.3 性能与包体积共享代码也有代价很多人以为KMP只共享逻辑运行时开销应该跟原生一样。这个说法大体成立但要注意对象序列化的开销。Kotlin数据类通过kotlinx.serialization序列化时在Android上走反射优化在iOS上则走编译期生成的序列化器性能表现都不错。但如果你在共享代码里用了大量泛型和嵌套结构编译期生成的代码会显著增加包体积。我另一个性能经验是尽量不要在共享代码里做敏感的IO密集操作。KMP的协程在Android上能利用JVM的线程池在iOS上则直接映射到GCD队列线程切换开销比想象中明显。如果某个算法函数在两端频繁调用、耗时小于1毫秒这种细粒度共享反而可能因调度开销适得其反。说到底KMP适合共享体重较大的业务逻辑不适合共享高频微小的底层工具函数。6. 面试前的最后准备除了KMP还要看什么6.1 Kotlin语言本身永远是地基KMP面试中很大一部分问题会在考题背景里预先假设你会用Kotlin。而很多人的Kotlin其实停留在“用Java写少写分号”的阶段。这里有几个Kotlin考点如果掌握透了KMP面试会更从容。协程是重中之重不只是launch和async要理解Dispatchers的切换原理、CoroutineScope的结构化并发以及Flow的冷热流区别。面KMP的考官经常把协程和KMP的跨平台调度结合起来考比如“Kotlin协程在iOS上的线程模型和Android有何不同”如果对协程调度器设计没有概念基本答不了。sealed class和密封接口在KMP里用来表示状态机和结果类型特别顺手面试写代码时如果能自然用出sealed interface加分明显。另外kotlinx.serialization的Serializable注解机制、泛型和类型变体reified也要了解写共享模块代码时几乎天天遇到。6.2 Linux查看系统状态和容器化基础KMP并不是一个孤岛技术安卓原生的基本功同样绕不开。准备面试时要记住面试官不会因为你是“KMP候选人”就降低Android基础要求。Activity的启动模式和保存恢复机制、Handler和Looper的原理、自定义View的测量布局绘制过程这些还是高频考核点。我建议按“Android四大组件生命周期、事件分发、消息机制、Binder通信、Jetpack核心组件”的顺序做一次系统复习。再贴上一个真题某面试官问“如果某个页面需要兼容低端机如何减少卡顿”这种题其实就是在考Memory和渲染性能优化。你把KMP的“共享逻辑不共享UI”理念套进去讲出“重逻辑原生实现、轻逻辑共享处理”的策略就形成了自己的特色答案。6.3 如何讲好你的KMP项目STAR原则的变体项目经历在面试中占比极大很多人做完了KMP项目却讲不出亮点。我的建议是不要按“需求-实现-难点-效果”套路机械复述而要讲决策过程。比如“我当时面对的问题是两端登录逻辑重复率超过70%团队目标是降低开发成本。我评估了Flutter、RN、KMP三种方案最终选择KMP因为团队全员是Kotlin背景且iOS端已有原生UI沉淀不需要重写UI。实施中最大的坑是iOS编译链接问题我通过拆分模块、统一版本矩阵解决了。最终共享代码占比约60%登录模块两端开发工作量下降约35%。”面试官听到这种带着数据和决策链的表述基本不会再追问“你在这项目里具体干了什么”因为答案已经比大多数候选人清晰了。讲项目不是念流水账是讲你如何分析问题、评估方案、排除障碍这是KMP实践里最能沉淀的部分。7. 写在最后的一点个人建议别把KMP当成“银弹”去背面试题。真正面试时考官只花几句话就能听出你是“动手做过”还是“看博客了解过”。我在模拟面试时遇到过不少候选人能把expect/actual原理说得头头是道但一问到“项目里KMP和原生如何协作调优”就瞬间失了底气。你缺的往往不是知识点而是把知识点串起来的实操线索。如果你现在正好准备面试我建议找个周末花一天时间从官方脚手架搭个KMP项目把登录模块的“校验网络请求状态管理”写完再试着在模拟器上跑通双端最后回头把踩坑经历复盘成自己的语言。这个过程耗时不多但足够让你在面试里面对KMP问题时不再心慌。技术面试最本质的就是想看到一个能独立解决问题的人而KMP正好提供了一堆正宗又新鲜的“问题”。