Android 深度实践

Appearance

实战坑点与性能调优 ​

源：Kotlin Multiplatform 官方文档

在 Kotlin Multiplatform (KMP) 从实验室走向工业级的过程中，许多开发者会遇到一些“文档中没写”的挑战。本章旨在汇总常见的实战坑点，并提供成熟的解决方案。

iOS 端的“减肥”：优化二进制体积 ​

由于导出的 .framework

包含 Kotlin 运行时以及大量的 Objective-C 桥接代码，体积往往会偏大。

  • 启用混淆与剥离: 确保在 Release 构建中开启 R8 和 Bitcode 剥离。
  • 架构精简: 默认情况下，KMP 会编译 x64 和 Arm64。在最终分发给 App Store 时，请确保移除模拟器的 x64 架构。
  • 静态 vs 动态:
    • Static Framework: (推荐) 直接链接到宿主 App，性能略好，适合小型项目。
    • Dynamic Framework: 适合多个模块共享同一个 Common 代码库的情况。

导出名称冲突：Objective-C 的局限 ​

Kotlin 支持函数重载

（Overloading），但 Objective-C 不支持。

自动重命名

如果您在 Kotlin 中定义了：

kotlin
fun load(id: Int)
fun load(name: String)

在 Swift 视角下，它们会被强制重命名为：

swift
load(id:)
load_(name:) // 注意那个下划线

解决方案：使用 @JvmName（对 JVM 有效）或手动提供更具区分度的名称，以确保 Swift 侧的 API 优雅且可预测。

跨平台资源管理 (Resources) ​

KMP 项目中

，访问图片、字符串、多媒体资源曾是一个噩梦。

  • 不要手动同步: 严禁在 androidRes 和 iosApp 中各存一份图片。
  • 推荐方案: 使用 Compose Multiplatform Resources 插件。
    • 将图片放在 commonMain/composeResources 目录下。
    • 插件会自动生成跨平台的 Res 对象，支持代码提示。

异常处理：丢失的 Crash 现场 ​

当 Kotlin 代码

在 iOS 侧崩溃时，原始的堆栈信息（Stacktrace）往往是混淆后的地址，极难定位。

  • Crashlytics 集成: 集成 Firebase Crashlytics 时，需要上传生成的 .dSYM 符号文件。
  • Crash 反混淆库: 使用 Kermit 或 [Napier] 等专门的 KMP 日志库，它们能更好地保留原始崩溃现场。

编译加速指南 ​

KMP 的编译速度

（尤其是涉及 Xcode 的链接阶段）通常比纯 Android 项目慢。

  1. Gradle 配置缓存: 开启 org.gradle.configuration-cache=true。
  2. Kotlin Daemon: 增加 org.gradle.jvmargs=-Xmx4g 以保证编译器有足够的内存。
  3. 增量编译: 尽量减少 commonMain 的频繁改动，将不稳定逻辑封装在具体平台的入口处。