如果你手里是一个已经上线很久的 Android 项目，不要把 KMP/CMP 当成“重写项目”的理由。说起来，真正可行的方法是：保留现有 Android 业务节奏。把可共享的部分一点点搬到 shared。

迁移可以拆成三步：先迁数据层。再迁状态层，最终才碰 UI。

先定一个现实目标

一开始别追“复用率 %”。这个目标听上去很美，但会逼着你把不该共享的东西硬塞进 shared，最终两端都难受。

更实用的目标是这三个：

• Android 和 iOS 的业务结果一致——双端逻辑不一致导致问题？
• 关键页面状态流转一致——不同网站使用者体验差异太大？
• 迁移过程可以随时停、随时回滚——担心中途出问题无法收尾？话说回来，

再看第一步先，先动数据层。不动 UI

"只改数据源不改页面" 让团队最快看到收益！

项目结构可以先变成这样：

project
├── androidApp # 现有 Android app，先继续用
├── iosApp # iOS 壳
└── shared
├── model
├── network
└── repository

共享模块配置建议

shared/build.gradle.kts 先保持最小可用：注意 iosMain

kotlin {
androidTarget
iosX64
iosArm64
iosSimulatorArm64
sourceSets {
val commonMain by getting {
dependencies {
implementation
implementation
implementation
}
}
val androidMain by getting {
dependencies {
implementation
}
}
val iosMain by creating { // ⚠️ 这里很关键！dependsOn
dependencies {
implementation
}
}
getByName.dependsOn
getByName.dependsOn
getByName.dependsOn
}
}

从接下来来看。先统一错误语义，再说“多端一致”

"错误处理不统一是跨网站最大隐患！"

• "原生异常直抛到界面层导致两端处理逻辑分裂？"
• "同一个API错误在安卓和iOS显示不同文案？"
• "业务方总抱怨'为什么iOS/安卓显示不一样'？"

建议 shared 里先把错误语义钉死：封装统一返回类型避免双端逻辑分歧！

sealed interface AppError { // ✅ 安卓和iOS都要用的统一错误类型！data object Network : AppError
data object Unauthorized : AppError
data class Server : AppError
data class Unknown : AppError
}
sealed interface AppResult { // ✅ 强制所有仓库返回此结果类型！data class Success : AppResult
data class Failure : AppResult
}

class UserRepository {
suspend fun fetchProfile: AppResult AppResult.Failure) } // ⚠️ 必须转换为我们定义的AppError!
)
}
}
}

：把 Android 的 ViewModel 思路抽成 shared StateHolder!

⚠️ 警告!: 如果仍然让Android单独维护ViewModel而shared只提供数据，那你其实只做了"网络层复用" - 收益有限且容易产生双端逻辑分歧！

"状态管理混乱导致跨网站开发效率低下?" "iOS团队总抱怨'你们安卓那边又改了接口'?" "一样的功能要维护两套状态机?"    

再看方法，1. 把状态机提取到shared中!

data class ProfileState(
val loading Boolean false,val userName String "",val error.AppErro null)
class ProfileStateHolder(
private repo.UserRepository。private scope.CoroutineScope){
private _state MutableStateFlow )
val state StateFlow_state.update{
it.copy}
is Failure->_state.update{
it.copy}
}}
}
}
}

>>关键点<<<<<<<< • 安卓和iOS走同一个状态流! • 功能修改只需更新shared代码! • 自动保证两端行为完全一致!

什么时候开始用 CMP 比较稳?

⚠️ 高风险场景警告!:别把第一个CMP页面选在登录/支付/下单这些链路上!这些场景: • 有严格UI规范要求 • 需要高度定制化交互 • 一旦出错影响面大

安全起见:

设置页)

纯展示详情页

简单列表页

>最小CMP页面代码示例 <<<<

@Composable fun ProfileScreen {
val uiSate by holder.state.collectAsState
when{
uiSate.loading-> CircularProgressIndicaator
uiSate.error!=null->Text
else ->Text
}}

>关键优势 <<< • 最快见效且风险最低 • 能验证跨平台UI架构是否可行

迁移里最容易复现的坑!

>>通病#1:

>典型场景: • 权限管理 • 推送SDK集成 • 支付能力封装 • 生物识别等本地特性

方法:-继续放在网站层,只通过接口向shared暴露业务结果!

>典型场景:-JSON解析 • 数据库批量操作 • CPU密集运算

方法:-强制使用CoroutineDispatcher控制执行线程!话说回来，

>典型场景:-订阅后忘记取消导致内存泄漏

方法:-包装watch+close函数显式化生命周期管理!不过，

>典型场景:-同时修改网络/DB/UI三大模块

方法:-每次只做垂直切片更新!

按照这个顺序做,基本不会翻车:

1. 建立shard。只放模型和1个接口请求

>>为什么?:逐步摸索KMM建立配置而不影响主业

---

贝注事项: ① 不要一次性提交大量代码 ② 不要删掉原生Android仓库层代码直到新实现稳定运行!③ 每次提交前检查CI通过情况!

---

---