跳到内容
CrossFly 是 100% 开源在 GitHub 关注我们
CrossFlyCrossFly
开始使用
对比框架

CrossFly vs Kotlin Multiplatform

这是榜单上最接近的一场对比——CrossFly 和 Kotlin Multiplatform 都来自 JVM 世界、都编译为原生二进制文件,所以“原生性能”是平手。真正的差异在于语言和 UI 模型:CrossFly 是纯 Java,各处都用一套 GPU 绘制的 UI;KMP 是 Kotlin,共享你的业务逻辑,而 UI 按平台保持原生(或使用 Compose Multiplatform,其 iOS 支持直到 2025 年才稳定)。

一句话总结—— 当你是一家想共享逻辑、保留原生 UI 的 Kotlin/Android 团队时,KMP 很出色。CrossFly 则赢在你想留在 Java、在桌面和移动上交付一套 UI,并跳过 Kotlin/Native 的 iOS 互操作以及 Gradle/CocoaPods 构建摩擦。

留在 Java
无需全团队迁移到 Kotlin
1 套共享 UI
而非“共享逻辑、每个平台重建 UI”
无 ObjC 桥
没有 Kotlin→ObjC→Swift 的翻译成本
CrossFly · Java

CrossFly 是一个开源框架(Apache 2.0),你用纯 Java 编写 UI 和逻辑,它通过 LibGDX/OpenGL 在 GPU 上渲染,并编译为桌面端(Windows、macOS 和 Linux)、Android 和 iOS 的原生二进制文件,以及可在 Chrome、Firefox、Safari 等任何现代浏览器中运行的 WebGL 构建。搭配 CrossFly Sync 即可实现离线优先的数据。

Kotlin Multiplatform · Kotlin

Kotlin Multiplatform(KMP)是 JetBrains 的开源(Apache 2.0)技术,用于在 Android、iOS、桌面和 Web 之间共享代码——逻辑、网络、数据——而 UI 按平台保持原生。Compose Multiplatform 是其可选的共享 UI 工具包(Skia 渲染),自 2025 年 5 月起在 iOS 上稳定。

真正重要的差异

两个 JVM 表亲,在语言、UI 和工具上下了两注很不一样的赌。

01 · 差异

它是 Kotlin 优先,而非 Java

痛点: Kotlin Multiplatform

KMP 的共享代码是 Kotlin。Kotlin 在 JVM 上与 Java 的互操作很好,但 Kotlin/Native(iOS)和 Kotlin/Wasm 是 Kotlin 工具链——并不是“运行你现有的 Java”。一个纯 Java 的企业团队不得不押注 Kotlin 作为其共享语言。

而 CrossFly

CrossFly 让你从头到尾留在 Java。没有全团队的语言迁移——你的 Java 开发者、库和惯用法直接带进每个平台的应用里。

02 · 差异

iOS 的互操作层有损耗

痛点: Kotlin Multiplatform

在 iOS 上,Kotlin 只能通过一个生成的 Objective-C 桥与 Swift 对话。那层翻译正是尖锐棱角所在:可空整数被装箱、密封类失去穷尽 switch、Kotlin Flow 变成笨拙的回调、泛型坍缩为 Any?。JetBrains 那套地道的修复方案 Swift Export 尚未就绪。

而 CrossFly

CrossFly 只有一条在 GPU 上绘制的渲染与逻辑路径——没有 Kotlin→Obj-C→Swift 的边界要跨越,所以那些互操作损耗从一开始就不会出现。

03 · 差异

iOS 上的共享 UI 还年轻

痛点: Kotlin Multiplatform

如果你也想共享 UI,那就是 Compose Multiplatform——它直到 2025 年 5 月才在 iOS 上达到稳定,文本框无障碍落地得更晚,而 web/Wasm 仍在测试版。它是 Skia 渲染(不是原生控件),所以在 iOS 上看起来像 Material,而非 Cupertino。

而 CrossFly

CrossFly“自己绘制 UI”的模型就是整个框架,而非一个新近才稳定的层——从第一天起就在桌面和移动上有一套一致的 UI。(如果你需要按平台的原生外观,KMP 的原生 UI 选项是一项真正的优势——见公平对待那一栏。)

04 · 差异

构建矩阵就是那笔税

痛点: Kotlin Multiplatform

KMP 意味着 Gradle-multiplatform——JetBrains 自己都称之为“令人不知所措”——外加脆弱的 CocoaPods 集成、一个只在 macOS 上工作的 iOS 插件,以及缓慢的 Kotlin/Native 编译。预期会有实实在在的搭建和迭代摩擦,尤其是在 iOS 一侧。

而 CrossFly

CrossFly 单语言、单工具链的模型让构建故事简单得多——在你和一个能在三个平台上运行的应用之间,活动的零件更少。

CrossFly 领先之处

纯 Java——你现有的 Java 团队无需把 Kotlin 采纳为共享语言即可交付跨平台。
为每个目标提供一套 GPU 绘制的 UI,而非共享逻辑、每个平台重建 UI。
没有 Kotlin→Objective-C→Swift 的互操作层,因此不会有它那些装箱/密封类/Flow 的翻译损耗。
更简单的构建故事——没有 Gradle-multiplatform + CocoaPods 矩阵要驯服。
CrossFly Sync 把离线优先数据作为产品交付,而非一个你自己拼装的库。

Kotlin Multiplatform 真正强大之处

由 JetBrains 打造,并获 Google 官方支持用于 Android/iOS 逻辑共享。
Kotlin 是一门现代、广受喜爱的语言,与 JVM 的互操作出色。
独具灵活性的 UI:既可交付 100% 原生的 SwiftUI/UIKit,也可用共享的 Compose Multiplatform。
通过 Compose for Desktop 提供成熟、经生产验证的桌面;被 Netflix、McDonald's 和 Cash App 采用。

CrossFly 对比 Kotlin Multiplatform 一览

维度CrossFlyKotlin Multiplatform
语言JavaKotlin
运行时原生二进制(JVM 血统)原生二进制(Kotlin/Native,JVM 血统)
共享的内容UI + 逻辑,一份代码默认共享逻辑;UI 原生或经 Compose MP
UI 模型各处一套 GPU 绘制的 UI按平台原生,或 Compose MP(Skia)
iOS UI 成熟度核心框架Compose MP iOS 自 2025 年 5 月起稳定
iOS 互操作一条路径,无 ObjC 桥Kotlin↔Objective-C 桥(Swift 经生成层)
构建/工具单一 JVM 工具链Gradle-multiplatform + CocoaPods;iOS 插件仅限 macOS
离线优先CrossFly Sync(双向)从库里拼装
桌面一等公民(Win/mac/Linux)经 Compose for Desktop 成熟
许可开源(Apache 2.0,Core)开源(Apache 2.0)

在以下情况选择 CrossFly

你的团队在 Java 上,且不想统一到 Kotlin。
你想要一套跨桌面和移动的共享 UI,而非按平台做 UI 的工作。
你宁愿避开 Kotlin/Native 的 iOS 互操作以及 Gradle/CocoaPods 矩阵。

在以下情况选择 Kotlin Multiplatform

你是一家 Kotlin/Android 团队,想在保留原生 UI 的同时共享逻辑。
按平台的原生观感(SwiftUI/UIKit)是优先项。
你看重 JetBrains/Google 的背书和庞大的生产实绩。
一句话结论

对于 Kotlin 和 Android 团队来说,Kotlin Multiplatform 是共享逻辑、保留原生 UI 的绝佳方式,背后有 JetBrains 和 Google 支撑。代价是它 Kotlin 优先,其 iOS 互操作和共享 UI 都带有实实在在的摩擦,而构建矩阵很重。CrossFly 下的是另一注赌:留在 Java、为每个平台在 GPU 上绘制一套 UI,并让工具链保持简单。如果你的世界是 Java,而你想各处都用一套 UI,CrossFly 是更直接的路径。

CrossFly 对比 Kotlin Multiplatform——常见问题

一门语言。一套 UI。每个平台。

留在 Java,在 GPU 上绘制一次,交付到桌面端(Windows、macOS 和 Linux)、Android、iOS 和网页(Chrome、Firefox、Safari 等浏览器)——没有 Kotlin/Native 的构建矩阵。

开始构建查看所有对比