KMP Meetup 202512 回顾

Source: Dev.to

引言

星期日（12/21），我参加了 Kotlin User Group Seoul 主办的 KMP 见面会。自从有了儿子后，这已经是很久没有参加开发者聚会了。最近参加的聚会都是 GDG Android 主办的活动，这次去一个没有熟人参与的社区活动，既有些期待也有点尴尬。

在育儿假期间，我一直在尝试用 KMP + CMP 做一些小应用。因为不想自己写代码，大部分工作交给 Claude Code 完成，同时在测试 Firebase 认证、Metro DI 等功能。恰好这次见面会的主题和我正在思考的问题完全吻合，所以毫不犹豫地参加了。

完整演示文稿 也已经共享，感兴趣 KMP / CMP 的朋友可以阅读，收获会很大。下面简要整理一下各个环节的感想。

各环节整理

从 Compose Multiplatform 外部依赖架构设计到运营

分享者讲述了使用 CMP 将内部用户应用发布到 iOS / Android 的经验。expect / actual 是 KMP 的语言特性，配合后面会出现的 Metro 之类的 DI 时，只需要声明接口并在各平台注入实现即可。由于构造函数必须保持一致等限制，感觉在不使用 DI 时或者功能不够通用时，这种方式的价值会打折。

所有跨平台技术的关键在于，当出现平台专属实现时，能否 更少痛苦 地处理它们。演示中展示了 在 Swift 中自然调用 Kotlin 函数并将原生端的改动反映到 Kotlin 的示例，以及如何用 Swift 编写 Kotlin 声明的接口实现，印象深刻。

Kotlin/Native 并不像 JNI 那样在 Java 与 Native 世界之间充当中介，而是直接把 Kotlin 代码编译成 Native 代码。因此 Swift 与 Kotlin 之间的相互调用非常自然，这一点每次看到都让人惊讶，但仍需适应。

不过，需要注意的是，在多模块情况下，单例对象在 Swift 与 Kotlin 区域可能会出现不同实例的问题。查看了相关文档后，建议创建一个把多个模块聚合在一起的 Umbrella Module（统一 Kotlin 模块）来解决。对应 Android 场景，就是在 app 模块下再加一个 umbrella 模块，所有子模块都放进去。

还提到了 Firebase。由于官方尚未提供 KMP SDK，Android 与 iOS 仍需分别使用各自的版本。虽然 GitLive 的 Firebase SDK 可以作为替代，但并未覆盖全部功能。相对而言，后面提到的 Supabase 对 KMP 支持更好。我的个人经验是，GitLive 的集成并不顺畅，导致不少痛点。

项目重构思路

• 注册、用户认证等基于会话的功能： Supabase
• FCM、Analytics、Crashlytics 等与会话无关的功能： 各平台原生 Firebase SDK

演示中还涉及了 CocoaPods 的安装，我更倾向于使用 SPM（Swift Package Manager）来解决。对于 Android 开发者来说，CocoaPods 常常会出现难以理解的问题。如果公司在引入 KMP 时要求“必须使用 CocoaPods”，会让 iOS 开发者产生不少抵触情绪。

使用 KMP 与 UIKit 开发 iOS 原生应用

这是一位已经用 CMP 上线应用的分享，内容非常有趣。演讲者详细说明了 KMP 编译时生成 Native 代码的过程，并展示了在没有 Xcode 的情况下手动创建一个 “Hello World” iOS 应用的步骤。

演讲中提到的 UIView 与 MetalView 的叠加选项、Alert 的实现方式等，都可以作为 iOS CMP 开发的实用技巧。尤其是 ARC（Automatic Reference Counting）可能影响 CMP 应用开发，这一点从书本上听到的理论转化为实际开发中的感受，让我意识到想做好跨平台，必须对两个平台都深入了解。

KMP + Supabase：单人开发的新范式

我曾在 Firebase 上实现 Google 登录（Desktop/Android）时遇到不少痛点，看到 Supabase 的 KMP SDK 后立刻决定以后一定要用它。相比于之前在 Claude Code 上“唠叨”实现的繁琐，库层面的支持显得更为简洁。Supabase 基于 PostgreSQL，SQL 使用自由，API 生成也很直观。

用 Metro 在 KMP 中实现依赖注入

最后介绍了全新的 DI 方案 Metro。我目前在玩具项目中已经在使用 Metro，看到它的出现非常开心。过去因为 Dagger 的复杂度转向 Koin，对“编译时 DI”有一定偏见，但 Metro 看起来比记忆中的 Dagger 更易用，像是吸收了 Anvil 等方案的优点。

演讲解释了其工作原理：Dagger 通过生成 Java 代码实现，而 Metro 作为 Kotlin 编译插件，在 IR（Intermediate Representation）阶段获取信息，生成的代码更简洁。尤其是错误信息更友好，这点让我非常满意。虽然还未到 1.0 版，但对玩具项目来说已经足够值得引入。

结语

在家里和 Claude Code 折腾 CMP，听到同样在思考这些问题的朋友们的深入分享，既开心又受启发。

KMP 今后能否进一步落地还有待观察，但目前 Android 与 Desktop 的组合已经相当顺畅，iOS 仍然有学习曲线。如果只共享业务逻辑（不包括 UI），引入 KMP 的可能性会更高。这次我也加入了 Kotlin User Group Seoul，今后会更加活跃。感谢组织者和演讲者们精心准备的精彩活动。