鸿蒙ArkUI-X跨平台技术：【概述】

 ArkUI-X概览

项目介绍

ArkUI是一套构建分布式应用的声明式UI开发框架。它具备简洁自然的UI信息语法、丰富的UI组件、多维的状态管理，以及实时界面预览等相关能力，帮助您提升应用开发效率，并能在多种设备上实现生动而流畅的用户体验。

ArkUI-X进一步将ArkUI扩展到了多个OS平台：目前支持OpenHarmony、HarmonyOS、Android、 iOS，后续会逐步增加更多平台支持。开发者基于一套主代码，就可以构建支持多平台的精美、高性能应用。

熟悉鸿蒙开发指导文档：gitee.com/li-shizhen-skin/harmony-os/blob/master/README.md点击或者复制转到。

关键特征

ArKUI跨平台框架关键特征如下：

1. 简洁自然的声明式语法。
2. 高效的渲染管线以及平台一致性的渲染机制。
3. 高效的方舟编译器以及运行时。
4. 统一的跨平台API能力集以及扩展机制。
5. 动态化特性

技术架构

ArkUI跨平台框架整体架构如下图所示。

简介

本文档描述ArkUI开发框架跨平台运行能力相关的总体技术方案。

范围

ArkUI是面向全设备的UI开发框架，已通过OpenHarmony代码仓开源，其关键组成包括：

• 开发模型;
• 应用界面&交互;
• 扩展机制-使能三方组件&平台API扩展机制。

ArkUI-X旨在将ArkUI开发框架扩展至其他OS平台（Android/iOS/Windows等），使开发者能够基于ArkUI开发框架，复用绝大部分的应用代码（UI以及主要应用逻辑），即可部署到不同OS平台上。

假设和约束

本文提到的跨平台是指UI部分的跨平台，其UI代码可以重用，其它应用对平台依赖的能力，需要应用层面进行适配，或通过JS API封装机制（NAPI），进行实现暴露到JS层。

涉及平台能力的JS API（比如网络、存储等）请参考OpenHarmony中的定义，需要通过在不同平台的封装实现达到复用的目的。

本文主要是通用方案设计说明，并以Android平台做为示例说明，其他平台的基本设计思路类似，但相关设计需进一步细化补充。

总体视图

从设计之初，跨平台就作为ArkUI最基本的设计目标之一，当前已支持基础的跨平台架构。相关的设计思路如下：

1. 采用 C++  编写整体后端引擎代码，保持在多平台的可移植性，最小化平台依赖，降低平台移植成本。
2. 整体绘制采用自渲染机制，降低平台依赖，同时进一步提升绘制效果的一致性。
3. 抽象出平台适配层以及平台桥接层，以便不同平台的适配。

模块功能介绍

ArkUI主要包括以下几个模块：

1. 研发模型，兼容OpenHarmony应用的Stage开发模型，支持基于ArkTS的声明式开发范式，可跨平台。
2. 声明式UI后端引擎，包括布局，渲染，C++ UI组件，事件机制等，可跨平台。
3. API扩展机制，基于NAPI机制，可跨平台。 不同平台需要各自扩展具体的API实现。
4. 工具链/SDK, 工具链可跨平台，SDK需基于不同平台构建。

另外，ArkUI依赖的ArkTS引擎以及图形引擎，也可跨平台。

ArkUI声明式UI后端引擎，主要完成整体pipeline流程控制、视图更新、布局系统、多页面管理、事件分发和回调、焦点管理、动画机制、主题机制、资源管理/缓存/provider等。 其中的UI组件，主要通过显示相关组件细粒度化，动画、事件、焦点等机制组件化，满足适配不同前端所需要的灵活性。

整体的跨平台需求，就是扩展ArkUI开发框架到其他OS平台，帮助开发者降低多平台应用开发成本。

通过ACE Tools命令行工具创建跨平台应用工程，开发者基于一套主代码，就可以构建支持多平台的精美、高性能应用。

方案设计

跨平台应用包结构设计

跨平台应用目录结构，包含一套为ArkUI-X开发者提供的应用工程模板，提供构建OpenHarmony应用、Android应用、iOS应用的能力。应用工程包结构设计如下：

ArkUI-X应用工程
  ├── .arkui-x
  │   ├── android                 // Android平台相关代码
  │   └── ios                     // iOS平台相关代码
  ├── .hvigor
  ├── .idea
  ├── AppScope
  ├── entry
  ├── hvigor
  ├── oh_modules
  ├── build-profile.json5
  ├── hvigorfile.ts
  ├── local.properties
  └── oh-package.json5

ArkUI-X应用目录结构设计思想是从OpenHarmony应用工程原生支持跨平台角度出发，在OpenHarmony应用工程之上叠加Android和iOS应用工程，ArkTS代码和resources资源编辑仍在OpenHarmony侧完成，Native代码在各自平台应用工程中完成。详细包结构设计。

ArkUI-X应用工程结构说明

简介

本文档配套ArkUI-X，将OpenHarmony ArkUI开发框架扩展到不同的OS平台，比如Android和iOS平台，让开发者基于ArkUI，可复用大部分的应用代码（UI以及主要应用逻辑）并可以部署到相应的OS平台，降低跨平台应用开发成本。

应用工程目录结构介绍

跨平台应用工程目录结构，包含一套为ArkUI开发者提供的应用工程模板，提供构建OpenHarmony应用，HarmonyOS应用，Android应用，iOS应用的能力。

ArkUI-X应用工程目录结构
  ├── .arkui-x
  │   ├── android                 // Android平台相关代码
  │   └── ios                     // iOS平台相关代码
  ├── AppScope
  ├── entry
  ├── hvigor
  ├── build-profile.json5
  ├── hvigorfile.ts
  ├── hvigorw
  ├── hvigorw.bat
  ├── local.properties
  └── oh-package.json5

此应用目录结构设计思想是从OpenHarmony应用工程原生支持跨平台角度出发，在OpenHarmony应用工程之上叠加Android和iOS应用工程，ArkTS代码和resources资源在OpenHarmony侧完成编译，Native代码仍在各自平台应用工程中完成编译。

编译构建说明

• ArkTS源码

ArkTS源码通过OpenHarmony SDK工具链生成abc（Ark Byte Code），并分别拷贝到Android和iOS应用工程，作为平台应用资源进行管理。

• ArkUI应用资源

ArkUI Resources资源也通过OpenHarmony SDK工具链进行编译，编译后的ArkUI资源分别拷贝到Android和iOS应用工程，作为平台应用资源进行管理。

• ArkUI框架资源

ArkUI框架资源随ArkUI-X SDK进行发布，应用构建时会自动打包到ArkUI-X应用中，可保证ArkUI-X应用在各平台上UX渲染一致性。

综上所述，Android平台上通过assets管理ArkTS编译产物、ArkUI应用资源和ArkUI框架资源，iOS平台上通过Bundle Resources管理ArkTS编译产物、ArkUI应用资源和ArkUI框架资源。

Android应用工程结构

ArkUI-X Android应用工程
├── app
│   ├── libs
│   │   ├── arkui_android_adapter.jar                   // ArkUI-X跨平台适配层，在SDK中发布
│   │   └── arm64-v8a
│   │       └── libarkui_android.so                     // ArkUI-X跨平台引擎库，在SDK中发布
│   │       └── libhilog.so                             // ArkUI-X日志库，在SDK中发布
│   │       └── libresourcemanager.so                   // ArkUI-X资源管理库，在SDK中发布
│   ├── src
│   │   ├── androidTest
│   │   ├── main
│   │   │   ├── assets
│   │   │   │   └── arkui-x                             // ArkUI应用编译后的字节码文件和Resources，作为资源文件存放在assets/arkui-x中
│   │   │   │       ├── entry                           // ArkUI单个模块的编译结果
│   │   │   │       │   ├── ets                         // ArkUI单个模块代码的编译结果：包括字节码文件以及sourceMap文件
│   │   │   │       │   │   ├── sourceMaps.map
│   │   │   │       │   │   └── modules.abc
│   │   │   │       │   ├── resources.index             // ArkUI单个模块资源的编译结果：resources资源的编译结果
│   │   │   │       │   ├── resources                   // resources资源中的rawfile资源，不会进行编译。
│   │   │   │       │   └── module.json
│   │   │   │       ├── entry_test                      // ohosTest，仅仅Debug模式构建包含。
│   │   │   │       └── systemres                       // ArkUI框架自带的系统资源
│   │   │   ├── java/com/example/mayapp
│   │   │   │   ├── MyApplication.java                  // 基于StageApplication扩展MyApplication
│   │   │   │   └── EntryEntryAbilityActivity.java      // 基于StageActivity扩展EntryEntryAbilityActivity
│   │   │   ├── res
│   │   │   └── AndroidManifest.xml
│   │   └── test
│   ├── build.gradle
│   └── proguard-rules.pro
├── gradle/wrapper
├── build.gradle
├── gradle.properties
├── gradlew
├── gradlew.bat
└── settings.gradle

iOS应用工程结构

ArkUI-X iOS应用工程
├── app.xcodeproj
│   ├── project.xcworkspace
│   ├── xcuserdata
│   └── project.pbxproj
├── app
│   ├── Assets.xcassets
│   ├── Base.Iproj
│   ├── AppDelegate.h
│   ├── AppDelegate.m                               // 应用入口, 驱动StageApplication的生命周期
│   ├── EntryEntryAbilityViewController.h           
│   ├── EntryEntryAbilityViewController.m           // 基于StageViewController扩展EntryEntryViewController
│   ├── Info.plist
│   └── main.m
├── arkui-x                                         // ArkUI应用编译后的字节码文件和Resources，作为资源文件存放在assets/arkui-x中
│   ├── entry                                       // ArkUI单个模块的编译结果
│   │   ├── ets                                     // ArkUI单个模块代码的编译结果：包括字节码文件以及sourceMap文件
│   │   │   ├── sourceMaps.map
│   │   │   └── modules.abc
│   │   ├── resources.index                         // ArkUI单个模块资源的编译结果：resources资源的编译结果
│   │   ├── resources                               // resources资源中的rawfile资源，不会进行编译。
│   │   └── module.json
│   ├── entry_test                                  // ohosTest，仅仅Debug模式构建包含。
│   └── systemres                                   // ArkUI框架自带的系统资源
└── frameworks                                      // ArkUI跨平台Framework动态库：包含ArkUI-X的框架以及插件

跨平台框架构建系统

ArkUI-X编译构建提供了一套基于GN和Ninja的编译构建框架，基础构建基于OpenHarmony的build仓，并在OpenHarmony构建基础上新增Android和iOS编译工具链，以支持ArkUI跨平台SDK编译输出。

跨平台SDK结构设计

跨平台SDK主要用于支持ACE Tools命令行跨平台应用构建和DevEco Studio\Android Studio\Xcode集成跨平台应用开发。内容范围主要包括：

1. 提供ArkUI跨平台开发框架基础引擎动态库，API插件动态库。
2. 提供ArkUI跨平台应用构建命令行工具。
3. 提供ArkUI组件渲染一致性系统资源包，应用资源编译工具。

ArkUI-X SDK组成结构如下：

arkui-x
  ├── engine                   // ArkUI-X的引擎库
  │   ├── lib                  // ArkUI-X的引擎库：包括Android平台及架构的动态库
  │   ├── framework            // ArkUI-X的引擎库：包括iOS平台及架构的Framework库
  │   ├── xcframework          // ArkUI-X的引擎库：包括iOS平台及架构的XCFramework库
  │   ├── ets                  // ArkUI-X增量接口，比如：@arkui-x.bridge
  │   ├── apiConfig.json       // engine库配置文件，用于IDE和ACE Tools解析，以支持应用构建按需打包。
  │   └── systemres            // ArkUI-X框架自带的资源
  ├── plugins                  // ArkUI-X官方提供的插件库
  │   ├── component            // ArkUI组件插件库，apiConfig.json
  │   └── api                  // @ohos接口插件库，apiConfig.json
  ├── toolchains               // ArkUI-X应用开发工具，比如：ACE Tools。
  ├── sdkConfig.json           // 增量d.ts路径和接口前缀配置
  ├── arkui-x.json             // SDK管理配置，流水线自动生成
  └── NOTICE.txt

操作系统抽象层

基于C++实现的OS Abstract Layer (下文缩写为OSAL)，屏蔽不同平台的OS相关的实现，主要包含功能列表：

• 日志、Trace抽象层
• 网络接口抽象层
• 文件/资源读写抽象层
• 基础线程抽象层
• 系统资源管理抽象及实现
• 系统Prop配置读取抽象层
• 打点能力抽象层

以Log调用流程为例，整体交互流程如下：

如上述流程，Core模块直接使用Base提供的接口，Base模块对接口进行定义，对于依赖平台的能力，在编译期就选择了对应OS的平台抽象层OSAL。运行时，直接通过OSAL的实现，调用到具体平台相关的库中。

跨平台启动入口

开发框架对应平台语言实现的Entrance，提供不同平台的基础入口环境，跨平台启动入口功能列表：

• 提供多个平台的加载入口，如OpenHarmony侧为一个Ability，Android侧为一个Activity。
• 对接不同平台的生命周期、事件输入、Vsync。
• 对接不同平台的窗口系统、硬件渲染加速。
• 对接不同平台的应用信息。
• 不同平台的原生语言转换到统一的C++后端，公共代码复用。

以Android的启动流程为例，整体交互流程如下：

Stage模型下，Ability声明周期的入口为StageAbility，生命周期一直会通知到JsAbility，执行用户的生命周期回调方法，UI的页面是在onWindowStageCreated的生命周期中，调用Window的loadContent接口进行加载，创建ArkUI的实例并初始化渲染管线，将页面进行渲染显示。

跨平台能力桥接

跨平台能力桥接包含框架内部需要用到的不同的平台能力模块，如：剪切板、输入法、视频等，提供基础能力模块的定义，不同平台按照定义实现对应的功能模块。功能列表：

• 剪切板抽象接口，及不同平台的实现。
• 输入法抽象接口，及不同平台的实现。
• 视频媒体等抽象接口，及不同平台的实现。
• 其它框架内部需要用到的不同的平台能力模块。

以剪切板ClipBoard为例，整体交互流程如下：

如上图，例如在框架核心层的TextField组件中，需要用到剪切板的能力，通过Proxy创建具体的ClipBoard实现，返回抽象的ClipBoard接口。在组件实现层即可实现平台无关的调用。以Android平台为例，GetData的调用会通过JNI调用到平台实现的Plugin中，然后Plugin通过访问剪切板服务实现对应的功能。

API扩展机制

1、JS API扩展机制，用于Native接口能力暴露到JS层，该机制直接复用OpenHarmony上的统一封装机制，扩展API （C++实现），并实现部分内置API，NAPI的整体结构如下图。

对于不同平台，JS API需要遵循OpenHarmony的API定义，在不同平台上通过API扩展机制进行扩展。

跨平台命令行工具ACE Tools

ACE Tools命令行工具作为ArkUI-X跨平台应用构建工具，具有创建/编译/安装/运行调试OpenHarmony、Android和iOS应用的能力。

ACE Tools代码结构
 cli
  ├─node_modules
  ├─src
  │  ├─ace-build                 // 构建跨平台应用安装包
  │  │  ├─ace-compiler
  │  │  └─ace-packager
  │  ├─ace-check                 // 查验ArkUI跨平台应用开发依赖的的库和工具链是否完整
  │  ├─ace-clean                 // 清理跨平台应用编译结果
  │  ├─ace-config                // 配置ArkUI跨平台应用开发环境
  │  ├─ace-create                // 创建ArkUI跨平台应用工程
  │  │  ├─aar
  │  │  ├─ability
  │  │  ├─component
  │  │  ├─framework
  │  │  ├─module
  │  │  └─project
  │  ├─ace-devices               // 列出当前PC所链接的各平台设备
  │  ├─ace-install               // 将跨平台应用安装到连接的设备上
  │  ├─ace-launch                // 在设备上运行跨平台应用
  │  ├─ace-log                   // 滚动展示正在运行的跨平台应用的日志
  │  ├─ace-run                   // 运行跨平台应用包
  │  ├─ace-test                  // 执行测试代码
  │  ├─ace-uninstall             // 将跨平台应用从设备上卸载
  │  ├─bin                       // 命令行入口脚本
  │  └─util
  └─templates                    // 跨平台应用工程模板

鸿蒙开发岗位需要掌握那些核心要领？

目前还有很多小伙伴不知道要学习哪些鸿蒙技术？不知道重点掌握哪些？为了避免学习时频繁踩坑，最终浪费大量时间的。

自己学习时必须要有一份实用的鸿蒙（Harmony NEXT）资料非常有必要。 这里我推荐，根据鸿蒙开发官网梳理与华为内部人员的分享总结出的开发文档。内容包含了：【ArkTS、ArkUI、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、Harmony南向开发、鸿蒙项目实战】等技术知识点。

废话就不多说了，接下来好好看下这份资料。

如果你是一名Android、Java、前端等等开发人员，想要转入鸿蒙方向发展。可以直接领取这份资料辅助你的学习。鸿蒙OpenHarmony知识←前往。下面是鸿蒙开发的学习路线图。

针对鸿蒙成长路线打造的鸿蒙学习文档。鸿蒙（OpenHarmony ）学习手册（共计1236页）与鸿蒙（OpenHarmony ）开发入门教学视频，帮助大家在技术的道路上更进一步。

其中内容包含：

《鸿蒙开发基础》鸿蒙OpenHarmony知识←前往

1. ArkTS语言
2. 安装DevEco Studio
3. 运用你的第一个ArkTS应用
4. ArkUI声明式UI开发
5. .……

《鸿蒙开发进阶》鸿蒙OpenHarmony知识←前往

1. Stage模型入门
2. 网络管理
3. 数据管理
4. 电话服务
5. 分布式应用开发
6. 通知与窗口管理
7. 多媒体技术
8. 安全技能
9. 任务管理
10. WebGL
11. 国际化开发
12. 应用测试
13. DFX面向未来设计
14. 鸿蒙系统移植和裁剪定制
15. ……

《鸿蒙开发实战》鸿蒙OpenHarmony知识←前往

1. ArkTS实践
2. UIAbility应用
3. 网络案例
4. ……

最后

鸿蒙是完全具备无与伦比的机遇和潜力的；预计到年底将有 5,000 款的应用完成原生鸿蒙开发，这么多的应用需要开发，也就意味着需要有更多的鸿蒙人才。鸿蒙开发工程师也将会迎来爆发式的增长，学习鸿蒙势在必行！