鸿蒙百篇系列第 76 篇 · 专家
第 18 篇讲过 ArkUI-X 的基本概念，第 49 篇讲过 H5 容器化。这篇站在架构选型的角度，讲清楚一个现实问题：团队同时要出 Android、iOS、鸿蒙三个端的 App，怎么组织代码。
这不是"哪个框架更好"的问题。不同团队、不同业务、不同历史包袱，答案不同。这篇的目标是给你决策框架，不是帮你做决定。
一、鸿蒙跨平台的四条路线
截至 2026 年，在鸿蒙上能跑通的跨平台方案有以下几条：
各方案在鸿蒙端的适配状态有差异，下面逐一分析。
二、ArkUI-X：以鸿蒙为主的方案
ArkUI-X 是华为推出的跨平台框架。核心思路：用 ArkTS 写代码，在鸿蒙上直接跑原生 ArkUI，在 Android/iOS 上跑 ArkUI 引擎的适配层。
工作原理
ArkTS 代码
│
┌──────────┼──────────┐
│ │ │
HarmonyOS Android iOS
原生 ArkUI ArkUI引擎 ArkUI引擎
(直接渲染) (适配层) (适配层)
在鸿蒙端，ArkUI-X 就是原生应用，没有中间层开销。在 Android/iOS 端，ArkUI 引擎通过适配层对接系统服务。
适用场景
团队以鸿蒙为第一目标平台
需要深度集成鸿蒙特有能力（分布式、原子化服务）
团队已有 ArkTS 开发经验
Android/iOS 是附带需求，不追求极致原生体验
代码结构
ArkUI-X 项目的代码结构：
myapp/
├── entry/ # 鸿蒙入口
│ └── src/main/ets/
├── android/ # Android 工程
│ └── app/src/main/
├── ios/ # iOS 工程
│ └── Myapp/
├── shared/ # 共享代码
│ └── src/main/ets/
│ ├── pages/
│ └── components/
└── .arkuix/ # ArkUI-X 配置
在 shared 目录写一次代码，三个端共享。
平台差异处理
// 通过条件编译处理平台差异
import { DeviceInfo } from '@arkuix/core';
@Entry
@Component
struct HomePage {
@State platform: string = '';
aboutToAppear() {
this.platform = DeviceInfo.getPlatform();
}
build() {
Column() {
Text('当前平台: ' + this.platform)
if (this.platform === 'harmonyos') {
// 鸿蒙特有：分布式入口
Button('流转到其他设备')
.onClick(() => this.startDistributedFlow())
}
// 公共 UI
ProductListComponent()
}
}
startDistributedFlow() {
// 鸿蒙分布式能力，其他平台不执行
}
}
ArkUI-X 的限制
Android/iOS 上 ArkUI 引擎有额外内存开销
部分鸿蒙特有 API（如分布式软总线）在 Android/iOS 上不可用
社区生态还在发展期，第三方库不如 Flutter 丰富
Android/iOS 上的体验不完全等同于原生
三、Flutter：以一致性为优先的方案
Flutter 通过 OpenHarmony SIG 的适配，可以在鸿蒙上运行。适配版本已发布 3.22.0-ohos，对接鸿蒙 C-API 进行渲染。
工作原理
Flutter 自带渲染引擎（Skia 或 Impeller），不依赖平台原生控件。在鸿蒙端通过嵌入层对接系统服务：
Dart 代码 → Flutter 引擎 → 嵌入层(鸿蒙 C-API) → 屏幕
适用场景
团队已有 Flutter 经验和代码积累
三端 UI 一致性要求高
不依赖鸿蒙特有分布式能力
已有大量 Flutter 插件可用
鸿蒙适配要点
创建支持鸿蒙的 Flutter 项目：
flutter create --platforms=android,ios,ohos my_app
在 pubspec.yaml 中添加鸿蒙适配依赖：
dependencies:
flutter:
sdk: flutter
# 鸿蒙原生能力对接
harmonyos_adapter: ^1.0.0
调用鸿蒙系统 API 通过 Platform Channel：
// Dart 侧
import 'package:flutter/services.dart';
class HarmonyService {
static const platform = MethodChannel('com.example.app/harmony');
static Future<String> getDeviceInfo() async {
try {
return await platform.invokeMethod('getDeviceInfo');
} catch (e) {
return 'Unknown';
}
}
}
ArkTS 侧实现 Channel：
// harmonyos 侧
class HarmonyPlugin {
onMethodCall(call: MethodCall): Promise<Result> {
switch (call.method) {
case 'getDeviceInfo':
return Promise.resolve({
result: deviceInfo.deviceType
});
default:
return Promise.reject({ code: 'NOT_IMPLEMENTED' });
}
}
}
Flutter 方案的限制
鸿蒙端适配由社区维护，不是 Google 官方支持
某些鸿蒙特有控件（如 CapsuleButton）需要额外适配
Flutter 和 ArkUI 混编不推荐——两套渲染引擎，内存模型不同，数据交互困难
内存占用比原生高约 15%
四、React Native：适合 JS/TS 团队的方案
React Native 在鸿蒙上的适配由 RNOH（React Native OpenHarmony）社区维护，基于新架构 Fabric。
工作原理
RNOH 将 React 组件直接映射为 ArkUI 组件，不走传统的异步 JS Bridge：
React 组件 → Fabric (C++ 层) → ArkUI 组件 → 渲染
适用场景
团队是 React/TypeScript 技术栈
已有大量 React Native 代码
需要 Web 和移动端共享业务逻辑
对 UI 一致性要求适中
限制
鸿蒙适配版本支持到 RN 0.77，落后于最新版
复杂列表性能不如原生和 Flutter
社区维护，更新频率取决于社区投入
五、选型决策矩阵
选型建议
如果是从零开始的新项目，且鸿蒙是核心目标平台：
鸿蒙是第一目标？
├── 是 → ArkUI-X（深度集成鸿蒙能力）
│ 需要三端高度一致的 UI？
│ └── 是 → 评估 Flutter（但放弃部分鸿蒙特有能力）
└── 否（鸿蒙是次要平台）
├── 已有 Flutter 代码 → Flutter + 鸿蒙适配
├── 已有 RN 代码 → RNOH
└── 团队是 Vue 技术栈 → uni-app x
六、混合方案：核心原生 + 部分跨平台
不是非此即彼。实际项目中常见的混合策略：
┌─────────────────────────────────────┐
│ 原生 ArkTS（鸿蒙） │ ← 核心页面、支付、分布式
├─────────────────────────────────────┤
│ Web 容器（H5 页面） │ ← 活动页、内容页（第 49 篇）
├─────────────────────────────────────┤
│ Flutter/RN 模块 │ ← 已有代码复用的模块
└─────────────────────────────────────┘
这种方案的优势是渐进式迁移。已有 Flutter 代码的团队不需要重写，直接嵌入鸿蒙应用。新增的核心功能用原生 ArkTS 开发，获得最佳体验。
Flutter 模块嵌入鸿蒙
通过 XComponent（第 66 篇）将 Flutter 渲染区域嵌入 ArkUI 页面：
import { XComponent } from '@ohos.arkui';
@Entry
@Component
struct FlutterPage {
build() {
Column() {
// 原生导航栏
TitleBar({ title: '活动中心' })
// Flutter 渲染区域
XComponent({
id: 'flutter_view',
type: XComponentType.TEXTURE,
libraryname: 'flutter_engine'
})
.onLoad(() => {
// 初始化 Flutter 引擎
this.initFlutter();
})
.width('100%')
.height('100%')
}
}
}
七、代码复用策略
无论选哪个方案，跨平台都要处理"共享什么、不共享什么"的问题。
共享层次模型
┌──────────────┐ ← 不共享：UI 层（各平台差异大）
│ UI Pages │
├──────────────┤ ← 部分共享：业务逻辑（可抽象）
│ ViewModels │
├──────────────┤ ← 大部分共享：数据模型
│ Models │
├──────────────┤ ← 完全共享：网络层、工具类
│ Network │
│ Utils │
└──────────────┘
接口抽象实践
在共享层定义接口，各端实现：
// shared/interfaces/IStorage.ets
export interface IStorage {
get<T>(key: string): Promise<T | null>;
set<T>(key: string, value: T): Promise<void>;
remove(key: string): Promise<void>;
}
鸿蒙实现：
// harmonyos/impl/HarmonyStorage.ets
import { preferences } from '@kit.ArkData';
import { IStorage } from '@shared/interfaces';
export class HarmonyStorage implements IStorage {
async get<T>(key: string): Promise<T | null> {
const prefs = await preferences.getPreferences(getContext(), 'my_app');
return prefs.get(key, null) as T | null;
}
async set<T>(key: string, value: T): Promise<void> {
const prefs = await preferences.getPreferences(getContext(), 'my_app');
await prefs.put(key, value);
await prefs.flush();
}
async remove(key: string): Promise<void> {
const prefs = await preferences.getPreferences(getContext(), 'my_app');
await prefs.delete(key);
await prefs.flush();
}
}
Android 实现（如果用 ArkUI-X 或跨平台方案）：
// android/impl/AndroidStorage.ets
export class AndroidStorage implements IStorage {
// 通过 SharedPreferences 或对应方案实现
}
八、小结
跨平台选型没有银弹。ArkUI-X 适合"以鸿蒙为主"的团队，Flutter 适合"三端一致优先"的团队，混合方案适合"已有代码要复用"的团队。选型的核心不是比框架参数，而是搞清楚自己的业务约束：你的第一目标平台是什么？你的团队技术栈是什么？你的历史代码有多少？这三个问题答完，答案基本就出来了。
下一篇讲设计模式综述——在前 50 篇散落各处的模式实践基础上，做一次系统梳理。