鸿蒙跨平台框架怎么选？从真实需求比较 Flutter、React Native、KMP/CMP 与 Web 路线

本文面向第一次做鸿蒙化的开发者，从业务需求出发，比较框架的性能关注点、安装包构成、学习成本与依赖生态。版本和生态数据来自文中列出的 8 个 AtomGit 组织；原理示意不代表实测跑分。

先写下三个答案：项目现在用什么、必须支持什么设备、哪些功能不能缺。再看框架。

假设你接到一个需求：“现有 App 要增加鸿蒙版本，登录、扫码、消息通知都不能少，页面尽量和 Android、iOS 保持一致。”

这时最值得问的，不是“Flutter 和 RN 谁更快”，而是：已有代码能复用多少？登录 SDK 有没有鸿蒙版？扫码库支持的是 Android，还是也支持鸿蒙？遇到插件缺口，团队里有没有人能补上？

一个登录链路都接不通的框架，即使空白页面跑得再快，也不是当前项目的好选择。

接下来先认识各条技术路线，再用性能、包体、学习成本和依赖四个维度比较，最后用四个业务场景说明怎么做决定。文中的业务场景均为假设需求，用来演示选型方法，不是商业项目实测报告。

一、先从需求选出两条候选路线

不用一开始就把所有框架都学一遍。先根据自己手里的资产，缩小范围。

你的实际情况	优先验证	选它的理由	必须先查的风险
已有 Flutter App，现在补鸿蒙端	Flutter OH	先复用 Dart 业务和页面，通常比全部重写更合理	每个原生插件是否有匹配版本的鸿蒙实现
已有 React Native App	RNOH，即 React Native for OpenHarmony	沿用 React 组件、状态管理和部分业务逻辑	RN 版本线、新架构、原生模块能否配套
已有 Kotlin 业务，希望继续使用各端原生界面	KMP + 平台 UI	共享业务逻辑，界面保留平台实现	Android 专属代码能否拆开，鸿蒙互操作是否可用
Kotlin 团队还希望共享界面	KMP + CMP	在共享逻辑之外，进一步复用 Compose UI	UI 组件、平台视图和系统能力的适配情况
已有 Web 页面，主要是表单、内容、内部工具	Cordova OH 或 Capacitor OH	复用 HTML、CSS、JavaScript 和 Web 业务	复杂交互、键盘、原生插件及弱网体验

如果只做鸿蒙，没有跨端复用需求，先评估 ArkTS + ArkUI 原生开发。 原生在这里是对照基线，不是本文新增的第九个跨平台组织。为了一款单平台小工具引入额外运行时和适配层，不一定划算。

另外两条路线单独看：Electron 放进桌面或明确受支持的大屏设备候选，不拿它与手机框架直接排名；CJMP 适合有仓颉积累、愿意承担早期生态验证工作的团队。 新手赶着交付第一个业务版本时，不建议仅因语言新、版本新就选它。

图 1：先用已有代码、团队技能和目标设备分流，最终所有候选仍要通过关键依赖和真机验收。这是一张初筛图，不是保证成功的推荐榜。

二、“支持跨平台”不等于“已经支持鸿蒙”

可以把一个 App 拆成三层：

1. 业务逻辑：金额计算、订单状态、数据校验。这些代码通常最容易共享。
2. 界面：列表、按钮、动画、手势。不同框架用不同方式把它们画出来。
3. 系统能力：相机、蓝牙、通知、支付、文件访问。这一层最容易暴露平台差异。

“鸿蒙化”主要是让框架运行时、界面承载方式和系统接口能在目标鸿蒙环境里正确工作。Android 的 APK、Java/Kotlin 原生插件和 Android SDK，不能因为上层框架跨平台，就自动变成鸿蒙实现。

还要分清两个名字：OpenHarmony 是开源项目，HarmonyOS 是商业系统。一个仓库声明支持某个 OpenHarmony API，不等于它已经承诺所有 HarmonyOS 设备、系统能力和应用上架场景都兼容。选型时应写明设备型号、系统版本、API 等级和厂商 SDK，而不只写“支持鸿蒙”。

如果是第一次接触移动开发，可以先认清这几个词：

术语	大白话解释
UI / 渲染	UI 是用户看到和操作的界面；渲染是把文字、图片和组件变成屏幕画面的过程
SDK	开发工具包，提供代码库、工具或接口，让应用使用某个平台或服务的能力
API / API 等级	API 是代码调用某项能力的接口；系统 API 等级表示一套接口版本，有的功能只在较高等级可用
插件 / 依赖	依赖是项目用到的外部代码；插件通常用来扩展框架能力，例如调用鸿蒙相机，但仍要确认它支持目标平台

不同路线到底共享什么？

路线	新手可以这样理解	鸿蒙端仍然要处理什么
Flutter OH	多数 UI 由 Flutter 的渲染体系绘制，便于保持各端设计一致	系统能力插件、嵌入原生视图、输入法、无障碍和生命周期
RNOH	用 React 写界面，由鸿蒙适配层接入原生组件及相关能力；不是把网页塞进 App	组件支持、新架构配套、原生模块、JS 与原生侧协作
KMP	共享 Kotlin 业务逻辑，不要求所有界面统一	不能共享的平台 API，用各端实现或互操作补齐
CMP	在 KMP 基础上进一步共享 Compose 界面	鸿蒙 UI 后端、原生视图混排和系统能力接入
Cordova / Capacitor	Web 页面运行在原生容器里，通过插件调用系统能力	容器适配、插件、WebView 行为和权限处理

Ionic 和 Capacitor 也不是一回事。 Ionic 主要提供 Web UI 组件和开发体验；Capacitor 负责原生容器与插件接入。看见“Ionic 8”不能据此推断自己安装的 Capacitor 鸿蒙平台包也一定是同一个版本。

图 2：框架共享的层不同，但相机、定位等能力最终仍需要鸿蒙侧实现。图中是简化架构，没有表示具体引擎后端或性能高低。

三、截至 目前，能核验到哪些数据？

先看版本状态，而不只是版本号

选版本时建议记住四个词：上游、适配版、稳定版、预览版。

上游是原始框架的发布线；鸿蒙适配版可能有独立后缀和配套工具链。beta、rc、canary 都不能直接当作“正式稳定”。仓库有某个分支、更新日志写了某个版本，也不等于已经提供公开可安装的稳定制品。

下表中的 tag 是代码仓库为某个版本设置的标记；分支则可能持续更新。它们用于定位代码，具体是否适合项目发布，还要看发布说明和配套依赖。

路线	本次核验结果	新手选型时的含义
Flutter OH	稳定线可核验 tag 3.41.10-ohos-1.0.1；另有 3.44.9+ohos-0.0.1-canary1	新项目优先从与依赖匹配的稳定线验证，不把较大的 canary 版本号当生产默认
RNOH	公开 tag/npm 可核验 0.84.3，对应发布说明仍标 beta；0.82-stable 当前指向 0.82.30	不直接写“0.84.3 是最新稳定版”；与已有 RN 项目及插件的版本线配套
KMP / CMP	鸿蒙文档列出 KMP 2.2.21-1.0.0、CMP 1.9.2-1.0.0 Release	必须使用匹配的鸿蒙工具链；文档声明 API 17+，具体功能可能有更高要求
Cordova OH	tag 14.0.1-ohos-14.0.2-release	记录完整适配 tag，不只记住“Cordova 14”
Capacitor OH	tag 8.0.0-ohos-8.0.2-release；该 tag 的 README 基于 @capacitor/android@8.0.0	按这个适配版本查找配套说明，不混用其他版本的安装步骤
CJMP	OpenSDK v0.2.2，Engine release-v0.2.3	SDK、Engine 分开记录，不把引擎 tag 当成整套 SDK 已同步发布
Electron OH	可核验 v40.1.0-openharmony 分支；公开 tag 仍见 v37.2.1	“40.1.0 分支存在”和“40.1.0 稳定安装包已发布”是两件事
ApplicationTPC	是多个 ArkTS / C / C++ 三方库与适配工具的集合	不应给整个组织套一个统一框架版本，按具体库核查

RNOH 还有一个值得新手注意的变化：9 月 7 日的 0.86.1 发布说明已经出现在源码中，但标注为 beta、内部转测版本。本次没有查到对应的公开 npm 包，因此这里把它列为进展，不作为默认安装建议。

另外，本次 npm 查询的 latest 仍是 0.72.143。这说明 latest 是发布者设置的标签，不是把所有版本按数字排序后的最大值。对 RNOH 应先读目标版本的 SDK 配置和发布说明，再锁定具体版本。

例如 RNOH 0.84.3 包声明的 peerDependencies.react-native 是 0.84.1，不是让你把所有组件都改成 0.84.3。peerDependencies 可以理解为“这个包要求搭配的其他包版本”。

CJMP 也有需要提前检查的设备门槛：OpenSDK v0.2.2 发布说明列出的鸿蒙运行条件为 HarmonyOS 6.0.2+ / API 22+ / arm64。要求覆盖更低系统的项目，应先确认是否存在可用配套，而不是先投入页面开发。

这些记录是本次核验的快照，不是未来发布的承诺。开工前重新检查对应仓库的 README、发布说明和包版本，是比记住一串数字更有用的习惯。

再看生态规模，但别把仓库数量当插件数量

本次选取上述 8 个组织，通过 AtomGit 公开 API 完整分页读取，并按仓库 ID 去重，得到 1051 个公开仓库、8278 个 Star。统计范围仅限这 8 个框架或三方库组织，不代表鸿蒙全生态的总量。Star 是用户为仓库添加的关注标记，不是下载次数或质量认证。

图 3：实时 API 快照。Flutter 373 仓、RN 286 仓、ApplicationTPC 166 仓、Cordova 82 仓、KMP/CMP 74 仓、Ionic 49 仓、CJMP 20 仓、Electron 1 仓。横条表示公开仓库数量，不表示性能或生产成熟度。

其中可能有框架源码、工具、文档、示例、测试仓和适配库。373 个仓库不等于 373 个可直接安装的 Flutter 插件，1 个仓库也不等于 Electron 只有一个依赖。 单体仓库和多仓库组织方式本来就不同。

Flutter 官方三方库清单本次核验有 262 个已适配条目、110 个开发中条目。但该表的配套版本列仍主要列出 3.35、3.27、3.22、3.7，不能据此宣称“262 个库全部兼容 3.41 或 3.44”。

对你的项目来说，真正有用的数字是：必须使用的依赖里，有多少已经在目标鸿蒙版本上验证通过。

四、性能怎么比？先看你的页面在忙什么

性能不是一个数字。启动快、列表顺、动画稳、内存低，是不同目标。

一个审批工具可能最在意首屏和输入；短视频页面更在意播放器、手势和持续滚动；蓝牙工具更在意系统接口、后台限制与连接稳定性。拿空白页启动成绩去选视频框架，参考价值很有限。

下面比较的是架构带来的关注点，不是同机跑分，也不代表固定的性能顺序。

路线	更值得放进什么场景验证	性能排查重点
Flutter OH	多端一致界面、自定义视觉、复杂 UI	不必要的重建、长列表、图片解码、渲染耗时、平台视图混排
RNOH	已有 RN 业务、原生组件交互	JS 长任务、组件更新范围、列表实现、JS/原生交互及模块实现
KMP + 原生 UI	共享数据和业务计算、保留平台界面	共享代码的算法与线程、互操作开销；UI 性能取决于平台实现
KMP + CMP	Kotlin 团队共享逻辑与界面	重组、布局、绘制、原生视图嵌入和对应鸿蒙后端
Cordova / Capacitor	表单、资讯、轻交互 Web 业务	DOM 数量、JS 主线程、重排、资源加载、键盘与原生插件交互
CJMP	有明确仓颉技术目标的试点	按实际 SDK 验证渲染、内存、系统接口及工具可观测性
Electron OH	支持设备上的桌面 Web 应用	多进程资源占用、窗口数量、主线程和原生模块；不参与手机横评

两个常见误区要先去掉：

“RN 用原生组件，所以一定比 Flutter 快”不成立。 应用是否卡顿，还取决于 JS 工作量、组件更新、布局和具体原生模块。Flutter 自绘也不代表系统能力免费获得。

“WebView 一定卡”同样不成立。 表单和内容页可能满足需求；复杂拖拽、重动画、超长列表则需要更认真地验证。你的验收线应来自产品场景，不是来自框架标签。

用一个列表理解：卡顿不一定是框架的问题

假设商品列表里有很多条数据，但手机屏幕一次只能显示其中几条。有两种处理方式：进入页面时就创建全部列表项，或者先创建可见项及少量缓存，滚动时再继续准备。

第二种方式通常能减少初始阶段不必要的构建与布局工作，但实际效果还取决于缓存设置、图片解码、列表项复杂度以及框架实现。它不是“打开某个选项，所有场景都会更快”的保证。

图 4：同一个列表需求，可以产生不同的初始工作量。这是原理示意，没有采集耗时或帧率，不能据此比较不同框架的性能。

遇到卡顿时，先检查是不是创建了大量不可见内容、一次加载了过多图片，或者一个小改动触发了整页更新。先排查不合理的实现，再判断框架是不是达不到业务目标。

五、安装包大小怎么比？先统一“大小”的口径

“Flutter 包多大？”这个问题还不够具体。

你问的可能是提交审核的 APP 包、某个签名 HAP 的文件大小、商店实际下发体积，也可能是安装后的磁盘占用。这几项不是同一个指标。HAP 可以理解为鸿蒙应用的模块安装包；一个应用也可能涉及多个模块。

更可靠的比较方式，是看同一业务、同一设备架构、同一发布模式下，各方案增加了哪些东西。

路线	主要包体来源	新手应该怎样判断
Flutter OH	业务产物、资源、Flutter 引擎及运行支持、原生插件	小应用要关注固定运行支持开销；大应用也要查图片、字体和插件，而不只盯引擎
RNOH	JS 业务产物、资源、JS 引擎和框架、鸿蒙原生模块	不是“用了原生组件就没有框架体积”；以实际打包配置检查
KMP + 原生 UI	Kotlin/Native 产物、依赖、平台界面与资源	只共享逻辑与同时引入 CMP，不应当成同一包体方案
KMP + CMP	KMP 部分，加上 UI、渲染相关依赖及资源	分别测共享逻辑的增量、共享界面的额外增量
Cordova / Capacitor	Web 资源、原生容器、插件与业务依赖	使用系统 WebView 时通常不需要把完整浏览器引擎随应用再打包，但运行开销仍存在
CJMP	业务产物、引擎、系统库与资源	以当前 SDK 的实际产物分析，不能从“自研”推导出固定的小包优势
Electron OH	Chromium、Node.js、应用资源与原生模块	通常有较重的随包运行环境；应按桌面场景的预算单独判断

图 5：拆开看“包里装了什么”。图块不按体积比例绘制，不能从色块长度读出 MB 或得出大小排名。

构建模式也会影响结果。以提供三种模式的工具链为例：debug 主要用于开发调试，profile 用于性能诊断，release 才是比较正式发布产物时应优先采用的模式；具体支持哪些模式，以所选框架为准。调试支持、裁剪配置和附带资源不同，都会改变包体，不能把任意一个演示工程的大小当成框架的固定大小。

正式选型时建议打三份同口径产物：最小应用、加入关键 SDK 的应用、完整核心页面的应用。两次增量能帮你分清，到底是框架、第三方 SDK，还是自己的图片资源在增加体积。

本文没有取得覆盖全部候选框架、同机同业务的 release 包体数据，所以不填一张貌似精确的“某框架 5 MB、某框架 20 MB”对比表。那样容易把不同平台、不同模式的数字混在一起。

六、技术难度怎么比？从“你已经会什么”出发

技术难度不是框架的固定属性。同一套 KMP 工程，对 Kotlin 团队和只写过网页的新手，意味着完全不同的学习成本。

团队已有经验	起步更自然的候选	鸿蒙化时要补的知识
Dart / Flutter	Flutter OH	鸿蒙工程与签名、插件配置；缺口处可能涉及 ArkTS 或 C++
React / TypeScript / RN	RNOH	RN 鸿蒙版本配套、原生模块、新架构；React Web 经验不等于 RN 经验
Kotlin / Android	KMP，按需求增加 CMP	共享代码边界、Gradle 与鸿蒙工具链、Kotlin/Native 和 ArkTS 互操作
HTML / CSS / JavaScript	Cordova OH / Capacitor OH	WebView、插件、权限、键盘和原生容器生命周期
仓颉 / 系统开发	CJMP	当前 SDK 的工程流程、系统能力覆盖和调试方式

能写页面，不等于能独立交付鸿蒙应用。 不管选哪条路线，至少要有人能处理签名、权限、应用生命周期、日志、崩溃和上架检查。

对刚开始学编程的人，也不建议同时学习 Dart、Kotlin、React 和仓颉。先沿着自己的现有语言选一条路线，做出最小可用功能，再决定是否值得深入。

七、生态怎么比？把依赖一项项验过去

生态里最危险的一句话是：“这个库网上能搜到，应该就能用。”

至少要区分：有仓库、有鸿蒙代码、能编译、所需 API 完整、你的项目真机可用。前一项并不能保证后一项。

图 6：依赖逐级验收。仓库存在只是入口，不是验收结果；许可和维护状态也要检查。

建议先把依赖分成三类：

1. 纯逻辑依赖：数据格式、校验、算法。复用机会较高，但仍要看目标平台、运行时和间接依赖。
2. UI 与渲染依赖：图表、富文本、动画。要看鸿蒙渲染支持，不能只看截图像不像。
3. 原生与商业 SDK：支付、地图、IM、推送、蓝牙、音视频。优先核验厂商鸿蒙 SDK、框架封装与业务账号条件。

检查时不要只抄库名，可以用下面这张表：

业务必需能力	必须记录的证据	什么情况下暂不放行
登录 / 支付	SDK 来源、明确支持的系统、回调与取消流程、账号配置	只有 Android/iOS 实现，或鸿蒙支付结果回调无法闭合
相机 / 扫码	插件版本、权限拒绝处理、扫码与页面返回的真机记录	只能预览，无法满足实际识别场景或异常恢复
IM / 推送	消息收发、通知点击、前后台切换、厂商服务配置	把“本地通知能显示”当成“远程推送全链路已通过”
蓝牙 / 音视频	目标设备、系统版本、断连重连、生命周期和压力记录	示例能跑，但关键业务 API 未实现或限制无法接受
文件 / 分享	文件模型、读写权限、目标应用唤起与返回	路径行为照搬 Android，或只测了成功分支

这里的“桥接”可以简单理解为：上层框架把请求交给鸿蒙代码，再把结果传回来。ApplicationTPC 提供的 ArkTS / C / C++ 库，可以成为这条调用链的底层材料，但通常不等于 Flutter、RN、KMP 直接就能使用的现成插件。

例如，一个 C++ 图像库已经完成鸿蒙编译，只能说明底层库这一步有基础。你还可能要做上层封装、线程处理、对象释放和错误映射。

关键依赖验收应当是硬门槛。 支付不能用，不能靠“UI 五星、社区五星”把综合分补回来。能接受自研或替换的缺口，要写明负责人、成本和回退方案。

八、把比较放进四个具体项目

下面用四个假设需求，把前面的规则串起来。它们是决策示例，不是已实测案例。

场景 A：已有 RN 零售 App，要增加鸿蒙端

团队已经用 React 和 TypeScript 写了商品页、购物车和订单状态。此时优先验证 RNOH，原因不是它在某个榜单里更快，而是已有业务资产可以保留。

第一轮不必搬完所有页面。先做“登录 → 商品列表 → 下单 → 支付回调”。同时确认项目当前 RN 版本与目标 RNOH、React、三方库的兼容要求。React 写的网页也不能直接等同于 RN 页面复用。

若支付或某个商业 SDK 在鸿蒙端没有可接受的实现，先解决这个缺口，再决定是否迁移；不要把核心阻塞留到项目最后。

场景 B：新建三端应用，界面一致性很重要

Android、iOS、鸿蒙要一起交付，界面含较多品牌化设计，团队愿意使用 Dart，可以优先把 Flutter OH 放进候选。若团队已有 Kotlin/Compose 积累，则把 CMP 作为另一条验证路线，而不是为了“新项目”强行换语言。

比较时做同一个页面：相同图片、相同行数、相同动效，再分别接入相机或地图。只比较纯 UI 演示，会漏掉平台视图混排和插件的成本。

场景 C：Android 团队积累了很多 Kotlin 业务逻辑

规则校验、数据模型、离线处理希望共享，但鸿蒙端需要自己的界面和系统体验，可以先尝试 KMP + ArkUI。KMP 不要求你同时采用 CMP。

不过，原来调用 Android Context、Android 数据库实现、系统定位接口的代码，不会因为挪进共享目录就自动跨平台。先把纯业务与平台操作分开，才有可能顺利复用。

只有确认共享 UI 的收益大于平台差异成本，再增加 CMP。这样也更容易判断新增包体和调试复杂度来自哪里。

场景 D：已有内部 Web 表单，想接入扫码和文件上传

如果业务以表单、审批和内容为主，优先评估 Cordova OH 或 Capacitor OH。已有 Ionic 页面可以保留为 UI 候选，但必须核验对应鸿蒙容器与插件的版本。

验证重点不是首页能打开，而是：输入法会不会遮住按钮、扫码后能否回到表单、文件能否上传、断网后草稿是否还在。若主业务变成复杂画布、重动画或实时音视频，再重新评估方案，不能只靠“网页已经写好了”决定长期架构。

Electron 和 CJMP 怎么放？ 已有 Electron 桌面产品迁移时，验证受支持的鸿蒙设备、窗口能力、Node 原生模块和发布方式；CJMP 则先做边界明确的试点，用实际 SDK 验证，不把早期版本号自动解读为“不可靠”，也不把新语言自动解读为“更高性能”。

九、用一个小验证，做出能解释的决定

PoC 是 Proof of Concept，即“概念验证”。在这里不需要做完整 App，只需要证明：最难的功能能不能做，关键体验能不能达标。

如果团队已经熟悉候选框架、SDK 和真机环境，可以先安排 3～5 个工作日做第一轮验证；这是排期示例，不是新手完成学习、账号申请和全量迁移的工期承诺。

1. 列硬门槛：目标设备、系统 API、必须接入的 SDK、最低功能集、发布要求。
2. 保留两条候选：优先保留现有技术栈；另一条用于验证明显短板，而不是把全部框架都做一遍。
3. 先做最难链路：登录、扫码、数据库、通知或支付，选择项目风险最高的一条跑真机。
4. 同口径测试：完成相同业务后比较启动、卡顿、内存和包体，同时记录开发投入。
5. 写决定与回退：保留通过证据、未解决问题、版本锁定信息，以及插件不可用时的替代方案。

图 7：公平比较需要同设备、同业务、同资源和同采样口径。不要拿一个框架的 debug 演示与另一个框架的 release 产物横比。

新手也能执行的指标表

指标	测什么	最容易犯的错
启动	统一起止点，区分冷启动与热启动，记录每次原始数据	把页面内部计时当操作系统启动；只保留最好的一次
流畅度	同刷新率、同滚动路线、同动画时长，用一致的系统侧指标	不同框架回调的帧数直接相除；只看平均 FPS
内存	同一页面、同一稳定时点，尽量统一为进程 PSS 等口径	一边读 Dart 堆，一边读整个应用；漏掉多进程
包体	同架构、同 release 条件，区分 HAP、下载体积、安装占用	把 profile、debug、release 或不同模块数量混着比
开发成本	记录接入、修复、调试和回归工时及剩余阻塞	只数页面写了几天，不数插件适配和版本升级

启动可以先做 10 次排查流程和异常，再用例如 50 次或更多样本观察中位数与 P95；样本量仍要按波动程度增加。P95 表示约 95% 样本不超过该值，用来观察偏慢的体验，不是“只测一次就能得到”的指标。

看帧耗时时，60 Hz 每帧预算约 16.67 ms，120 Hz 约 8.33 ms。它们来自 1000 ÷ 刷新率，但是否真正掉帧还要看帧是否按时呈现；不同框架内部的计时回调不一定可以直接互换。

跨框架体验对比优先使用 release 和统一的系统侧观测。若某个分析器只能在 profile 模式下工作，就把结果单列为诊断，不与其他框架的 release 数字直接排名。

图 8：这是可以执行的验证方案，不是本篇已经完成的八框架测试记录。先验证高风险链路，最后再决定是否投入完整迁移。

最后，把结论写成这样，比“我们觉得这个框架不错”更有用：

本项目优先选择 ______，因为现有 ______ 可以复用，且 ______ 核心链路已经在 ______ 设备 / 系统上通过验证。锁定框架与插件版本为 ______。目前仍有 ______ 风险，由 ______ 负责；若无法解决，则采用 ______ 回退方案。

十、给新手的最后一条建议

鸿蒙选型不是选一个大家都说好的框架，而是选一条你能把核心功能做完、测完、维护下去的路线。

已有项目先考虑复用，关键依赖先做验证，性能和包体坚持同口径测试。只做鸿蒙时允许原生方案胜出；只想共享逻辑时允许不共享 UI；一个系统能力需要原生实现时，也不必因此推翻整个跨平台方案。

现在可以做的第一件事很小：写下项目最不能缺的三个依赖，在对应组织里查它们的鸿蒙实现和版本要求。 这通常比先看十张框架排名图更接近答案。

数据与参考

组织入口

以下是本文涉及的框架与三方库组织。CPF-rn 的 API 规范名称返回为 CPF-RN，指向同一组织。

组织	入口
Flutter	https://atomgit.com/CPF-Flutter
React Native	https://atomgit.com/CPF-rn
ApplicationTPC	https://atomgit.com/CPF-ApplicationTPC
KMP / CMP	https://atomgit.com/CPF-KMP-CMP
Cordova	https://atomgit.com/CPF-Cordova
Ionic / Capacitor	https://atomgit.com/CPF-Ionic
CJMP	https://atomgit.com/CJMP
Electron	https://atomgit.com/CPF-Electron