前言
在前面的十一篇文章中，我们深入探讨了 Compose 在 Android 上的底层原理、性能优化和架构实战。作为一名十年 Android 开发，你可能觉得已经掌握了它的精髓。
但真正的惊喜现在才开始。
你辛苦写出的那些漂亮的 Composable 函数、精准的 MVI 逻辑，不仅仅能跑在 Android 手机上。通过 Compose Multiplatform (CMP)，它们可以无缝降临到 iOS、桌面端（macOS/Windows/Linux）甚至浏览器（Web）。
今天，我们就来揭开 Compose 跨端的神秘面纱：它到底是“套壳”还是“原生”？一套代码又是如何搞定不同平台的交互差异的？
一、 核心揭秘：为什么 Compose 天然适合跨端？
我们在第一篇架构解析中提到过，Compose 实现了彻底的**“去 View 化”**。
- Skia 引擎的力量：Compose 并不调用平台的原生控件（如 iOS 的
UIButton）。它自带了一个强大的 2D 图形库 —— Skia。 - 像素级复刻：在 iOS 上，Compose 向系统申请一个画布，然后由 Skia 引擎根据 Kotlin 代码直接绘制像素。
- 结论：这意味着你在 Android 上看到的圆角、阴影和动效，在 iOS 上会分毫不差地呈现。这与 Flutter 的理念一致，但比 Flutter 更纯粹——因为它是 100% Kotlin 编写的。
二、 四大平台的实现路径
1. iOS：穿透 Objective-C
Compose 编译成 Native 代码，通过 MainViewController 嵌入到 SwiftUI 或 UIKit 中。性能接近原生，且能完美调用 CInterop（正如我们在本专栏项目中实现的）。
2. Desktop：JVM 的二次春
基于 Compose for Desktop。它利用 JVM 的高性能和 Skia 的本地链接，让你可以用写 App 的逻辑去写复杂的桌面办公软件。
3. Web：Wasm 的奇迹
这是目前最前沿的方向。Compose 通过 Kotlin/Wasm 将 Kotlin 直接编译成浏览器可执行的二进制指令，绕过了 JavaScript 性能瓶颈，实现了流畅的 Web UI。
三、 处理差异：Expect/Actual 与 组合项抽象
虽然 UI 逻辑可以共享 90% 以上，但有些东西是无法共享的，比如：调用系统相册、获取电池电量、或者特定的平台手势。
1. 逻辑层：expect/actual
这是 KMP 的招牌动作。在 commonMain 声明，在各平台 actual 实现。
2. UI 层：组合项抽象
你可以针对不同平台定义不同的 Composable：
@Composable
fun PlatformSpecificButton(text: String, onClick: () -> Unit) {
if (isIOS) {
CupertinoButton(onClick) { Text(text) } // 使用高仿 iOS 风格的库
} else {
Button(onClick) { Text(text) } // 标准 Material 风格
}
}
四、 给开发者的跨端避坑指南
- 资源管理（Resources）：
不要再用
R.drawable.xxx。必须改用composeResources。这套新方案允许你将图片、字体放在commonMain中，全平台通用。 - 软键盘与窗口边距（Window Insets）：
Android 有
Modifier.imePadding()，但在 iOS 上处理状态栏和刘海屏（Safe Area）的逻辑略有不同。建议使用WindowInsets.asPaddingValues()这一套通用 API。 - 导航（Navigation）：
虽然我们在第九篇讲了 Navigation Compose，但在多端项目中，你需要确保你的导航图定义在
commonMain中。
五、 开发者的终极思考：这会取代原生吗？
作为一个 Android 老兵，我必须诚实地说：它不会完全取代原生，但它会吞掉 80% 的业务开发。
- 什么时候用原生：开发系统桌面工具、深度依赖底层 Framework（如桌面小部件、特定系统服务）时。
- 什么时候用 CMP：绝大多数业务 App、企业级工具、全栈全平台同步的项目。
结语
Compose Multiplatform 的出现，标志着“Kotlin 全栈时代”的到来。它让 Android 开发者的技能价值放大了四倍。
下一篇我们将探讨：跨平台资源管理与多语言：composeResources 的统一方案。
如果你觉得有帮助，欢迎点赞关注，我们在代码上演进，在原理上深耕。
