标签 Compose Multiplatform 下的文章

想必做移动端的朋友们肯定或多或少听说过 Kotlin 和 Compose Multiplatform,
前者是 JetBrains 开源、Google 首推用于 Android 开发(自 2019 年 Google I/O 大会起)的现代开发语言,
后者是使用 Compose API 开发多端(Android、iOS、桌面端、Web 端等)应用的 UI 框架。

但是不论你是使用 Compose/Kotlin 开发应用,还是使用其他解决方案,都会有一个苦恼:使用代码编写 UI,
终归是不如大家最喜欢的拖拖拽拽来的直观。你选择 Compose/KMP 的理由,其中大概率有一条会留给它的多平台逻辑共享与原生互操作能力,
避免中间层的出现,可以有更好地表现效果与上限。

那么有没有什么办法,可以即让我使用 Compose 开发应用、又可以借助 AI 神力并且以拖拉拽的形式而免去需要写代码的苦恼?
如果你有这些想法,那么也许你可以关注一下 ComposeFlow: 一个 Compose Multiplatform 的可视化应用构建器。

注意,这篇文章图片会比较多喔~

什么是 ComposeFlow

ComposeFlow 是一个 Compose Multiplatform 的可视化应用构建器,它通过 AI 代理和直观的拖放界面,
赋能开发者、企业家、设计师和产品经理创建功能完整的应用程序。它能生成完整的、可运行的 Compose Multiplatform 项目,
并提供干净的 Kotlin 代码,支持桌面、Android、iOS 和 Web 等多个平台。

以上是它们的 GitHub 仓库中的首段自我介绍。
简单来说,它就是一个 AI 驱动、可视化、拖拉拽的 Compose Multiplatform 开发工具。


图片来自官方 GitHub README 中的配图。

更多信息,你可以前往它们的 文档 了解更多。

使用

安装

首先需要知道,这个工具目前仍处于早期阶段,因此可能存在各种各样的问题,我们今天就只是尝鲜为主。

根据 GitHub 的说明,我们前往它们的下载页面去下载对应的应用(Windows 用户可以直接使用 Microsoft Store 安装)。
安装完成后,它会提示你登陆账号(也可以不登录,只不过那样就不能使用 AI 服务了),我选择使用 Google 账号登陆。

登录后,这就是它的首页:

创建项目

毕竟是新安装的,我们先来创建一个项目。

就按照它的推荐提示词,创建一个任务管理的应用,为了方便演示,我加了一句 “USE CHINESE”,其他的内容均未修改。




通过 AI 提示词创建一个项目的基本过程就在上面了。它会根据你的基础提示词,设计出几个详细的界面设计,
然后再根据每个界面的细节内容生成具体的界面布局与样式,然后在右侧供你预览。当一切就绪,你就可以直接创建项目了。

作为一个尝鲜体验,我就不修改什么了,直接默认并创建即可~

那么接下来,我们点击 create project 创建一个项目看看。

项目视图

首次进入项目内容,它会给你一个引导,欢迎你,并告诉你一些操作方法:

项目的左侧,是各类工具视图,它们提供了添加文字、图标等组件的 UI 构筑功能,以及布局功能等等,如图所示:

接下来,为你介绍了画布的正中央:你的 UI 表现效果,以及画布尺寸、明暗等内容的配置和展现。

随后是右半侧,提供了选中组件的各类属性信息的展示与编辑等。

当然,作为一个 AI 驱动的工具,除了构建项目之外,肯定也会在其他功能上增加 AI 能力。左上角的小图标便是提供 AI assistant 能力的地方。

接下来引导就结束了,然后便是我们自由发挥的时候啦。
下面便是我生成的项目的一些基本样式与信息:




可以看到信息和功能还是相当丰富的。而且除了基本的 UI 设置之外,左侧工具还可以选择切换到:

  • 数据 / 枚举类型定义
  • App 状态 (App state)
  • Firesotre (好像是某种 NoSQL 的云服务?)
  • API editor (看上去是配置 API 调用的)
  • 配置主题配色的 Theme editor
  • 图片图标等资源的管理 Assets
  • 项目和应用的基础配置

可谓是功能相当丰富。





下载 & 安装项目

不过这次主打一个基础体验,我也就不做什么修改了,直接点击右上角的 “下载代码”,下载一份 Web 版的看看样子。
有一说一,它这个下载成功的提示真的很不起眼哈哈


可以看到,项目的大概文件结构是这个样子的:

安卓、iOS 和 JS 都有(虽然不知道为什么没用 WasmJs),也是相当全面了。
让我来随便找几个源代码文件看看内容:

嗯… 整体来说还是可以的,不过也有一些小缺陷:

  1. 代码可以说几乎没什么注释。
  2. 由于我一开始的提示词用了 USE CHINESE,结果导致它生成的代码中存在一些使用中文命名的类型。

上面这几个小缺陷我觉得如果用英文原版的提示词,或者再精修一下、将这些问题都在提示词中说明白,
那应该也都是可以避免的,所以问题不大。

运行项目

考虑到我没配置移动端的开发工具和相关的东西,咱们就跑一下 web 端看看效果吧。




嗯… 让我们先忽略它中文乱码的问题,这是 Compose for Web 渲染 canvas 的老问题了,找个中文字体加载下就好(或者有什么配置)。
单从 UI 布局上来看,是基本符合之前的设计布局的。

只不过不知道是不是应该在下载的时候选什么配置,这个 Web 端出来的布局仍是竖屏手机的样式哈哈哈,
之前在 UI 设计阶段是有宽屏 Web 布局的样式的,可能我漏掉了什么选项吧。不过我也懒得回去找了,就不再重新捣鼓了。
我将它生产出来的这个项目发布到了 GitHub 的仓库中:GitHub - ForteScarlet/ComposeFlow-TaskManagementApp: A demo project for ComposeFlow
你如果感兴趣的话,也可以去看看。

尾声

对此工具的体验就到此为止啦~ 有一说一在 UI 构建的工作区里功能比我想象要丰富不少。
不过毕竟工具也还是在早期阶段,还是会有不少细枝末节的小问题存在的,尝尝鲜还可以,不过想要非常优质的生产级体验还是有些距离。总而言之,未来可期!

至于我是怎么知道这个的呢,是因为前阵子看到 JetBrains 的布道师关注了这个仓库的所述组织,
于是乎就进去看了下,而后便有了这篇文章。

不管怎样,感谢你读到这里,祝你有愉快的一天,我们下次再见~


📌 转载信息
转载时间:
2026/1/24 06:42:41

哈喽,我是老刘

2025年已成过往。随着iOS、Android、桌面端、Web与各类小程序的持续发展,原生开发的高墙已难以维系,成本与效率的矛盾达到顶峰。

跨平台不再只是备选项,而是个人和团队的必选项。但面对Flutter的全平台一致体验、React Native的新架构性能突破、uni-app x的原生编译能力、KMP的Compose全栈统一,究竟谁才是2026年的最优解?

如何在这个AI重塑代码的时代,把有限的资源发挥出最大的效率?

老刘每个月为大家画出最新的跨平台技术选型地图,帮你快速做决策。

本月,各大框架在“原生体验”与“AI提效”上都有重磅更新。


1. 2025年跨平台技术简单总结

  • 性能仍是核心

2025年,各个框架都在寻找性能的突破点。

Flutter全面普及Impeller引擎,解决了最后一公里的卡顿问题。

uni-app x和KMP则选择了另外一条路,通过编译为原生代码(Native Compilation),直接从物理层面消除了性能鸿沟。

RN则全面切换到新架构来实现性能的突破。

性能上向原生看齐是2025年跨平台技术的一个重要趋势。

  • 平台拼图补全

框架们不再满足于能跑,而是追求各个平台的完美适配。

Flutter在桌面端和Web端(Wasm)持续发力,真正实现六端同源。

KMP推出了Kotlin-to-Swift导出功能,让iOS开发者也能优雅地接入,填补了跨平台在iOS原生生态上的最后一块拼图。

  • AI与框架深度融合

AI不再只是外部辅助,而是开始进入框架内部。

Flutter推出的Dart MCP Server让AI能直接理解项目结构和组件树。

MAUI也在不断完善其AI功能,如Copilot Agent,试图通过AI赋能来改善开发者体验。

应该说我们离描述即应用的时代不远了。

2. 最新技术动态

2.1 React Native 新架构全面启用

React Native 0.83 发布日志: https://reactnative.dev/blog

React Native 0.83 版本随 Expo SDK 55 正式到来。新架构(New Architecture)已成为默认标准,遗留架构代码正在被加速移除。新版本集成了 React 19.2,并在构建时间和应用体积上取得了显著优化。开发者现在可以享受到更接近原生的性能体验,以及更强大的 DevTools 支持。

2.2 Kotlin Multiplatform 生态成熟加速

Kotlin 2.3.20-Beta1 新特性: https://kotlinlang.org/docs/whatsnew-eap.html

Kotlin 2.3.20-Beta1 于本月发布,标志着 KMP 生态的进一步成熟。

Compose Multiplatform for iOS 已经稳定,越来越多的团队开始从原生转向 KMP。

K2 编译器的全面普及以及 JetBrains 在 AI 辅助开发(如 Koog 和 Mellum)上的投入,使得 KMP 的开发效率达到了新高度。

2.3 .NET MAUI 企业级发展

.NET MAUI Roadmap: https://github.com/dotnet/maui/wiki/Roadmap

.NET 11的规划和早期迭代正在进行中。当前重点依然是提升产品质量和性能稳定性。微软正在深度集成 GitHub Copilot 和 Copilot Agent,试图通过 AI 赋能来改善 MAUI 的开发者体验。尽管社区仍有关于稳定性的讨论,但其在企业级市场的地位依然稳固。

2.4 Flutter 平台更新

Flutter 最新动态: https://docs.flutter.dev/release/whats-new

虽然社区对 Flutter 4.0 充满期待,但截止 2026 年 1 月,Flutter 3.38 仍是官方维护的最新稳定版本。目前的更新重点在于 Impeller 渲染引擎 的进一步优化与稳定性提升,该引擎现已在 iOS 和 Android 上默认启用,彻底解决了 shader 编译造成的卡顿问题。此外,Flutter 团队修复了 Android 端 Activity 销毁时的内存泄漏问题,并对 Android 15 的 16KB Page Size 提供了完整支持,继续巩固其在跨平台渲染一致性上的优势。

2.5 uni-app x 进展

uni-app x 更新日志: https://uniapp.dcloud.net.cn/release.html

近期 uni-app x 迎来了一系列重要更新(v4.87)。核心亮点包括:

  • 多线程能力增强
    新增 uni.createWorker API,正式支持 Worker 线程,显著提升复杂计算场景下的性能表现。
  • 鸿蒙生态深度适配
    将逻辑层 JSVM 迁移至独立子线程,彻底解决主线程阻塞问题;新增微信登录、分享及屏幕亮度调节等原生能力。
  • 新设备与系统兼容
    修复 Android 16KB 页大小模式下的录音问题,并提前适配 iPhone 17 系列机型。

2.6 Valdi 进展

Valdi GitHub 仓库: https://github.com/Snapchat/Valdi

本月Valdi框架没有新的进展,最新发布版本仍然是beta-0.0.1

接下来老刘按照跨平台技术框架的三种路线,分别介绍一下目前主流的跨平台技术。


3. 自渲染类框架

简单来说,就是框架自己携带渲染引擎,自己画界面,不用系统提供的组件。

这样做有什么好处?

  • 界面完全一致
    UI渲染不依赖系统组件,多端展示效果完全统一。
  • 性能媲美原生
    跳过系统UI层直接操作GPU绘制,架构与原生一致。
  • 无兼容性Bug
    不调用系统原生组件,规避了因系统差异导致的兼容性问题。

3.1 Flutter

2024年Stack Overflow调查显示,Flutter是最受欢迎的跨平台框架。

全球有超过500万开发者在使用。

连阿里巴巴、腾讯、字节跳动都在使用Flutter。

为什么这么多大厂选择Flutter?

  • 性能强劲
    切换Impeller引擎后,Flutter性能已与原生应用一致。
  • 开发高效
    热重载实现秒级预览,Dart语言在功能性与复杂度间达成完美平衡。
  • 生态成熟
    pub.dev拥有超4万插件,涵盖地图、支付等各类功能,开箱即用。
  • 测试友好
    拥有客户端领域最佳的单元测试支持,是TDD及敏捷团队的最优选择。
  • 拥抱AI

    • AI Toolkit

    集成Gemini API,快速实现聊天、识别等功能。

    • 本地部署

    支持TensorFlow Lite/ONNX,保障隐私安全。

    • Dart MCP Server

    让AI助手直接理解项目,辅助编码与调试。


4. 中间层类框架

简单来说,就是在你的代码和系统原生组件之间,加了一个"翻译官"。

比如你用JavaScript写界面逻辑,框架帮你翻译成原生的Button、TextView。

核心特点:

  • 成熟的开发体验
    复用React/Vue/C#等生态成熟的开发思路,上手快,学习成本低。
  • 原生组件渲染
    最终映射为系统原生组件,UI符合平台规范,质感原生。
  • 桥接性能损耗
    通过中间层与原生通信存在"翻译"开销,交互密集场景性能稍弱,常规界面无感知。

4.1 React Native

React Native是第二受欢迎的跨平台框架,是Facebook开源的项目。

为什么这么多人选择React Native?

核心优势:

  • 零门槛上手
    React开发者可直接复用JSX、组件化及状态管理经验,一周即可转型。
  • 生态庞大
    npm拥有超15万相关包,共享Web生态,导航、支付等库应有尽有。
  • 动态热更新
    支持不发布新版本App直接在线更新,无需发版即可修复Bug或上线新功能,迭代极快。
  • 架构升级
    Meta持续投入,新架构引入Fabric和TurboModules,性能提升30%,旧架构已退役。

4.2 .NET MAUI

2024年5月,微软正式停止了Xamarin的支持,.NET MAUI(Multi-platform App UI)成为微软官方的跨平台解决方案。

核心优势:

  • 企业级保障
    微软提供长期技术支持(LTS),确保企业应用所需的稳定性。
  • 数据处理强
    C#擅长处理复杂业务逻辑,特别适合金融、ERP等数据密集型应用。
  • 生态深度集成
    与Azure、SQL Server等微软全家桶无缝对接,集成体验最佳。

5. 转译类框架

简单来说,就是把你写的高级语言代码,"翻译"成目标平台的原生代码。

比如你用Kotlin写业务逻辑,框架帮你"翻译"成iOS的Swift代码。

或者你用类TypeScript的语法写界面,框架帮你"翻译"成Android的Kotlin和iOS的Swift。

核心特点:

  • 性能接近原生

因为最终运行的就是原生代码,没有任何中间层损耗。

就像你直接用Swift写iOS应用,用Kotlin写Android应用一样。

  • 能享受原生生态

转译后的代码可以直接调用平台的所有API。

  • 转译效果可能不完美

毕竟是机器"翻译"的代码,有时候可能不如手写的原生代码优雅。

特别是复杂的业务逻辑,转译后的代码可能需要人工优化。

但这个问题随着AI技术的发展,正在快速改善。

5.1 Kotlin Multiplatform (KMP)

KMP的核心用法:业务逻辑用KMP共享,UI用Compose Multiplatform统一开发

这是KMP的最新发展方向,结合了Compose Multiplatform的强大能力。

一套Compose代码可以运行在Android、iOS、Desktop、Web等所有平台。

KMP的特点

  • 真正的一套代码多平台

不仅业务逻辑共享,UI也可以共享,开发效率大幅提升。

  • 保持原生性能

    Compose Multiplatform在各平台都编译为原生代码,性能接近原生应用。

  • 技术栈统一

全部使用Kotlin生态,学习成本更低,团队协作更高效。

  • 渐进式迁移

你不需要重写整个应用,可以先从一个模块开始。

比如先把网络层用KMP重写,然后逐步迁移UI到Compose Multiplatform。

  • 生态仍需完善

生态仍在加速建设,注意版本兼容与插件成熟度,第三方库相对较少,但发展很快。

5.2 uni-app / uni-app x

传统uni-app
基于Vue.js + JavaScript,更适用于小程序开发

uni-app x
全新架构,使用UTS语言,性能达到原生级别

uni-app x的技术特点

  • 平台支持最全

一套代码可以发布到:iOS、Android、Web、各种小程序、快应用、鸿蒙...

总共支持14+个平台,这是其他框架做不到的。

  • 小程序优先的设计理念

如果你的产品需要同时支持App和小程序,uni-app几乎是唯一的选择。

其他框架都是App优先。

  • 国产化支持

对鸿蒙、信创等国产化平台支持最好。

这对国内企业来说非常重要。

  • uni-app的局限

    生态相对封闭
    主要依赖DCloud的生态
    国际化程度低
    海外开发者使用较少
    技术栈绑定
    主要适合Vue技术栈

5.3 Valdi

Valdi的核心思路属于转译方案的范畴,但是并发代码级转译。

它采用了介于转译和中间层之间的混合架构,将UI组件树编译为原生组件并交由C++引擎管理生命周期,同时保留业务逻辑在TS层(Worker)运行,从而实现无JS Bridge的高性能渲染。

这样的好处是在一定程度上避免了转译类方案代码翻译不到位造成的一些问题。

但是仍然会有中间层方案在高UI交互场景下的性能问题,这部分就需要把处理逻辑放到C++/Swift/Kotlin编写的Polyglot模块解决。

站在纯粹客户端跨平台开发的角度,转译类方案老刘目前更推荐KMP。

Valdi可以作为一个有潜力的备选,等生态更加成熟后再重新考虑。


6. 技术选型指南

看了这么多技术栈,是不是更晕了?老刘把复杂的选型逻辑浓缩成一份实战决策指南,帮你快速拍板。

6.1 核心推荐:Flutter (通用首选)

对于 90% 的新启动 App 项目,Flutter 是当前版本的最优解

  • 性能强悍
    自带 Impeller 渲染引擎,不依赖系统组件,体验无限接近原生。无论是复杂的动画还是高性能列表,都能轻松驾驭。
  • 效率极高
    Hot Reload (热重载) 让改代码像刷新网页一样快。一套代码覆盖 Android、iOS、Web 甚至桌面端,研发成本降低 40% 以上。
  • AI 友好
    作为 Google 亲儿子,Cursor、Claude 等 AI 工具对 Dart/Flutter 的支持极为成熟,能自动生成高质量 UI 代码。

⚠️ 避坑提示
如果你的应用极度依赖原生比如有大量历史遗留的原生代码,或对包体积有苛刻要求 (<10MB),需谨慎评估。

6.2 潜力观察:Kotlin Multiplatform (KMP)

极度依赖原生的最佳选择。

  • 核心定位
    逻辑共享,UI 原生
    它不强求 UI 统一,而是让 Android 和 iOS 共享数据层、网络层和业务逻辑代码。
  • 适用场景

    • 已经在原生层面积累了大量的UI组件和功能模块,可以逐步把业务逻辑切换到KMP。
    • 应用强依赖系统底层能力 (蓝牙、NFC、深度硬件交互),同时又希望保持跨平台的优势。
  • 现状判断
    技术理念先进,但第三方生态仍在爬坡期。2026 谨慎全量 All-in。

6.3 谨慎评估需求:App + 小程序 ≠ 一套代码

一个产品有App和小程序不代表他们的业务逻辑是完全一致的,小程序在产品定位上不应该是App的简化版。

  • 最佳实践:App和小程序承担不同的产品职责

    • App (Flutter/原生)
      负责沉浸式体验、复杂交互、高粘性留存 (如阅读、创作、社交)。
    • 小程序 (原生/Uni-app)
      负责营销裂变、即用即走、低成本获客 (如分享落地页、简单工具)。
  • 决策依据
    只有当功能重叠度 > 80% 且交互极其简单 (如纯展示类新闻、简单电商) 时,才推荐使用 Uni-app/Taro 等方案同时生成 App 和小程序。

6.4 决策速查表

你的项目场景推荐技术栈理由
从 0 到 1 新项目Flutter效率与体验的最佳平衡点
原生项目转型跨平台Flutter可以增量迁移,混合开发风险低
重度依赖原生底层KMP风险低,渐进式重构
App与小程序功能重叠Uni-app小程序支持好
系统级工具纯原生 (Swift/Kotlin)无中间层损耗,完全掌控硬件
团队 Web 背景React Native学习曲线平滑,社区资源丰富

7. 总结与建议

写了这么多,老刘最后给你一个终极建议。

2026年跨平台开发,记住这三个关键词:务实、聚焦、长期主义。

7.1 务实

软件开发没有银弹。

Flutter性能好但包体积大,React Native动态性好但有桥接损耗,KMP接近原生但生态不成熟。

选择技术的核心是:在当前约束条件下,哪个方案的收益最大。

7.2 聚焦

没有项目需要超过2种跨平台框架同时使用。

同样也不推荐团队同时在多个不同的跨平台框架上投入时间和精力。

建议:选定一个主力技术栈,最多再备一个备选方案。

7.3 长期主义

真正决定项目生死的,是你选定技术栈之后做的那些事。

  • 架构设计够不够清晰?
  • 开发流程够不够规范?
  • 代码规范够不够严格?
  • 技术债务管理够不够及时?

选定技术栈不是终点,而是起点。

做好这些基础建设,才是项目能持续健康演进的根本。

否则,再好的技术栈也救不了你。

最后,希望这篇跨平台开发地图能帮你避开那些坑,找到最适合你的路。

如果看到这里的同学对客户端开发或者Flutter开发感兴趣,欢迎联系老刘,我们互相学习。

点击免费领老刘整理的《Flutter开发手册》,覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

覆盖90%开发场景的《Flutter开发手册》

我真是个大宝贝,这都能让我发现

佬友们藏的好深啊,还掖着啥好东西吗?
分享一下呗~

下载地址



感谢佬友 @rapbull 分享补充,有二十多个其他的软件源,自定义应用监控更新,牛掰!


项目地址

下载地址

谢谢佬友支持~:


📌 转载信息
原作者:
you_z
转载时间:
2026/1/3 11:57:42