企业官网建设流程全解析

今年有不少团队在立项调研时跑来问我同一个问题：“我们要做 OpenHarmony 版本，代码到底该怎么复用？”问的人多了，我意识到这已经不是一个技术选型问题，而是整个应用生态迁移期的共性焦虑。OpenHarmony 的 ArkTS/ArkUI 原生栈足够新，但新系统最大的短板是存量代码积累不足，谁也不想为一个小众入口重写整套业务。

现阶段绕不开的就是 RN、Flutter、Cordova、KMP 这四个方向。它们分别代表了跨平台开发的四种典型思路：JS 加原生控件、自绘引擎、WebView 壳、共享逻辑层。我会把这四套方案的原理、接入路径、性能表现和真正的适用场景全部梳理一遍。如果你正在做 OpenHarmony 跨平台框架选型，这篇文章能帮你把“听说”变成“判断”。

1. 想清楚再做：OpenHarmony 跨平台开发的真实处境

1.1 为什么“重写一套”不现实

很多团队第一次接触 OpenHarmony 时，第一反应是“直接上原生”。这个想法本身没有错，ArkTS 的声明式语法和 ArkUI 的组件体系借鉴了不少成熟思路，写起来并不算别扭。但问题的关键在业务层：一套已经跑了两三年的业务系统，可能有几十个模块、几百个接口、一堆自定义逻辑，如果在 OpenHarmony 上全部重写，成本不仅仅是代码量翻倍，还包括测试回归、数据兼容、人员培训、后续双倍维护。对一个商业团队来说，这几乎等同于把产品再做一遍。

所以绝大多数理性选择是：把现有跨平台框架的产物搬进 OpenHarmony，让框架底层去适配新系统，上层业务代码基本不动。但这里有个容易误判的点——同一套跨平台框架，在不同平台的适配深度完全不一样。网上能搜到不少“某某框架已支持 OpenHarmony”的新闻稿，真实情况往往是“能跑 hello world”和“能跑生产级应用”之间还隔着十万八千里。

1.2 跨平台框架要过的三道关

不管哪个框架，往 OpenHarmony 上迁移都要依次过三道坎：

第一道是运行时。RN 需要 JS 引擎，Flutter 需要 Dart VM，KMP 需要 Kotlin/Native 的编译产物能对接系统调用链。OpenHarmony 的方舟运行时对 JS/TS 有原生支持，对 Dart 和 Kotlin 就得靠框架自己带或者额外编译，这是最底层的适配成本。

第二道是渲染。RN 依赖把逻辑映射到原生控件，Flutter 是自己画每一帧，Cordova 直接交给 WebView。OpenHarmony 有自己的一套声明式 UI 组件，RN 要把控件一一映射到 ArkUI 组件，Flutter 要在 OpenHarmony 的图形栈上跑自己的渲染引擎，Cordova 则需要系统 Web 组件足够稳定和完整。三条路难度完全不同。

第三道是能力桥。跨平台框架要调用摄像头、定位、蓝牙这些原生能力，都需要一条桥接通道。OpenHarmony 对外提供的是 NAPI，RN 的 JSI、Flutter 的 Platform Channel、Cordova 的 Plugin Bridge，都得在 NAPI 层重新实现一套。哪条桥搭得稳，直接影响这个框架能不能上生产。

把这三道关放在心里再去看四个框架，你就很容易理解为什么有的框架适配快，有的适配慢，为什么有的框架很多东西要等社区补，因为每一层都有坑。

2. React Native：JS 生态是最快的入场券，也是最大的隐忧

2.1 RN 的架构与 OpenHarmony 的结合点

React Native 的核心思路是：业务层用 JS/TS 写，渲染层映射到宿主平台的原生控件。在 Android 上，RN 的一个 View 最后会变成一个 Android 原生 View；在 iOS 上会变成 UIView。对 OpenHarmony 来说，这套逻辑是可行的，因为 ArkUI 本身也有对应的原生组件树，只要在适配层把 RN 的组件逐一映射过去就行。

关键结合点有三处：

第一，JS 引擎。RN 默认用 Hermes 或 JSC，OpenHarmony 的方舟运行时本身也支持运行 JS/TS 标准代码，理论上 RN 的 JS 业务代码可以直接跑在方舟上，不需要额外塞一个解释器。这意味着对纯 JS 层代码，兼容成本是最低的。

第二，组件映射。RN 的 View、Text、ScrollView、FlatList 这些基础组件，需要有人实现一套 OpenHarmony 对应的版本。社区适配方案通常是在 ArkUI 侧写一个组件的原生实现，然后通过 JSI 暴露给 JS 层。工作量不小，但因为 RN 组件类型是有限的，基础组件加常用第三方组件只要覆盖到位，业务代码就能大面积跑起来。

第三，原生模块。RN 生态里有大量原生模块是 Android/iOS 双端实现，OpenHarmony 上一开始几乎全军覆没。这个问题的解法只能靠社区逐个移植，或者自己写一个 NAPI 模块再通过 JSI 桥接进去，属于最耗时的一部分。

2.2 把 RN 工程接到 OpenHarmony 的实操步骤

这里我按自己在模拟项目 X 中实际操作过的流程来说，适配到某个具体版本时细节略有差异，但整体路径是通用的：

1. 创建标准的 React Native 工程，先把业务代码跑通在 Android 或浏览器调试环境，尽量减少业务层的平台耦合。

2. 安装 OpenHarmony 侧的适配依赖包。这里一定要看依赖包的发布版本和 RN 版本是否配套，版本错位是最常见的初期报错来源。

3. 在项目根目录增加 OpenHarmony 的原生工程目录（通常是一个独立文件夹，比如harmony），然后用对应的 IDE 打开，让它作为一个原生宿主工程存在。

4. 配置打包入口。在原生工程里引入 RN 的应用注册逻辑，让 OpenHarmony 启动时先初始化 RN 环境，再加载 JS Bundle。这一步需要写少量原生配置代码，通常在项目的entry/src/main下加一个自定义的Application类或页面。

5. 配置 Metro 打包器。RN 的调试和发布都依赖 Metro 把 JS 代码打成 Bundle，你需要使 Metro 能识别 OpenHarmony 平台，并在打包命令里指定--platform harmony类似的参数。

6. 用 hvigor 构建 OpenHarmony 产物，先跑一个最小的 Text 组件页面。这一步能过，说明 JS 引擎、组件映射、打包链路都通了。

7. 逐渐替换原生模块依赖。每跑一个业务模块就检查一次依赖，凡是调用了 RN 社区原生模块的地方，要么找 OpenHarmony 替代实现，要么封装一个空实现或者自写 NAPI 桥。

这套流程走下来，头部业务跑通大概需要一到两周，全量业务跑通且性能达标，就要看团队投入了。

2.3 我实际跑过之后的几个结论

RN 在 OpenHarmony 上的表现，最大的优势是 JS/TS 生态丰富，团队上手几乎没有门槛，因为现有一大堆前端工程师就能直接参与。但问题同样明显：

性能会打折扣。RN 的业务逻辑和 UI 更新之间多了一层 JSI 桥接，再加上 OpenHarmony 的 ArkUI 组件树本身有自己的 diff 和更新机制，两层叠加后列表类页面的滚动流畅度明显不如原生。如果页面里大量使用 FlatList 或者复杂嵌套布局，需要做不少性能调优，比如减少重复渲染、优化图片加载。

原生依赖是最大瓶颈。第三方的原生模块几乎全部要重新适配，很多业务团队卡就卡在某个地图 SDK 或者某个登录 SDK 没法在 OpenHarmony 上复用。这不是 RN 框架本身能解决的，而是整个原生依赖生态的问题。

还有一个容易忽略的点：热更新热重载能力在 OpenHarmony 适配层初期并不完整，开发调试时经常遇到“改了代码要重新走完整构建”的情况。这会影响开发效率，但不影响上线。

综合来看，RN 适合那种已经有成熟 RN 应用、业务逻辑足够复杂、且愿意投入人力解决原生依赖的团队。

3. Flutter：自带渲染引擎的“硬核”选手

3.1 Flutter 落地的核心逻辑：不借原生控件，借原生能力

Flutter 和 RN 有一个本质区别：Flutter 根本不用宿主平台的原生控件做渲染。它在底层接入 Skia 图形库，所有 UI 都是 Dart 代码描述出来的，再由引擎直接绘制到屏幕上。这意味着 OpenHarmony 的 ArkUI 组件体系对 Flutter 来说并不重要，Flutter 需要的只是系统提供一个可以绘制上去的“画布”和一套接入事件、生命周期的原生壳。

所以 Flutter 落地的核心问题不是“控件怎么映射”，而是：

• 引擎怎么初始化。Flutter 引擎需要拿到一个原生窗口或者 Surface，才能在 OpenHarmony 上创建渲染环境。OpenHarmony 的图形栈需要提供对应的接入接口，这属于原生层适配，通常由适配项目提前完成。
• 垂直同步与事件。Flutter 的动画引擎依赖垂直同步信号来调度帧，OpenHarmony 的图形框架需要能向 Flutter 引擎发送帧回调。触摸事件也需要从原生层转发到 Flutter 引擎内部。
• 平台通道。Flutter 调用原生能力（相机、存储、网络状态等）走的是 Platform Channel，OpenHarmony 上需要实现一套基于 NAPI 的通道承载层。

如果这三件事解决了，Flutter 应用在 OpenHarmony 上的 UI 一致性会非常高。因为 UI 不是由平台控件决定的，而是同一个引擎绘制出来的，你在 Android、iOS 上看到的效果，到 OpenHarmony 上几乎一模一样。

3.2 在 OpenHarmony 上让 Flutter 跑起来的实操要点

在我参与的某跨平台系统适配中，Flutter 的接入流程大致是这样的：

1. 准备一个标准的 Flutter 工程，先用 Flutter 自带的多平台构建把工程跑通，确认 UI 和业务逻辑没有平台依赖。

2. 检查版本配套。OpenHarmony 侧的 Flutter 适配项目和官方 Flutter 版本之间存在严格对应关系，用错版本会出现一堆莫名其妙的编译错误。

3. 在原生工程里加入 Flutter 的 OpenHarmony 运行时依赖。这一步本质上是在 ArkUI 工程里嵌一个FlutterView类似的容器组件，用它承载 Flutter 引擎的全部输出。

4. 配置启动入口。在应用启动时初始化 Flutter 引擎，加载 Dart 入口，并把引擎绑定到生命周期事件上。这里需要把 OpenHarmony 应用的前后台切换、onShow、onHide 都正确转发给 Flutter 引擎，否则会出现页面切回来黑屏或动画卡死。

5. 处理平台通道。原工程里凡是调用了MethodChannel的地方，需要检查 OpenHarmony 侧是否已经实现了对应通道处理器。没有实现的能力要么自己写 NAPI 模块，要么在 Dart 层做兼容降级。

6. 用 hvigor 构建整体产物。Flutter 引擎和 Dart 代码编译出的产物会被打包成 OpenHarmony 应用的一部分，构建时间会比普通应用长不少。

整个过程最花时间的是第 5 步。Flutter 的 UI 一致性优势再大，也架不住业务里到处是平台能力调用，而 OpenHarmony 的插件生态尚在起步期，很多在 Android 上一行代码就能调用的能力，到 OpenHarmony 上需要自己用 NAPI 从零实现。

3.3 Flutter 的真实性能与体验

单从渲染性能来看，Flutter 在 OpenHarmony 上的表现比我预期好。自绘引擎对平台控件树的依赖小，只要引擎与图形栈的适配到位，帧率稳定性甚至可以超过 RN。特别适合对 UI 一致性和流畅度要求高的产品，比如带复杂动画的首页、图表类应用、金融数据看板。

但有一个不容忽视的问题：包体积和启动时间。Flutter 引擎要打包进应用，包体积比 Cordova 和 RN 大一圈，OpenHarmony 应用市场对包体大小比较敏感。另外 Flutter 引擎初始化需要加载 Dart 运行时和渲染库，冷启动速度比原生 ArkUI 应用慢。如果团队对启动耗时指标卡得很严，这个方向就要慎重。

还有一个体验问题：Flutter 的字体渲染、输入法、无障碍这些护栏在 OpenHarmony 适配初始阶段并不会做得像 Android 那样完善。中文输入框候选词、键盘弹出避让、屏幕阅读器兼容性，这些细节需要专门验证，否则可能在绑卡页面或者登录页面出现很尴尬的体验断层。

4. Cordova：被低估的轻量 WebView 方案

4.1 Cordova 的技术本质：桥，不是壳

很多人一听到 Cordova 就想到“老技术”“性能差”，但在 OpenHarmony 上反而不是这样。Cordova 的技术本质是：用一套标准 Web 技术栈（HTML/CSS/JS）写业务，用 WebView 渲染，用一个统一的插件桥去调用设备原生能力。对这个定义，OpenHarmony 上其实没有障碍，因为系统本身自带了一套完善的 Web 组件，性能并不弱。

Cordova 的适配核心是它的插件桥。默认情况下，Cordova 的 JS 侧通过某种协议通知原生侧执行对应插件方法，原生侧执行完再把结果回传。OpenHarmony 需要做的是在 Web 组件上自定义一套 JavaScript 接口，让 Cordova 的 JS 层能找到可以调用的原生对象，或者修改 cordova 的 platform 定义，让它把桥接目标指向 OpenHarmony 的 NAPI 方法。

由于 WebView 渲染不依赖 ArkUI 组件映射，也不需要自绘引擎，所以 Cordova 适配的技术门槛是四个方案里最低的。很多在 Android 上能跑的 Cordova 插件，只要原生逻辑不涉及特别独特的 SDK，迁移起来的成本反而比 RN 和 Flutter 小得多。

4.2 将一个 Cordova 应用迁移到 OpenHarmony 的路径

我帮某团队做过一个内容类应用的 Cordova 迁移，过程可以简化成这么几步：

1. 先确认业务代码是否使用了较新的 Web API。OpenHarmony 的 Web 组件基于系统内核实现，对标准的 HTML5 API 支持比较全面，但某些特定版本的内核对个别 API 的兼容性有差异，比如 WebGL 和 WebRTC 要单独验证。

2. 把 Cordova 工程的www目录原样保留，这是你的整个前端资源包。

3. 在 OpenHarmony 原生工程里创建一个 Web 页面，加载本地www/index.html。这一步其实就是一个Web组件加上loadUrl指向本地文件。

4. 处理插件桥。Cordova 在 Android 上会往 WebView 里注入cordova.js，在 OpenHarmony 上你需要找到对应适配实现，让cordova.js里的exec方法能把调用转成对 OpenHarmony 原生对象的调用。核心是提供一个可供 JS 调用的原生对象入口。

5. 逐个验证核心插件。比如存储、网络状态、文件读写、相机等。能通过 NAPI 快速实现的就自己写，不能实现的使用业务降级方案。

6. 最后处理打包体积和启动优化。Cordova 的包体很小，因为只有一个 WebView 壳和前端资源，启动速度取决于浏览器内核加载和前端解析速度。

4.3 什么项目才该选 Cordova

我的判断是，Cordova 在 OpenHarmony 生态里远没有大家想得那么不堪，尤其适合这几类场景：

• 已有成熟 Web 应用或小程序 H5 版本的团队，想快速上一个 OpenHarmony 包。Cordova 的价值是让你用一周时间拿到一个能上架的版本。
• 对性能要求不极致的内容型应用，比如资讯、文档、后台管理、表单填报。
• 团队前端能力显著强于原生能力的团队。OpenHarmony 原生开发对 ArkTS 有要求，但 Cordova 方案下，你的前端程序员可以直接上手。

它的缺点也很清晰：复杂交互和长列表滚动性能不如原生和 Flutter；调用设备能力时插件桥有额外开销；系统 Web 内核升级可能带来不可控的渲染差异。用一句话总结：Cordova 不性感，但对于“快速覆盖”这个目标，它是最实用的那个。

5. Kotlin Multiplatform：不碰 UI，只碰业务层

5.1 KMP 的共享策略：UI 继续各写各的

前面三个框架都在解决“UI 怎么跨平台”的问题，Kotlin Multiplatform 的思路完全不同：它不打算共享 UI，而是把业务逻辑层单独抽出来共享。你可以在一个 Kotlin 模块里编写网络请求、数据解析、本地存储、状态管理，然后用 expect/actual 机制处理平台差异，最终编译成不同平台的产物。

对 OpenHarmony 来说，KMP 的共享思路其实很有吸引力，因为 ArkUI 对于业务团队是一个新语言栈，如果你能把大部分和数据相关的复杂逻辑放到 Kotlin 层，ArkTS 侧只需要负责 UI 渲染和用户交互，工作量能砍掉一大截。

但这里有个现实问题：KMP 官方对 OpenHarmony 的支持并不是“开箱即用”。OpenHarmony 的 NAPI 层是用 C/C++ 接口对外暴露能力的，Kotlin 代码如果想被 ArkTS 调用，通常需要先把共享逻辑编译成一个动态库，再通过 NAPI 暴露成 ArkTS 能调用的对象和方法。

5.2 把 KMP 代码接进 OpenHarmony 的两种路线

在模拟项目 X 中，我们实验了两种接入路径，各有优劣：

路线一：Kotlin/Native 编译成动态库

把 KMP 共享模块用 Kotlin/Native 交叉编译成 OpenHarmony 目标架构的.so文件，然后通过 C 接口封装成一个 NAPI 模块，ArkTS 通过import这个 NAPI 模块调用共享逻辑。这条路的好处是 Kotlin 代码能真正被复用，业务逻辑写在 Kotlin 里完全独立于平台。缺点是 Kotlin/Native 的编译链对 OpenHarmony 目标架构的适配还不够顺手，可能需要自己处理 C 接口的导出和内存管理，工程复杂度直接拉高。

路线二：KMP 模块作为“逻辑标准”

共享工作不在二进制层面，而在代码层面。团队用 Kotlin 编写一套业务逻辑参考实现，然后在 ArkTS 侧按同样的结构重写一遍。这条路听上去像是在做重复劳动，但在实际工程里非常常见，因为 ArkTS 和 Kotlin 都是静态类型语言，语法结构相似度较高，有经验的工程师可以用半自动方式把 Kotlin 代码翻译成 ArkTS，同时保留统一的接口定义和数据结构。

从长远看，路线一是 KMP 在 OpenHarmony 上的终极形态，但目前更适合有底层能力的团队去趟坑。路线二则是一个折中策略，适合那些想借用 KMP 梳理业务边界、又不想陷入编译地狱的团队。

5.3 KMP 与其他框架怎么协作

KMP 最大的价值不是替代 RN 或 Flutter，而是补充它们。举个例子：你用 Flutter 写 UI，用 KMP 写业务模块，两者之间怎么配合？在 Android 和 iOS 上，通常是把 KMP 编译成静态库或 framework，再在原生层通过方法通道暴露给 Flutter。在 OpenHarmony 上，这个链路要多走一步：把 KMP 产物通过 NAPI 暴露给 ArkTS，再由 Flutter 的 Platform Channel 调 ArkTS 层，或者 RN 的 JSI 调 ArkTS 层。

说白了，KMP 的位置是“业务中台”，UI 框架是“前端门面”。如果你的团队已经在用 KMP 做双端业务复用，那么 OpenHarmony 只是“多一个平台要接入”的问题，而不是“要不要引入跨平台框架”的问题。这个架构思路在长期维护多个平台时非常有价值。

6. 四大方向横向对比与选型建议

6.1 四个框架的适配成本、性能与生态对比

我把四个方向放在同一张表里，按我接触过的实际工程经验来打分，方便你对照：

这个表格里最需要强调的是原生依赖覆盖度。四个框架在 OpenHarmony 上的核心问题都不是框架本身，而是框架后面那套插件生态。RN 有成千上万个原生模块，Flutter 有强大的 pub 插件库，Cordova 有成熟的 plugin 市场，但 OpenHarmony 侧它们几乎都要重新适配。这个预期必须提前建立，否则做到一半发现某个核心功能没法实现，返工成本极高。

6.2 按团队现状决定的选型矩阵

选型不是“哪个框架好”，而是“哪个框架适合你这支团队”。

如果你的团队是一个标准的 RN 团队，已经在 Android、iOS 上用 RN 维护两套产品，那 OpenHarmony 版本优先考虑 RN。虽然性能有损耗、原生模块有缺口，但团队不需要学习新语言，业务代码复用率也最高，这是成本最可控的路线。

如果你的团队是原生工程师为主，同时想给用户一个体验跨端一致的产品，Flutter 值得重仓。前提是产品经理必须对冷启动时间和包体积的指标有合理预期，团队也要有一定的原生编译和 NAPI 功底去填插件缺口。

如果你的团队其实是个 Web 团队，或者这个 OpenHarmony 版本只是“先上再说”的占坑产品，Cordova 就是最优解。先把产品铺上去，后续再根据用户反馈决定是否用 Flutter 或原生重写。

如果你的团队已经深度使用 KMP 做逻辑共享，那就把 OpenHarmony 当成 KMP 的第四个平台来规划。UI 层可以过渡期内用 Cordova 或 ArkUI 原生快速实现，但业务层一定要回到 KMP 这套共享模型里来。

6.3 混合路线：跨平台框架不必二选一

还有一个很容易被忽略的思路：混合架构。在很多大型应用里，不同模块对跨平台要求完全不同。比如首页和核心交易页面要求高体验高流畅，可以用 Flutter 或原生 ArkUI；运营活动页和帮助中心要求更新快，可以用 Cordova 或 H5；数据密集型模块则用 KMP 共享逻辑。这种混合架构在商业应用里非常常见，但代价是工程复杂度高，需要团队有足够强的架构把控能力。

如果你问我个人更看好哪个方向，我会说 Flutter 是这轮适配里综合胜率最高的，因为自绘引擎绕开了 OpenHarmony 组件映射的坑，能够赢得长期性能优势。但如果你是第一次接触 OpenHarmony，我的真实建议是先别急着押注，拿一个真实业务模块分别用 RN 和 Flutter 跑一个 POC，用数据说话，比任何架构分析都靠谱。

7. 常见问题与避坑实录

7.1 每个框架都有的“隐藏雷区”

RN 最容易踩的雷是把原生模块迁移想得太简单。很多原生模块为了适配某个平台 SDK，内部有大量平台相关代码，OpenHarmony 上没有对应 SDK，整个模块就废了。避免方式是在技术方案阶段就做一次原生依赖清单普查，把每个依赖标注为“可直接用”“需重写”“可降级”三类，让风险提前暴露。

Flutter 最容易踩的雷是版本错乱。OpenHarmony 的 Flutter 适配版本、Flutter SDK 版本、工程模板版本三者必须严格对应，稍有偏差就会出现引擎编译失败或者运行期白屏。建议直接锁定一组经过验证的版本组合，并写进团队文档，禁止随手升级。

Cordova 最容易踩的雷是 Web 内核兼容性。OpenHarmony 系统的 Web 组件在不同设备上可能是不同内核版本，同一个页面的布局和脚本行为可能不一致。上线前需要在至少三台不同设备上做真机测试，特别是 Canvas、视频播放和动态样式部分。

KMP 最容易踩的雷是过度设计。很多团队引入 KMP 后，恨不得把所有代码都塞进共享层，结果光是处理 expect/actual 的平台差异就耗时巨大。我的建议是最初阶段只共享最稳定的那部分逻辑，比如数据模型映射、网络层封装、纯计算服务，别一上来就共享 UI 状态层。

7.2 我最后想说的几句实操心得

第一，跨平台框架在 OpenHarmony 上的适配成熟度，大概比我写这篇文章时往前推一年已经好很多，但和 Android、iOS 相比依然有明显差距。在做规划时，一定要把“填坑时间”算进排期里，不要只按框架官方文档描述的时间来估。

第二，无论选哪个框架，团队里至少要保留一两个懂 OpenHarmony 原生开发的人。因为所有的跨平台框架最终都要落到 NAPI 层，这一层的调试和开发是逃不掉的。完全依赖社区适配方案，你会被上游更新节奏牵着鼻子走。

第三，如果条件允许，把跨平台框架的接入抽象成一个独立的模块层。不要在整个应用里到处都是跨平台调用原生能力的散点，而是集中封装成统一接口，这样框架升级的时候，你只需要改底层适配，不需要动用业务层代码。

第四，我个人的真实体会是，OpenHarmony 跨平台开发的瓶颈从来不是“框架能不能跑”，而是“跑起来之后业务能不能持续迭代”。UI 可以跨，逻辑可以跨，但团队认知、工具链、自动化测试、灰度发布这些配套能力都需要围绕新系统重新打磨。选哪个框架只是开场，真正决定成败的是后续工程化体系的建立。

这篇文章写到这里，没有给你一个绝对的答案，因为每个团队的存量技术栈、人员构成和产品诉求都不同。但我希望这四个方向的全景梳理，能让你在下一场技术评审会上，心里更有底。