ISLAND
·
SugarLite 的 KMP 渐进式迁移实践
内容提要
SugarLite 项目成功从纯 iOS 应用迁移到 Kotlin Multiplatform (KMP)，以降低双端维护成本。文章详细记录了迁移过程，包括架构重构、数据层下沉和 CI/CD 适配。通过将业务逻辑集中在 KMP 共享模块，iOS 端仅保留 SwiftUI 和系统框架调用，实现了渐进式接入，确保了迁移的顺利进行。
关键要点
-
SugarLite 项目从纯 iOS 应用迁移到 Kotlin Multiplatform (KMP)，以降低双端维护成本。
-
迁移前进行了 MVVM Clean Architecture 的重构，使 ViewModel 不依赖外部框架，便于后续迁移。
-
引入 KMP 后，项目结构调整为包含共享模块，iOS 端仅保留 SwiftUI 和系统框架调用。
-
数据层下沉至 KMP 共享模块，创建统一的 Kotlin DTO 和 CloudSource 封装 CRUD 操作。
-
iOS 侧采用渐进式接入策略，新功能直接使用 KMP，旧功能逐步替换。
-
CI/CD 适配中，解决了 Xcode Cloud 环境中缺少 Java 和 Gradle 的问题，确保构建顺利进行。
-
迁移策略总结包括优先下沉 DTO/Model，保留 ViewModel 以维持 SwiftUI 响应式体验。
延伸问答
SugarLite 项目为什么选择迁移到 Kotlin Multiplatform (KMP)？
SugarLite 项目选择迁移到 KMP 是为了降低双端维护成本，避免在 iOS 和 Android 上重复维护相同的业务逻辑。
迁移过程中进行了哪些架构重构？
迁移前进行了 MVVM Clean Architecture 的重构，使 ViewModel 不依赖外部框架，便于后续迁移。
如何实现 iOS 侧的渐进式接入 KMP？
iOS 侧采用渐进式接入策略，新功能直接使用 KMP，旧功能逐步替换，并通过桥接层让 Swift 能获取 Koin 容器中的实例。
在 CI/CD 适配中遇到了哪些挑战？
在 CI/CD 适配中，主要挑战是 Xcode Cloud 环境缺少 Java 和 Gradle，导致构建无法顺利进行。
迁移策略总结中提到的优先级是什么？
迁移策略总结中提到的优先级是：DTO/Model 优先下沉，Repository Protocol 其次，UseCase/Service 随后，ViewModel 暂不迁移。
如何处理数据层的下沉？
数据层下沉至 KMP 共享模块，创建统一的 Kotlin DTO 和 CloudSource 封装 CRUD 操作，整合各 Repository 中的 Supabase 调用。
