Kotlin Multiplatform 与 AI 图像修复的融合实践
在移动开发领域，我们常常面临一个现实困境：同一款应用要在 Android 和 iOS 上实现完全一致的功能，却不得不由两支团队分别用 Kotlin 和 Swift 实现几乎相同的业务逻辑。尤其当功能涉及复杂的图像处理时，这种重复劳动不仅耗时，还容易导致双端行为不一致。
有没有可能让两个平台共享一套核心逻辑？答案是肯定的——Kotlin Multiplatform（KMP）正在悄然改变这一局面。它不是另一个“全栈跨平台”框架，而是一种更务实的思路：保留原生 UI 的流畅体验，只把那些真正可以复用的部分抽出来，比如网络请求、数据解析、状态管理，甚至是对 AI 模型的调用。
最近我们在开发一款老照片智能修复 App 时，就尝试将 KMP 与DDColor 黑白图像上色模型结合使用。结果令人惊喜：原本需要双端各自实现的图像上传、参数校验、AI 调用等流程，现在只需在一个共享模块中维护即可，代码复用率超过 75%。更重要的是，Android 和 iOS 用户看到的修复效果完全一致，再也不用担心因为参数差异导致一边颜色偏暖、一边偏冷的问题。
共享不只是代码，更是逻辑的一致性
很多人初识 KMP 时会误以为它只是“写一次 Kotlin，跑在两边”。其实它的精髓在于expect/actual机制——允许你在公共模块中声明一个接口或变量（expect），然后在各个平台提供具体实现（actual）。这种方式既保证了抽象层面的一致性，又不失灵活性。
举个例子，在图像修复场景中，我们需要获取设备信息用于日志追踪：
// commonMain expect val platform: String // androidMain actual val platform: String = "Android" // iosMain import platform.UIKit.UIDevice actual val platform: String = UIDevice.currentDevice.systemName() + " " + UIDevice.currentDevice.systemVersion这段代码看似简单，但它背后体现的设计哲学很关键：共用契约，分治实现。你不需要强迫 iOS 工程师去学 Android 的 Build 类，也不用为 Swift 写一堆桥接代码，大家只需要遵循同一个接口规范就行。
同样的思想也可以用在网络层。我们可以定义一个通用的服务类来封装对 DDColor 模型的调用：
class DdcolorService(private val client: HttpClient) { suspend fun uploadAndRestore( imageBytes: ByteArray, modelType: ModelType, size: Int ): Result<ByteArray> { return try { val response: HttpResponse = client.submitFormWithBinaryData( url = "http://comfyui-server/v1/ddcolor/restore", formData = formData { append("image", imageBytes, Headers.build { append(HttpHeaders.ContentType, "image/jpeg") }) append("model", modelType.name.lowercase()) append("size", size.toString()) } ) if (response.status.isSuccess()) { Result.success(response.readBytes()) } else { Result.failure(Exception("Server error: ${response.status}")) } } catch (e: Exception) { Result.failure(e) } } } enum class ModelType { BUILDING, PERSON }这个DdcolorService完全运行在共享模块中，使用的也是 Ktor 这样支持多平台的网络库。Android 端注入 OkHttp，iOS 端注入 URLSession，底层不同，但上层 API 完全统一。这样一来，无论是哪边发起请求，传参规则、错误处理、响应解析都是一样的。
DDColor 模型：让老照片“活”过来的技术
说到修复老照片，传统方式要么靠专业修图师手动上色，费时费力；要么用一些通用的自动上色工具，但效果往往不尽人意——肤色发绿、天空变紫，色彩分布毫无逻辑。
而 DDColor 模型之所以能在众多方案中脱颖而出，是因为它做了两件事：专用化训练和场景区分。
该模型基于卷积神经网络（CNN）或 Transformer 架构，在大量配对的老照片与现代彩色图像上进行训练，学习从灰度到 RGB 的映射关系。更重要的是，它提供了两种独立的工作流模板：
DDColor建筑黑白修复.json：针对建筑物材质、纹理优化，强调历史风貌的真实性；DDColor人物黑白修复.json：专注于人脸肤色、衣物细节还原，增强人物生动感。
这意味着用户上传一张祖辈合影时，系统可以选择“人物模式”，优先保证面部自然；如果是老城区街景，则切换至“建筑模式”，保留砖墙质感和屋顶色调。
在 ComfyUI 的可视化工作流中，这些步骤被封装成节点链路，开发者无需关心模型内部结构，只需通过 HTTP 接口提交图像和参数即可获得结果。整个过程通常在 GPU 加速下 10 秒内完成，非常适合移动端集成。
如何构建一个可扩展的图像处理架构？
我们最终采用的系统架构分为三层：
+---------------------+ | Platform UI | ← Android (Jetpack Compose) / iOS (SwiftUI) +---------------------+ | Kotlin Multiplatform Layer | ├─ Common Logic | ← 数据模型、状态管理、网络请求 | ├─ Expect/Actual | ← 平台适配：文件访问、权限请求 | └─ AI Gateway | ← 封装对 ComfyUI DDColor API 的调用 +---------------------+ | Backend Services | ← ComfyUI Server + DDColor 模型 +---------------------+这套设计有几个关键考量点：
1. 合理划分共享边界
并不是所有东西都要放进共享模块。UI 组件、手势动画、相机预览这类强平台依赖的功能，依然保留在各自工程中实现。共享层只负责“稳定且无 UI”的部分，比如：
- 图像元数据提取（EXIF）
- 文件压缩与格式转换
- 参数配置与合法性校验
- 任务队列调度与重试机制
这样既能最大化复用，又能避免过度抽象带来的维护成本。
2. 参数控制不能放任自流
早期测试发现，如果允许用户随意设置size参数，很容易出现内存溢出或推理超时。于是我们在共享层内置了安全范围检查：
fun validateSize(modelType: ModelType, size: Int): Boolean { return when (modelType) { ModelType.BUILDING -> size in 960..1280 ModelType.PERSON -> size in 460..680 } }这样一来，无论哪一端调用，都会受到相同的约束。而且未来如果服务端升级支持更高分辨率，我们也只需修改一处逻辑即可生效。
3. 隐私保护必须前置
老照片往往承载着家庭记忆，上传前必须明确告知用户用途，并启用 HTTPS + Token 认证传输。我们在共享模块中统一实现了加密上传流程，确保两端在安全性上不留死角。
4. 可观测性不可或缺
为了监控服务质量，我们在共享层加入了轻量级埋点机制，记录每次修复的耗时、模型响应时间、失败原因等指标。这些数据帮助我们判断是否需要扩容服务器资源，或者优化某些低效路径。
为什么这比 Flutter 或 React Native 更适合某些场景？
有人可能会问：既然目标是跨平台，为什么不直接用 Flutter？毕竟它连 UI 都能统一渲染。
但我们的经验是：对于已有成熟原生团队的产品，KMP 是更平滑的选择。
- Flutter 要求彻底重构 UI 层，学习 Dart 语言，放弃已有的 Jetpack Compose 或 SwiftUI 投资；
- 而 KMP 支持渐进式迁移——你可以先从网络层开始，再逐步将状态管理、数据模型迁入共享模块，不影响现有功能迭代。
尤其在涉及 AI 功能时，KMP 的优势更加明显。它不像全跨平台框架那样需要层层桥接才能调用本地服务，而是可以直接通过actual实现在 iOS 调用 Metal 加速、Android 使用 NNAPI 的能力。虽然当前案例走的是远程 API，但未来若想做本地推理，迁移成本也极低。
不止于修复，更是通往 AI 原生应用的桥梁
这项技术组合的价值远不止于“省了几千行代码”。
想象一下，未来你可以构建一个跨平台的AI 图像处理 SDK，支持多种模型插件：
- 老照片上色（DDColor）
- 图像超分（Real-ESRGAN）
- 噪点去除（DnCNN）
- 缺失区域补全（LaMa）
每个模型都有自己的工作流模板和参数空间，但调用方式完全统一。开发者只需引入共享库，选择模型类型，传入图像，就能获得处理结果。这一切都不需要关心平台差异。
企业级应用场景也随之打开：
- 博物馆数字化项目可以用这套方案批量修复历史影像；
- 家庭相册 App 可以提供一键美化功能；
- SaaS 平台甚至可以按次计费，打造订阅制的老照片修复服务。
写在最后
Kotlin Multiplatform 的意义，从来不是取代原生开发，而是成为连接移动端与后端 AI 能力的“中间层”。它让我们可以把精力集中在真正重要的事情上：如何设计更好的用户体验，如何提升 AI 输出的质量，而不是反复写着几乎一样的上传逻辑。
当一位老人看着手机里泛黄的全家福重新焕发生机，眼里闪烁出光芒的时候，我们知道，技术的意义正在于此。
而 KMP + DDColor 的组合，正是让这样的时刻更容易发生的工具之一。
