说实话，2025年这开局，真有点让人目不暇接的感觉。不知道大家有没有发现，跨平台开发这个领域又热闹起来了。这背后可Neng有“鸿蒙Next”带来的紧迫感，也可Neng是因为大厂们的技术积累到了该换个活法的时候，当然咱们也不Neng忽视那个在圈子里流传的“降本增笑”的梗。不管怎么说今年上半年，各种新框架、新版本像雨后春笋一样冒出来确实让人有点挑花眼。

今天咱们不聊那些虚头巴脑的概念，就来盘一盘Zui近这些让人心动的技术geng新。毕竟技术选型这事儿，选对了Neng让你少掉几根头发，选错了嘛……那就只Neng自求多福了。

Flutter：老将新招，Impeller 终于成了大气候

先说说 Flutter 吧。这老伙计在“自绘”这条路上坚持了这么多年，相信大家dou不陌生。因为它走的是“自绘”加“AOT模式”的路子，所以在平台统一性和性Neng表现上，一直挺Neng打的。但是以前大家总吐槽它在 iOS 上偶尔会“卡顿”一下这事儿其实不Neng全怪它。

要知道，跨平台框架毕竟不是系统的“亲儿子”。以前 Flutter 依赖 Skia，而传统的 Skia 需要把绘制命令编译成 GPU Neng懂的代码，这个过程叫着色器编译。问题是Skia 往往是在运行时才去干这个编译的活儿。Ru果这时候编译速度跟不上帧率，画面就会掉帧，也就是咱们常说的“Jank”或者“着色器卡顿”。这体验，确实挺搞心态的。

不过现在情况变了。Flutter 的核心竞争力Yi经转移到了 Impeller 身上。这玩意儿简单说就是：App 需要的所有着色器，在 Flutter 引擎构建的时候就Yi经离线编译好了根本不需要等到应用运行时再去手忙脚乱地编译。这就好比是预制菜和现炒菜的区别，上菜速度Neng一样吗？

而且，Google 自家的 Skia 项目也没闲着，他们有个 Graphite 后端正在推进，内部也是参考 Impeller 的思路在Zuo改进。未来 Skia 也Neng支持部分场景的提前编译，这算是双保险了。甚至华为那边也没闲着，针对 Flutter 在鸿蒙上的适配，官方分享里提到了 Flutter 引擎 Impeller 的鸿蒙化，这波操作必须点赞。

除了渲染引擎的升级，Flutter 还有个挺大的变化，那就是 Platform 和 UI 线程的合并。以前 Dart 的主线程和平台的 UI 线程是各跑各的，交互数据dou得经过 Channel 传话，效率多少有点打折。现在合并之后Dart 和原生语言Ke以直接同步调用了这为 Dart 和 Kotlin/Java、Swift/OC 的直接互操作打下了基础。虽然这改动也带来了一些新问题，但总体来kan，是利大于弊的。

当然Flutter 也不是完美的。它的局限性其实也不少，比如那个让人头大的包体积问题，还有对原生控件的集成难度。不过Ru果你想Zuo点类似游戏的东西，配合 Rive 的状态机，或者用官方的游戏 SDK、Flame 之类的，那效果还真挺让人惊喜的。

Kotlin 生态的反击：Kuikly 与 CMP 的双雄并立

再来kankan Kotlin 阵营。2025年，Compose Multiplatform的热度那是相当高，尤其是 Compose Multiplatform iOS 稳定版发布之后这算是第二个使用 Skia 的自绘框架，基本完成了跨平台的稳定之路。

CMP 的Zui大优势其实就是 Kotlin 本身。Kotlin 的编译器太强大了支持各种编译过程和产物，这让 KMPNeng灵活适配各种平台。而且 Kotlin 的语法糖确实香，用过的开发者忠诚度dou挺高。在 Android 上，CMP 依赖系统的 Skia，所以 APK 体积相对较小；在 PC 端，得益于 JVM 的成熟度，体验也相当不错。

不过CMP 在鸿蒙平台的适配上，目前好像还不是 JetBrains 官方提供的方案。华为暂时也没说有啥适配计划，现在Yi知的 CMP/KMP 适配，基本dou是大厂自己在倒腾，有的基于 KN 的 llvm 方案，有的用 Kotlin/JS 的低成本方案，路线五花八门。

这时候，腾讯的 Kuikly 就hen有意思了。其实 Kuikly 也算是 KMP 体系的跨平台框架，只不过腾讯刚开始Zuo它的时候，CMP 还没影儿呢。一开始 Kuikly 是通过 KMM 实现的，后来在 UI 层搞了自己的方案。

Kuikly 和 CMP Zui大的不同在于底层虽然dou是 KMP，但绘制上 Kuikly 走的是类 RN 的路子。它现在主要是在 KMP 基础上用自研 DSL 来构建 UI。比如在 iOS 平台，它的 UI Neng力就是基于 UIKit 的。大家geng熟悉的 Compose 支持，目前还在开发中。

这其实才是 Kuikly 的聪明之处：它实现了一套“薄原生层”。这个原生层非常“薄”，只暴露Zui基本、没逻辑的 UI 组件。真正的 UI 逻辑全在共享的 Kotlin 代码里实现。也就是说Kuikly 虽然依赖原生控件，但大部分控件的实现dou被“提升”到了 Kotlin 共享层。据说目前 Kuikly 实现了 99% UI 组件的纯 Kotlin 组合封装，根本不需要 Native 提供原子控件。

通过把 UI 逻辑抽象到共享的 Kotlin 层，Kuikly 减少了平台差异的可Neng性，“薄原生层”就像一个一致的渲染目标，确保 Kotlin 定义的 UI 元素Neng和腾讯自家的热geng新管理平台无缝集成，这绝对是个大杀器。后续它还打算支持全平台小程序，这优势就geng明显了。

当然Kuikly 也有局限。比如动态化场景目前只支持 Kotlin/JS，可动态化的类型也有点限制。而且，SwiftUI 和 Compose 虽然不Neng直接和 Kuikly 一起用，但 Kuikly Ke以在 DSL 语法和 UI 组件属性上对齐两者的写法，让你感觉像是在用 Compose 或 SwiftUI。

那么你会为了小程序和鸿蒙选择 Kuikly 吗？

相信从今年开始，CMP 会是 Android 原生开发者在跨平台时的首选之一。毕竟 Kotlin 生态不需要你去额外学 Dart 或者 JS 体系。但是Kuikly 这种“薄原生”+“强动态”的思路，是不是geng对你的胃口呢？

Web 技术的逆袭：React Native 与 Lynx 的进化

说到 React Native，这可是我接触的第一个真正意义上的跨平台框架，到现在dou十年了。Ru果你hen久没关注过它，那 2025 年的 RN 绝对会超乎你的想象。

RN 的核心一直是对齐 Web 开发体验。新架构成了默认框架之后Fabric、TurboModules、JSI 这些Neng力解决了hen多历史遗留的性Neng瓶颈。现在新版 RN 也支持热重载，还Nenggeng快地对齐 React 的新特性，比如 React 19 的 Actions、改进的异步处理等等。

geng猛的是RN 开始引入 WebGPU 支持。这意味着它Neng确保与 Web 端的 WebGPU API 完全一致，开发者Ke以直接复制代码示例，还Neng实现和 Web Canvas API 对称的 RN Canvas API。WebGPU 的引入还让 RN 开发者Neng利用 ThreeJS 生态，直接引入Yi有的 3D 库，这让 RN 的Neng力进一步对齐了 Web。

另外RN 在 Skia 和 WebGPU 上的探索也值得一提。它并不是想变成自绘引擎，而是在动画、图像处理等场景下增加了强力补充。比如 React Native Skia Video 模块，实现了原生纹理到 React Native Skia 的直接传输，优化了内存和渲染速度。

当然RN 也有它的局限性。Zui直观的就是平台 UI 的一致性和样式约束，这是 OEM 框架的天生局限。而且，虽然它对 Web 前端hen友好，但对客户端开发者来说学习成本还是有点高。除了 Android、iOS 和 Web 的类 RN 实现外其他平台的支持和自绘Neng力目前还不太明确。在 PC 领域，虽然微软提供了 Windows 和 macOS 支持，社区也有 Web 和 Linux 的支持，但占有率实在不高，一般也就忽略了。

不过RN 在鸿蒙适配上也没落下。华为推进的鸿蒙版 RN Yi经正式开源了它采用 XComponent 对接到 ArkUI 的后端接口进行渲染。再加上成熟的 code-push 热geng新支持，RN 的老大哥地位依然稳固。

字节跳动的 Lynx：前端开发者的新宠？

Ru果说 Kuikly 是面向客户端的全平台框架，那字节跳动的 Lynx 就是一个完全面向 Web 前端的跨平台全家桶。

Lynx 开源的首个支持框架是基于 React 的 ReactLynx。官方也说了Lynx 不局限于 React，未来不排除有 VueLynx、SvelteLynx 之类的。Lynx 作为核心引擎，其实并不绑定任何特定前端框架，只是目前你Neng用的暂时只有 ReactLynx。

从技术特点上kan，Lynx 的源代码标签在运行时会被引擎解析，翻译成用于渲染的 Element，嵌套的 Element 组成一棵树，从而构建出 UI 界面。官方介绍里说它要“在移动和桌面端达到像素级一致的自渲染”，虽然目前kan起来还是个类 RN 框架，但宣传中提到的“自渲染”切换Neng力，还是挺让人期待的。

Lynx 的优势在于对“即时首帧渲染”和“丝滑流畅”交互体验的先天支持。它的双线程模型及主线程脚本让启动和第一帧渲染速度相当不错。而且，它自主开发的渲染后端支持 Windows、tvOS、MacOS 和 HarmonyOS。

官方也建议，Lynx Zui初可Nenggeng适合作为模块嵌入到现有的原生应用中，用于构建特定视图或功Neng，而不是从零开始构建一个完整的独立应用。从宏观目标kan，Lynx 既支持类 RN 实现，又有自绘计划，除了 React，后期还要适配 Vue、Svelte，Ke以说是完全针对 Web 开发而存在的跨平台架构。

不过Lynx 也有它的短板。 它太年轻了虽然饼画得hen大，但社区、生态系统、第三方库这些dou还需要时间成长。而且，开发环境Zui好选 macOS，Windows 和 Linux 平台的工具链兼容性目前还需要打磨。

编译时革命：uni-app x 的硬核尝试

说到 uni-app，大家第一印象肯定还是小程序。虽然它也Neng打包客户端 App，甚至有基于 Weex 的 nvue 支持，但效果嘛，确实有点“一言难尽”。

但是DCloud 这两年搞了个新尝试，叫 uni-app x。这玩意儿可不一样了。它不再是运行在 JSCore 上的跨平台框架，而是“基于 Web 技术栈开发，运行时编译为原生代码”的模式。简单说就是你的 JS代码在打包时会直接编译成原生代码。

在 uni-app x 里你甚至不需要单独写插件去调用平台 API。你Ke以直接在 UTS 代码里引用平台原生 API，因为你的代码本质上也会被编译成原生代码。所以UTS ≈ native code。当然使用时需要配置对应的条件编译来支持。

比如你Ke以直接 `import BatteryManager from "android.os.BatteryManager"`，然后像写原生代码一样用。这种“代码混写”的感觉，确实挺爽的。在 UI 上，除了编译为 ArkUI 之外Android 和 iOS 其实dou是编译成原生体系。Android 应该是编译为传统 View 体系而不是 Compose，iOS 应该也是 UIKit。按照官方的说法，性Neng和原生是相当的。

所以uni-app x 是一个类 RN 的编译时框架。它的优势在于编译器转译得到原生性Neng，但它的劣势也在于转译。毕竟转译这事儿，太依赖编译器的强大程度了。

其他领域的声音

除了这些移动端的大头，其他领域也没闲着。

比如网络通信这块，历时一年，acl 跨平台网络通信及服务器框架库也发布了大版本升级。这次重构了网络协程库，支持 Linux/FreeBSD/MacOS/Windows 等geng多操作系统，而且支持 epoll/select/poll/kqueue/iocp/Win32 GUI 等各种网络事件引擎。ACL 服务容器也从基础库里独立出来了变成了一个独立的模块，还增加了服务管理工具链。这对于Zuo后端或者底层通信的同学来说绝对是个好消息。

还有 Remobjects Software 公司的 Remoting SDK 9，这是他们屡获殊荣的跨平台远程处理框架的新版本，可Neng是他们多年来发布的Zui重要的一次geng新。它支持跨平台和移动应用程序开发，支持 C#、Visual Basic、Oxygene 和 Swift，还Neng和 Visual Studio、Fire 集成。

至于 Qt 这种老牌劲旅，虽然现在讨论得不如前端框架多，但 Qt 5.9 LTS 乃至后续版本，在物联网和工业领域依然稳如泰山。毕竟对于 C++ 图形用户界面应用程序开发来说Qt 还是那个绕不开的大山。

你会怎么选？

kan了一圈下来2025 年的跨平台市场真是百花齐放。Flutter 靠 Impeller 继续领跑性Neng，Kotlin 阵营靠 CMP 和 Kuikly 攻城略地，RN 靠 WebGPU 和新架构焕发第二春，Lynx 和 uni-app x 则在各自的细分领域寻找突破口。

其实没有Zui好的框架，只有Zui适合你业务场景的框架。你是kan重极致的性Neng？还是开发效率？或者是热geng新的灵活性？亦或是对鸿蒙的完美适配？

甚至有时候，选择一个框架不仅仅是因为技术，还因为面试的时候Neng吹得动，或者团队里大家dou会。毕竟“就算你不用，也许面试的时候就糊弄上了”？

那么面对这些 2025 年的新版本、新特性，你的心里有答案了吗？你会为了 Kotlin 的优雅选择 CMP，还是为了 Flutter 的稳定继续坚守，或者是尝试一下 Lynx、uni-app x 这些新面孔？不管怎么选，技术这行，永远不缺惊喜，缺的只是敢于尝试的勇气。

---