企业官网建设流程全解析

你手头那套 Flutter、React Native 或 uni-app 的代码，离真正跑在鸿蒙手机里还差多少？这是过去一年我做技术选型评审时被问得最多的问题。尤其是 HarmonyOS NEXT 明确了不再兼容安卓 APK 之后，“跨平台框架适配鸿蒙（OpenHarmony）”这个话题，从“要不要跟”直接变成了“怎么跟、跟到什么程度”。这篇汇总我拖了很久才动笔，因为信息变化太快，今天能用的适配方案，下个月可能就被官方新版本替代。我干脆按信息汇总表的方式来整理，把主流跨平台框架的适配状态、底层原理、迁移流程和坑点全部摊开来讲。无论你是刚接手鸿蒙项目的开发，还是正在做多端架构选型的技术负责人，这份内容都值得花十分钟通读一遍。

1. 为什么跨平台框架适配鸿蒙这件事突然成了硬需求

1.1 从安卓 APK 到 HAP：生态切换意味着什么

HarmonyOS 早期版本还能通过 AOSP 兼容层直接安装安卓 APK，所以很多团队对“鸿蒙适配”并不着急，把 APK 拿来重签就能在 HarmonyOS 上跑个大概。但 HarmonyOS NEXT 以及 OpenHarmony 主分支的做法完全不同，应用形态改成了 HAP（HarmonyOS Ability Package），应用逻辑跑在自有的 Ability 框架上，安卓环境被整体移出。对用户来说，这不是一次系统升级，而是一次生态迁移；对开发者来说，原来“安卓 APK 一套带走”的跨平台策略，在鸿蒙这个新阵地里直接失效。

这也是跨平台框架适配鸿蒙（OpenHarmony）这件事突然变得重要的根本原因：鸿蒙已经不是一个小众实验场，它有自己的设备基数、主机厂合作方和行业落地场景。如果跨平台框架不跟进，存量 App 想要进入鸿蒙生态，就只能全部用 ArkUI/ArkTS 重写，这对绝大多数团队来说成本太高、周期太长。跨平台框架恰好提供了一条“业务代码大部分复用、只替换运行底座”的折中路线。

1.2 跨平台框架是承接存量的最短路径

你想想看，一个典型 App 的代码构成大概是：业务逻辑占大头，平台交互占小头。而平台交互又往往收敛在几个固定模块里：网络请求、本地存储、推送、登录、地图、支付。跨平台框架本身已经把 80% 的业务代码和平台解耦了，剩下的 20% 通过统一接口或平台通道对外暴露。

所以当鸿蒙需要一个新运行时，跨平台框架的适配本质上就是“再实现一套平台通道”，而不是把业务代码重写一遍。Flutter 可以把 Dart 层几乎不动地编译过去，RN 可以把 JS 层几乎不动地跑起来，uni-app/Taro 更是把“一套代码多端编译”作为卖点。这一点在鸿蒙生态刚起步、原生控件和三方 SDK 都不够丰富的时候，对开发团队来说有着巨大的诱惑力：用最低成本快速占住鸿蒙入口，等生态成熟了再决定要不要做原生精细化。

1.3 现在就要看这份汇总表的三种团队

我把最近咨询过这类问题的团队大致归成三类，你可以对号入座。第一类是有存量跨平台 App 的团队，比如电商、工具、内容类产品，他们有成熟的 Flutter 或 RN 代码，需要在鸿蒙设备上继续提供产品，这类团队需要的是“最小改动跑通鸿蒙”；第二类是正在做新项目技术选型的团队，产品会同时覆盖安卓、iOS、鸿蒙甚至 PC，他们需要判断“是用现有跨平台方案顺带支持鸿蒙，还是直接上 ArkUI 原生”；第三类是接外包或做行业解决方案的团队，客户明确要求鸿蒙版，但预算和排期都很紧张，他们需要的是一个可复制的迁移路径和选型依据。下面所有内容，都围绕这三类团队的实际决策点展开。

2. 主流框架适配现状总览：一张表看清家底

2.1 主流跨平台框架适配鸿蒙现状汇总表

我先把目前市面上讨论度较高的跨平台方案整理成一张汇总表，这里不区分 Flutter/RN/uni-app 这些名词的衍生分支，只看“当前在 OpenHarmony/HarmonyOS NEXT 上能否产出可运行应用”。

这张表只看大方向，具体版本支持度建议以各仓库的 Release 为准。我自己的判断是，2025 年的节点上，真正可以考虑用于生产环境的还是 Flutter、RN、uni-app、Taro 四条线，ArkUI 原生则是一条绕不开的参照线。

2.2 判断适配成熟度的四个维度

很多人看到“某框架已支持鸿蒙”就以为可以放心接入了，实际上“能跑”和“能上线”之间隔着很大的距离。我在评估某个跨平台框架在鸿蒙侧的成熟度时，主要看四个维度。

第一是 API 覆盖度。不是说 Demo 能出页面就够了，而是看它到底覆盖了 OpenHarmony 的多少系统能力，比如网络、存储、文件、通知、剪贴板、传感器、NFC、蓝牙。第二是三方插件生态。Flutter 和 RN 的威力在 pub.dev / npm 上的现成插件，但鸿蒙侧这些插件大多数还没有对应实现，你需要自己写或改。第三是性能表现。自绘引擎和原生渲染在常规页面上差别不大，但在长列表、大图、动画、低端机上差距会被拉大。第四是版本跟进速度。OpenHarmony 本身在快速迭代，框架能不能跟上 API 变更、能力新增，决定了你未来是被升级推着走，还是开开心心吃新能力。

2.3 哪些框架暂时不用等

如果你现在才开始鸿蒙之旅，Cordova 方案可以直接划掉，它的 WebView 体验在鸿蒙里不会有突破；.NET MAUI 目前还没有明确的官方路线图，不用浪费精力；Kotlin Multiplatform 更适合已经有 Kotlin 基础、且主要目标是共享逻辑的项目，如果你想让它跨到鸿蒙 UI 层，目前还相当吃力。真正值得投入时间跟踪的是 Flutter 和 uni-app，这两个我身边验证过的团队最多；RN 则适合那些完全依赖 React 技术栈、且愿意自研鸿蒙原生模块的团队。

3. Flutter、React Native、uni-app、Taro 逐个拆解

3.1 Flutter on OpenHarmony：自绘引擎要过三道关

Flutter 在鸿蒙侧的适配思路，和它在安卓、Windows、Linux 上的思路一脉相承：Dart 代码不换，Flutter Engine 换平台实现，渲染结果直接画到鸿蒙的 Surface 上。也就是说，它不是一个“把 Flutter 变成 ArkUI”的方案，而是保留了 Flutter 的自绘渲染路径，UI 由 Skia/Impeller 绘制，上层只对接鸿蒙的窗口、输入、生命周期。

看起来很美，但实际要过三道关。第一关是 Engine 移植质量，包括线程模型、Vsync 信号、触摸事件分发是否跟鸿蒙的窗口系统完美配合；第二关是插件通道，Dart 端的 MethodChannel / EventChannel 在鸿蒙侧需要有原生实现，这个工作量非常大；第三关是生态依赖，Dart pub 包纯 Dart 的能直接用，但凡是依赖 Android/iOS 原生能力的插件，在鸿蒙上基本都要换实现。我见过不少团队拿 Flutter Demo 跑通后，第二天想接入个地图或推送，就被卡了两周。

3.2 React Native on OpenHarmony：桥接的不是 WebView

React Native 在安卓上是通过 Bridge 把 JS 组件映射到原生 View，在鸿蒙上则是把 JS 组件映射到 ArkUI 组件，底层走的是 C++ 实现的 Fabric 渲染管线。它不是套壳 WebView，也不是把 RN 页面包在 WebView 里先跑起来糊弄人，这一点可以放心。

但 RN 的坑在于它的三方原生模块生态太依赖安卓。比如一张图片加载可能走 Glide，一个推送可能走 Firebase，一个埋点可能走 Android SDK。这些原生依赖在鸿蒙侧都没有现成替代。所以 RN 团队做鸿蒙适配时，最重的活儿不是把 JS 层跑通，而是把所有 JS 层依赖的原生模块，用 ArkTS 或 C++ 在鸿蒙侧重新实现一遍，然后再注册给 JSI/Bridge 使用。

3.3 uni-app 与 Taro：国内跨端框架的本土化优势

uni-app 和 Taro 在国内市场有天然优势，因为它们原本就是为了“一套代码跑小程序/H5/App”而生，业务代码抽象化程度高，平台差异被框架层吸收了一部分。uni-app 官方已经支持将工程编译到鸿蒙，生成 HAP 应用；uni-app x 则是更进一步使用自己的跨端语言方案，直接编译到原生能力。对熟悉 Vue 的团队来说，这条路径的学习成本最低。

Taro 从 3.6 版本开始提供 OpenHarmony 支持，京东团队持续在推进。它更适合那些原本就把 Taro 作为核心跨端方案的团队，尤其是电商、中后台、活动页这一类业务。Taro 对 React 和 Vue 语法都有支持，编译后会生成鸿蒙端所需的 ArkTS 等产出，运行时负责把 Taro 的组件模型映射到 ArkUI 上。这两个框架给我的共同感受是：上手快，但一旦遇到超出 Vue/React 常规能力边界的功能，比如复杂手势、自定义绘制、底层性能调优，就会比较难处理，最终还是要写鸿蒙原生代码来补洞。

3.4 ArkUI：如果从零开始，要不要直接学鸿蒙原生

如果项目完全从零开始、团队没有人质于已有跨平台框架，我通常建议认真评估直接使用 ArkUI。它和 Flutter 一样是声明式 UI 思想，组件树、状态管理、生命周期都是这个时代的正常思路，有 React/Vue 或 SwiftUI 经验的人不会太陌生。它的优势是底层通道最短，不需要任何跨语言桥接，系统能力、性能、权限、后台任务都走得最顺畅。

当然劣势也一样明显：ArkUI/ArkTS 目前主要在鸿蒙生态内通用，你学到的技能很难迁移到安卓和 iOS；一旦鸿蒙的项目停了，这部分人力储备在其他平台会显得比较浪费。我的建议是，纯鸿蒙项目可以直上 ArkUI，多端项目还是优先考虑跨平台框架，再通过框架的鸿蒙适配去覆盖这个新生态。

4. OpenHarmony 开发语言、工程结构与核心概念扫盲

4.1 鸿蒙系统本体是用什么语言写的

这个热搜词出现频率极高。严谨一点说，OpenHarmony 作为一个操作系统，底层基础库、内核相关组件、图形栈、通信协议栈等核心部分主要使用 C/C++；更上层的系统服务和应用框架则越来越多使用 ArkTS、C++ 甚至 Rust 参与开发。对应用开发者来说，我们接触到的绝大多数业务代码是用 ArkTS 写的，需要高性能或复用已有 C/C++ 库时，可以通过 NAPI 写 C++ 扩展。所以“OpenHarmony 用什么语言编写”这个问题，准确答案不是单一语言，而是“内核和底层以 C/C++ 为骨，应用层以 ArkTS 为主，C++/NAPI 做高性能补充”。

4.2 开发者要掌握的 ArkTS 与声明式 UI

ArkTS 是 TypeScript 的一个超集子集，它的设计目标是“用声明式的方式描述 UI，用状态驱动更新”。如果你写过 Flutter 的 Widget、SwiftUI 的 View 或者 Jetpack Compose 的 Composable，上手 ArkTS 会非常快。核心思路是：定义状态变量，UI 会根据状态自动刷新，而不是手动操作 DOM 或 View。

我用一个底部导航栏的例子说明，这在热搜词里出现频率很高。用 ArkUI 做底部导航，通常会用到 Tabs 组件，Tabs 下挂 TabContent，每个 TabContent 对应一个页面。操作逻辑不复杂，布局上可以配合 RelativeContainer 做相对定位，或者用 Flex 做弹性排列。和 Flutter 的底部导航相比，ArkUI 的 Tabs 自带联动切换和角标能力，少写不少胶水代码。但要注意 Tab 页面切换时的状态保存，默认情况下页面可能会被重建，需要设置合理的主页路由栈策略。

4.3 工程结构：HAP、HAR、HSP 与 Stage 模型

跨平台框架的适配最终都要落到鸿蒙工程结构上。一个鸿蒙应用的最小发布单位是 HAP，它内部包含代码、资源、配置和签名信息。当模块需要被多个 HAP 共享时，可以打包成 HAR（静态共享包）或 HSP（动态共享包）。开发上，现在主流是基于 Stage 模型的开发，页面不再是 Activity/Fragment，而是 UIAbility + Page。

UIAbility 承载应用交互入口，WindowStage 负责窗口，页面的入口通过 windowStage.loadContent 加载。这个流程里，如果你想在页面加载前做一些窗口属性设置，必须在 loadContent 之前做；而页面真正可交互之后，再获取窗口实例做沉浸式、全屏或焦点管理。网上很多人问 loadContent 报错或拿不到 window，十有八九是生命周期时序没弄对。

4.4 HDI、元服务和 XTS 认证这几个名词别搞混

HDI（Hardware Device Interface）是 OpenHarmony 里硬件设备接口的描述规范，它把驱动和系统框架解耦。如果你的应用需要外接设备、USB 外设或者特定传感器，就需要关注设备厂商是否提供了对应 HDI 服务；普通应用开发通常不会直接碰 HDI。元服务是鸿蒙生态里一种轻量、免安装的应用形态，适合高频小场景，比如扫码、打车、订餐，它不能完全替代传统 HAP，所以跨平台框架第一步还是先适配标准应用形态。XTS 认证则是 OpenHarmony 的兼容性测试套件，设备厂商想说自己兼容 OpenHarmony，就要过这套测试；应用侧也有对应的兼容性约束，所以在鸿蒙应用上架前，尽量用官方测试工具把基础能力过一遍，能省不少审核扯皮的麻烦。

5. 迁移实操：把现有跨平台工程跑上鸿蒙真机

5.1 迁移前先填一张自检清单

我不建议任何人直接拿着现有代码就往鸿蒙工程里塞，提前做一次自检可以节省大量返工时间。你把项目里所有依赖列一遍，按三个维度标记：纯跨平台代码（比如 Dart 层、JS 层、Vue 组件）可以直接复用；有平台特化调用的要看接口是否暴露到鸿蒙侧；只有安卓/iOS 原生实现的三方 SDK 则是最危险的。网络请求、日志、JSON 解析这类基础库通常没问题，但地图、支付、推送、广告、登录分享这类 SDK 就要确认鸿蒙厂商是否提供鸿蒙版。

第二步是确认团队里有没有能写 ArkTS 或 C++ 的人，因为跨平台框架的鸿蒙适配往往不是纯配置就能搞定，插件缺了实现就需要自己补齐。第三步是把用户的设备结构看清楚。如果你的存量用户都在安卓/iOS 上，且有鸿蒙设备增长预期，可以按 20% 的精力先跑通核心路径；如果客户是政企或 To B 硬件场景，鸿蒙甚至 OpenHarmony 可能是硬性交付标准，那就要直接切换到以鸿蒙为主线的迁移计划。

5.2 搭好环境：DevEco Studio、SDK、模拟器与 hdc 连接

鸿蒙应用开发的官方 IDE 是 DevEco Studio，它内部会引导你下载对应 API 版本的 SDK。创建工程时选择“Empty Ability”，基于 Stage 模型生成一个最简 HAP 工程。集成跨平台框架时，不要把跨平台代码直接乱放，参照对应框架的鸿蒙适配文档，把引擎运行时或编译产物作为一个模块集成进来。

模拟器方面，DevEco 内置了 HarmonyOS 模拟器，支持常见手机和平板形态，适合快速验证。但模拟器对蓝牙、NFC、传感器等真实硬件能力覆盖有限，涉及这些能力一定要连真机。鸿蒙的真机调试使用 hdc 工具，它和 adb 在指令设计上很接近，hdc list targets、hdc install 包名，配合 hilog 看系统日志。第一次连真机时，记得在开发者选项里打开调试开关，并在 DevEco 里完成签名配置，否则装不到真机上。

5.3 把跨平台工程改造成鸿蒙工程：代码级改造

以我相对熟悉的 Flutter 路径为例，流程大致是：先在 DevEco 中创建鸿蒙主工程，然后把 Flutter 模块以源码或预编译产物的方式集成进去，在 Ability 里创建 Flutter 容器并将它附着到 WindowStage。启动入口写成 Dart 侧的 main()，Dart 层代码几乎不用动，需要处理的是原生能力和插件注册。

代码改造时有一个最容易忽略的点：跨平台框架在安卓/iOS 上的生命周期回调，和鸿蒙上的 UIAbility/Page 生命周期不是一一对应的。比如应用从前台退到后台、从后台回前台，事件名称和触发时机都有差异。你必须重新处理 App 生命周期监听，否则会出现切后台再回来时页面状态错乱、视频播放掉续播、用户登录态被误删的问题。

5.4 构建、签名和安装：HAP 要过一遍的流程

鸿蒙应用在真机上安装运行，需要签名，不像开发期那样随意。开发调试可以用自动签名，但发布上架需要申请正式证书。构建出的 HAP 可以通过 DevEco 一键部署到模拟器或真机，也可以用命令行工具打包和安装。这个过程对跨平台工程来说还有一个特殊点：最终 HAP 里既包含原生 ArkTS 代码，又包含 Flutter/RN/uni-app 的运行时和业务包，包体通常会比纯原生应用大不少。

我在跑通一个 Flutter 鸿蒙 Demo 时，包体从安卓的 20MB 左右变成 40MB 左右，因为引擎二进制、Skia 渲染库、Dart 运行时都要打进去。对包体有严格要求的应用，可以考虑延迟加载非核心模块，或者用按需下载的 Feature 模块，别把所有东西都塞进一个 HAP。

6. 高频问题与坑点速查：全是搜出来的真实痛点

6.1 搜出来的高频问题：逐一给出结论

我沿着那批网络热词搜了一圈，发现大家关心的问题非常集中，我把最有代表性的几个整理成速查表。

6.2 适配期最容易踩的 5 个坑

第一个坑是三方 SDK。统计、推送、登录、热更新这类 SDK 在安卓上早就成熟，但鸿蒙侧往往要么没有版本，要么是功能裁剪版。接之前一定要确认厂商的鸿蒙适配进度，否则项目阶段会被一个 SDK 卡死。

第二个坑是图片与字体。很多跨平台项目会依赖网络图片加载库、图片选择器、字体包，这些库通常只实现了安卓/iOS 的原生逻辑。到了鸿蒙侧要么图片加载不出来，要么是字体渲染风格不一致，需要手动指定系统字体或改加载链路。

第三个坑是权限模型。鸿蒙的权限声明和安卓的 targetSdk 权限机制不同，后台定位、通知、传感器等敏感权限需要在应用配置里声明，并在代码里动态申请。很多团队把安卓权限配置习惯带过来，结果真机运行到相关功能直接没反应，日志也不报错。

第四个坑是窗口和屏幕适配。不是所有鸿蒙设备都是手机，还有折叠屏、平板、车机、电视。跨平台框架默认的布局可能在手机上没问题，但一旦跑在折叠屏或平板上，SafeArea、分屏、窗口尺寸变化都要重新调。

第五个坑是性能调优。跨平台应用上鸿蒙真机后，不要拿安卓/iOS 的调试经验直接套用。线上监控里可能会出现 CPU 偏高、首帧偏慢、内存涨得快的情况。优先检查是否把某个高频计算放在了主线程，或者某个页面组件没有被正确销毁。必要的时候使用 DevEco 自带的性能分析工具抓一下 Flame Chart，比瞎猜靠谱得多。

7. 选型建议：不同团队不同抄法

7.1 三类团队三种推荐路径

如果你是存量 Flutter 团队，我建议你把 Flutter on OpenHarmony 作为主线验证，因为代码复用度最高。先用一周时间把核心业务模块跑通，确认各插件都有替代实现后，再决定是否全量迁移。如果你是 React 技术栈为主、后端是 Node/React 为主的前端团队，可以重点看 RN 的鸿蒙端口，但一定要提前规划原生模块的鸿蒙实现，这是最大工作量所在。如果你是给中小客户做多端应用的，uni-app 或 Taro 更现实，因为团队里通常不缺 Vue/React 开发者，且这两个框架对鸿蒙的支持由国内团队持续跟进，遇到问题更容易找到中文资料和官方回应。

7.2 建议什么时候开始适配，什么时候再等等

如果目标产品对鸿蒙设备覆盖有明确业务指标，那现在就可以开始做 PoC，因为你越晚动手，存量代码积压越重。如果产品的主力用户还在安卓/iOS，且业务场景不强依赖鸿蒙自研特性，你可以先建立技术跟踪清单，按季度更新一次框架适配状态，但不投入重兵。一个比较特殊的节点是当你的竞品已经在鸿蒙应用商店上架，那就不再是“要不要做”的问题，而是“要不要尽快追平”的问题。

7.3 保持一份自己的适配跟踪清单

跨平台框架适配鸿蒙这件事不是一个静态结果，它会随着 OpenHarmony 版本、框架 Release、三方 SDK 支持度不断变化。我建议每个团队维护一张自己的清单，包含四列：当前使用的框架版本、OpenHarmony 目标版本、核心三方依赖的支持状态、每个依赖的替代方案和负责人。每两周更新一次，比临时抱佛脚查资料高效得多。

最后再分享一个团队里的习惯：每次大版本升级前，先用一个非核心模块做最小验证，跑通之后再做回归。跨平台框架版本和鸿蒙 SDK 版本一旦不匹配，编译期、运行期、性能表现都会出现各种诡异问题，直接拿到主项目上试错，很容易把团队节奏打乱。我个人在实际适配中的体会是，跨平台框架迁移鸿蒙的真正成本早就不是“能不能编译通过”，而是“生态依赖能不能被填平”。把第三方原生 SDK 的鸿蒙支持状态排出来，项目的真实排期也就浮出水面了。