又是凌晨三点。
显示器幽蓝的光映在脸上，手指机械地在Android Studio和Xcode之间切换。
完全相同的业务逻辑，却要在Java和Swift里分别实现一遍。
这种重复造轮子的枯燥感，几乎磨光了我对编码的最后一点热情。
直到团队里新来的小伙儿在茶水间随口提了句："要不试试Kotlin Multiplatform？"
（二）
Kotlin Multiplatform（KMP）不是什么新概念，但真正把它用到生产环境，还是需要点儿勇气的。
我们的项目结构很典型：一个社交类App，Android和iOS两端功能基本同步，核心的feed流、消息推送、用户关系链这些逻辑高度重合。
以前的做法是两端各维护一套，每次产品经理提个需求，两边开发就得同时开工，联调时还得小心翼翼对比差异。
（三）
下决心迁移后，我们抽离出的第一个共享模块是网络层。
用做HTTP客户端，配置序列化、日志拦截器都在common代码里一气呵成。
最爽的时刻是看到同一份API请求逻辑，在Android的和iOS的里都能直接调用。
数据模型用注解，自动在两端生成对应的和。
以前因为两端模型字段解析不一致导致的诡异bug，彻底成为历史。
（四）
但坑也是真不少。
比如日期处理，common模块里只能用，到了平台上再转换成或。
还有依赖注入，我们在common里定义接口，Android侧用Koin，iOS侧用纯手动的Provider模式，虽然笨拙但管用。
最头疼的是线程调度，common代码里不能直接使用，得通过机制分别实现。
我们在common里声明，然后在androidMain里成，在iosMain里则折腾了好久才搞定的适配。
（五）
说到iOS调用，KMP编译生成的framework，直接拖进Xcode工程就行。
不过Swift调用Kotlin代码时，方法命名风格会变得很"Java"，比如这种。
我们写了层薄薄的adapter，把转换成更Swift化的点语法访问。
另外，Kotlin里的到了Swift那边会变成，注意可选类型的处理就能避免大部分崩溃。
（六）
经过三个月的摸索，现在我们的代码库大约有35%的逻辑共享在了KMP模块中。
包括所有的网络请求、数据模型、缓存管理、部分业务状态流转。
效果最明显的是产品提需求时，我们终于可以自信地说"这个功能底层逻辑一套就行"，开发周期肉眼可见地缩短。
当然，UI层、平台特定API（比如Android的WorkManager、iOS的BackgroundTasks）还是各做各的，KMP没打算取代它们。
（七）
如果你也想尝试KMP，建议从网络层和数据层这种"纯逻辑"模块开始啃。
别一上来就搞太复杂的并发操作，先熟悉的套路。
多看看现在JetBrains官方和社区开源的KMP项目，比如和，能少走很多弯路。
记住，KMP的目标不是100%代码共享，而是把该共享的优雅地共享，该平台特定的放手让它特定。
（八）
回头看看，从当初的双端重复劳动，到现在只写一次核心逻辑。
这种开发体验的提升，远比想象中来得实在。
技术选型就是这样，有时候需要的不是无休止的争论，而是在合适的时机，像推开一扇门那样，果断地迈出第一步。
至少现在，团队里的兄弟们都觉得，这波折腾，值了。