1. HarmonyOS 应用开发入门知识_oh_modules

前言

本文编辑时：

最新 DevEco Studio Release版本为：DevEco Studio 3.1.1

最新 Compile SDK Release版本为：3.1.0（API 9）

最新 构建方式为 HVigor，而非 Gradle

最新版本已不再支持 （“Java、JavaScript” 、“类Web开发范式” 和 “FA 模型” ）用于应用开发，因此大部分举例都以 （“ArkTS声明式范式” 和 “Stage 模型”）最新内容为基础

---

一、现有的 UI 框架

HarmonyOS 提供了一套UI开发框架，即 方舟开发框架（ArkUI框架）。方舟开发框架可为开发者提供应用UI开发所必需的能力，比如多种组件、布局计算、动画能力、UI交互、绘制等。

方舟开发框架针对不同目的和技术背景的开发者提供了两种开发范式，分别是基于ArkTS的声明式开发范式（简称“声明式开发范式”）和 兼容JS的类Web开发范式（简称“类Web开发范式”）。

在目前最新IDE版本中，已不再支持 “类Web开发范式” 创建应用

• 声明式开发范式：采用基于 TypeScript 声明式 UI 语法扩展而来的 ArkTS 语言，从组件、动画和状态管理三个维度提供 UI 绘制能力。

• 类Web开发范式：采用经典的 HML、CSS、JavaScript 三段式开发方式，即使用 HTML 标签文件搭建布局、使用 CSS 文件描述样式、使用 JavaScript 文件处理逻辑。该范式更符合于Web前端开发者的使用习惯，便于快速将已有的Web应用改造成方舟开发框架应用。

以下是两种开发范式的简单对比：

二、ArkTS 的概念

ArkTS围绕应用开发在 TypeScript（简称TS）生态基础上做了进一步扩展，继承了TS的所有特性，是TS的超集。

ArkTS 是 HarmonyOS 优选的主力应用开发语言（早期版本支持 Java和JS，现已不再支持了）。所以，具备TS语言开发能力的开发者学习起来会更容易。

当前，ArkTS在TS的基础上主要扩展了如下能力：

• 基本语法：ArkTS定义了声明式UI描述、自定义组件和动态扩展UI元素的能力，再配合ArkUI开发框架中的系统组件及其相关的事件方法、属性方法等共同构成了UI开发的主体。

• 状态管理：ArkTS提供了多维度的状态管理机制。在UI开发框架中，与UI相关联的数据可以在组件内使用，也可以在不同组件层级间传递，比如父子组件之间、爷孙组件之间，还可以在应用全局范围内传递或跨设备传递。另外，从数据的传递形式来看，可分为只读的单向传递和可变更的双向传递。开发者可以灵活的利用这些能力来实现数据和UI的联动。

• 渲染控制：ArkTS提供了渲染控制的能力。条件渲染可根据应用的不同状态，渲染对应状态下的UI内容。循环渲染可从数据源中迭代获取数据，并在每次迭代过程中创建相应的组件。数据懒加载从数据源中按需迭代数据，并在每次迭代过程中创建相应的组件。

未来，ArkTS会结合应用开发/运行的需求持续演进，逐步提供并行和并发能力增强、系统类型增强、分布式开发范式等更多特性。

三、HarmonyOS支持的应用模型介绍

HarmonyOS 应用有 两种模型，分别是 FA（Feature Ability）模型 和 Stage模型。通过这两种模型可以构建出以下 三种应用 ：

• FA模型
  • ArkTS应用（过时）
  • JS应用（最新版IDE已不再支持）
• Stage模型
  • ArkTS应用（推荐）

1. 应用模型的演进：

API 4-8 仅支持 FA模型 模型；

API 9 后新增 Stage模型，是目前主推且会长期演进的模型，FA 暂时保留但不推荐；

2. Stage模型的优点：

1. 为复杂应用而设计
2. 支持多设备和多窗口形态
3. 平衡应用能力和系统管控成本

3. 对比传统FA模型和Stage模型：

传统的FA模型设计更偏向传统原生，Stage模型则提供了更好的扩展能力，和更适用于Harmony生态的使用场景。

四、IDE工具和开发工程相关介绍

开发工具为：DevEco Studio，基于 IntelliJ IDEA Community 开源版。

在开发态，一个应用工程包含一个或者多个子工程（Module），可以在 DevEco Studio 工程中创建一个或者多个Module。Module是HarmonyOS应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行。

1. 工程类型

• Application：也就是本文介绍的需要安装且会在桌面创建图标的应用开发
• Atomic Service：不需要安装的原子服务，不在本文应用开发范畴

2. 子工程类型

Module 分为 “Ability”（默认）和 “Library（共享库）” 两种类型。

“Ability” 类型的 Module 对应于编译后的 HAP（Harmony Ability Package）；

“Library” 类型的 Module 对应于 静态共享库 HAR（Harmony Archive），或者 动态共享库 HSP（Harmony Shared Package）。

3. 创建应用面板

4. 工程目录结构介绍（Stage 模型的 ArkTS 应用）

• AppScope > app.json5：应用的全局配置信息。

• entry：HarmonyOS工程模块，编译构建生成一个HAP包。

  • src > main > ets：用于存放ArkTS源码。
  • src > main > ets > entryability：应用/服务的入口。
  • src > main > ets > pages：应用/服务包含的页面。
  • src > main > resources：用于存放应用/服务所用到的资源文件，如图形、多媒体、字符串、布局文件等。关于资源文件，详见资源分类与访问。
  • src > main > module.json5：Stage模型模块配置文件。主要包含HAP包的配置信息、应用/服务在具体设备上的配置信息以及应用/服务的全局配置信息。具体的配置文件说明，详见module.json5配置文件。

• build-profile.json5：当前的模块信息、编译信息配置项，包括buildOption、targets配置等。其中targets中可配置当前运行环境，默认为HarmonyOS。

• hvigorfile.ts：模块级编译构建任务脚本，开发者可以自定义相关任务和代码实现。

• oh_modules：用于存放三方库依赖信息。关于原npm工程适配ohpm操作，请参考历史工程迁移。

• build-profile.json5：应用级配置信息，包括签名、产品配置等。

• hvigorfile.ts：应用级编译构建任务脚本。

五、构建后的应用程序包介绍

1. HAP的两种类型

通过 DevEco Studio 可以把应用程序编译为一个或者多个 .hap 后缀的文件，即 HAP。HAP是HarmonyOS应用安装的基本单位，包含了编译后的代码、资源、三方库及配置文件。HAP可分为 Entry 和 Feature 两种类型。

• Entry 类型的 HAP：是应用的主模块，在 module.json5 配置文件中的 type标签 配置为“entry”类型。在同一个应用中，同一设备类型只支持一个Entry类型的HAP，通常用于实现应用的入口界面、入口图标、主特性功能等。

• Feature 类型的 HAP：是应用的动态特性模块，在 module.json5 配置文件中的 type标签 配置为“feature”类型。一个应用程序包可以包含一个或多个Feature类型的HAP，也可以不包含；Feature类型的HAP通常用于实现应用的特性功能，可以配置成按需下载安装，也可以配置成随Entry类型的HAP一起下载安装（请参见module对象内部结构中的“deliveryWithInstall”）。

2. Bundle的概念

每个HarmonyOS应用可以包含多个.hap文件，一个应用中的.hap文件合在一起称为一个Bundle，而 bundleName 就是应用的唯一标识（请参见 app.json5 配置文件中的 bundleName 标签）。需要特别说明的是：在应用上架到应用市场时，需要把应用包含的所有.hap文件（即Bundle）打包为一个 .app 后缀的文件用于上架，这个.app文件称为 App Pack（Application Package），其中同时包含了描述App Pack属性的 pack.info 文件；在云端（服务器）分发和终端设备安装时，都是以HAP为单位进行分发和安装的。

3. 多HAP使用规则

• App Pack包不能直接安装到设备上，只是上架应用市场的单元。

• App Pack包中所有HAP的配置文件中的 bundleName 标签必须一致。

• App Pack包中所有HAP的配置文件中的 versionCode 标签必须一致。

• App Pack包中同一设备类型的所有HAP中必须有且只有一个entry类型的HAP，feature类型的HAP可以有一个或者多个，也可以没有。

• App Pack包中的每个HAP必须配置 moduleName 标签，同一设备类型的所有HAP对应的 moduleName 标签必须唯一。

• 同一应用的所有HAP签名证书要保持一致。上架应用市场是以App Pack的形式上架，并对其进行了签名。应用市场分发时会将所有HAP从App Pack中拆分出来，同时对其中的所有HAP进行重签名，这样保证了所有HAP签名证书的一致性。在调试阶段，开发者通过命令行或IDE将HAP安装到设备上时要保证所有HAP签名证书一致，否则会出现安装失败的问题。

4. 程序包内目录结构介绍（Stage 模型的 ArkTS 应用）

打包后的HAP包结构包括 ets、libs、resources 等文件夹，和 resources.index、module.json、pack.info 等文件。

• ets目录：用于存放应用代码编译后的字节码文件。

• libs目录：用于存放库文件。库文件是HarmonyOS应用依赖的第三方代码（例如：.so二进制文件）。

• resources目录：用于存放应用的资源文件（字符串、图片等），便于开发者使用和维护，详见zh-cn_topic_0000001523808422.html。

• resources.index：资源索引表，由IDE编译工程时生成。

• module.json：是HAP的配置文件，内容由工程配置中的 module.json5 和 app.json5 组成，该文件是HAP中必不可少的文件。IDE会自动生成一部分默认配置，开发者按需修改其中的配置。详细字段请参见应用配置文件。

• pack.info：是Bundle中用于描述每个HAP属性的文件，例如app中的 bundleName 和 versionCode 信息、module中的 name、type、abilities 等信息，由IDE工具生成Bundle包时自动生成。

六、共享库

OpenHarmony 提供了两种共享包，HAR（Harmony Archive）静态共享包，和 HSP（Harmony Shared Package）动态共享包。共享库不能独立安装运行在设备上，只能作为应用模块的依赖项被引用。

HAR 与 HSP 都是为了实现代码和资源的共享，都可以包含 代码、C++库、资源和配置文件，最大的不同之处在于：

• HAR 中的代码和资源跟随使用方编译，如果有多个使用方，它们的编译产物中会存在多份相同拷贝。
• HSP 中的代码和资源可以独立编译，运行时在一个进程中代码也只会存在一份。

HSP旨在解决HAR存在的几个问题：

• 多个 HAP 引用相同的 HAR，导致的 APP 包大小膨胀问题。
• 多个 HAP 引用相同的 HAR，HAR 中的一些状态变量无法共享的问题。

HSP的一些约束：

• HSP 及其使用方都必须是 Stage 模型。
• HSP 及其使用方都必须使用 esmodule 编译模式。
• HSP 不支持在配置文件中声明 abilities、extensionAbilities 标签。
• HSP 按照使用场景可以分为应用内 HSP 和应用间 HSP，应用间 HSP 暂不支持。
• 应用内 HSP 跟随其宿主应用的 APP 包一起发布，与该宿主应用具有相同的包名和生命周期。

七、快速修复

值得一提的是，HarmonyOS的应用程序设计中官方支持了快速修复，以替换部分文件的方式对bug进行修复，并且是在较短的时间内不中断正在运行的应用的情况下（即不需要重启应用）。

快速修复的使用规则：

1. 仅支持修复应用的TS和C++代码，对应的文件为.abc文件（TS编译后的文件）和.so文件（C++编译后的文件），不支持对资源的修复。
   不支持新增.abc文件和.so文件。
2. 快速修复包部署时要确保对应应用包已安装，如果未安装，则部署失败。
3. 快速修复包中配置的包名和应用版本号必须和已安装的包名和版本号应用相同，如果不同则部署失败。
4. 如果已经部署过快速修复包，新部署的快速修复包的版本号必须大于之前快速修复包的版本号，否则部署失败。
5. 快速修复包的签名信息和待修复的应用的签名信息必须一致，否则会部署失败。
6. 新的应用版本发布安装时，会清理掉快速修复包。

快速修复包结构：

其实结构和程序包差不多，只是文件包格式不一样，程序包是：.app 包含多个 .hap；修复包是 .appqf 包含多个 .hqf。

• appqf（Application Quick Fix）

.appqf 与应用的 app pack 包是一一对应关系，具体可参考上文应用程序包结构的介绍。

- appqf 包是HarmonyOS应用用于发布到应用市场的单元，不能够直接安装到设备上。
- 它是由一个或多个 hqf（Harmony Ability Package Quick Fix）组成，这些 hqf 包在应用市场会从 appqf 包中拆分出来，再被分发到具体的设备上。
- appqf 包上架到应用市场前要有开发者的签名信息。
1
2
3

• hqf（Harmony Ability Package Quick Fix）

.hqf 包是修复 HAP 中问题的快速修复包，用于安装到设备上的快速修复单元。一个 hqf 可以包含 .abc 的快速修复文件，.so 的快速修复文件和描述该包的配置文件。

- .abc文件：应用中修改后的 ts 代码，编译后生成的字节码文件。
- libs目录：存放 .so 库文件的差分文件，以 .so.diff 为后缀。区分的不同的系统 cpu 架构，例如 arm 平台、x86 平台。
- patch.json：
1
2
3

patch.json 文件用于描述 hqf 包版本信息的配置文件，由开发者填写，具体内容如下：

{
    "app" : {
        "bundleName" : "com.ohos.quickfix",
        "versionCode" : 1000000, // 应用版本号
        "versionName" : "1.0.0",
        "patchVersionCode" : 1000000, // 补丁版本号
        "patchVersionName" : "1.0.0"
    },
    "module" : {
        "name" : "entry",
        "type" : "patch",
        "deviceTypes" : [
        "default",
        "tablet"
        ],
        "originalModuleHash" : "11223344556677889900" // 待修复hap包的sha256值，可采用SHA256生成器自行生成
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

快速修复包的调试流程：

快速修复命令行调试开发指导

DevEco Studio中暂时还没有集成快速修复的能力。当前阶段，HarmonyOS为开发者提供了命令行的调试开发工具可供使用，具体的调试开发流程如下：

1. 基于原应用的源码和修复后的源码，通过命令行工具可以编译生成快速修复包，并通过命令行签名工具完成对快速修复的包的签名。通过命令行调试开发，要对 .hqf 包签名，并通过命令行工具将.hqf包安装到设备上，.appqf 包不能直接安装到设备上。

2. 通过快速修复的命令行工具，将 .hqf 包安装部署到设备上。

3. .hqf 包安装部署完成后，回调通知快速修复引擎触发应用使用快速修复包，进而保证用户使用到问题修复后的功能。

快速修复包的端到端发布部署流程：

1. 开发者通过 DevEco Studio，基于原应用的源码和修复后的源码编译打包生成快速修复包，并通过 DevEco Studio 完成快速修复包的签名。

2. 将生成的带有签名的快速修复包上架到应用市场，应用市场通过验证签名、风险扫描和拆包重签名后进行分发。

3. 设备侧的应用市场客户端检测到应用市场服务器端有新上架的快速修复包会下载最新版本的快速修复包，接着通过系统中的包管理服务来安装部署快速修复包。

4. 快速修复包部署完成后，再由快速修复引擎触发应用使用快速修复包，进而保证用户使用到问题修复后的功能。

以上是我在这几天阅读了最新版的鸿蒙应用开发入门部分文档后，精简内容记下的入门笔记，仅供参考，后续会不定时更新

---

结语

前不久宣布 HarmonyOS Next 版本将不再兼容 Android 应用这本身就是必然会经历的，于是突然冒出了很多鸿蒙开发岗位，毕竟大量的高质量用户手持华为设备，这是不得不移植版本的，其实在早期推鸿蒙社区的时候就已经有不少大厂在着手做这件事了，我觉得鸿蒙的优势还是跨端跨设备的生态体验。现在的 Android 原生开发市场已经不像前几年了，大前端的各种平台层出不穷，如果仅仅就以华为自己的生态设备量救活整个 Android 原生的开发市场那也是了不起的一件事。

不吹不黑，鸿蒙的整个开发套件第一个版本刚发布时比起迭代了很久的其他平台显得有些粗糙，而且无论是开发形式、API的设计、手机系统的设计和交互都参考了 Android，快速发展的这几年逐步脱离，蜕变得更为个性了。Java 和 JS 都从 Ark 套件里淡出视野了，我记得最开始都还和 Android 一样用 xml 写布局，现在的版本稳定使用 eTS，抛弃命令式拥抱声明式，我觉得集所开发语言的优点于一身对开发者算是件好事。

最新版本的 DevEco Studio，体验比以前的版本好了不少，构建工具 Hvigor 比起 Android Studio 的 Gradle 速度快很多（非常想吐槽现在as的体验），经历几年后对比刚开始的两个版本体验提升明显。个人总结了鸿蒙开发以下几点体验结果：

1. 开发工具基于 IntelliJ IDEA Community 开源版，对长期用 JetBrains 家族工具的人无缝衔接好上手，同时也做出了一些差异化的体验

2. IDE 内集成了官方的开发教程、文档、QA，代码示例完整可以直接copy运行，可以更方便查找一些文档，比较好的还有可以直接调起工具内的各种功能

3. 对代码高亮、提示、自定义折叠处理得很好，但是工程结构感觉还能再优化，配置文件还是稍显繁琐，尤其是多 Module的情况（说到配置文件，JSON内也支持注释和提示很不错，不过会比较依赖工具，换个编辑器浏览文件体验会大打折扣）

4. 从开发工具到 SDK、Tools、本地模拟器的整个安装过程很顺很快。新版本的构建工具从 Gradle 换成了 Hvigor 后，新建项目和编译构建速度快得飞起，又想吐槽一下 Android Studio 默认下载一大堆依赖的糟糕体验，当然这个也跟鸿蒙本身起步不久，吸取了经验做好了各种版本和依赖库管理有关

5. 低代码工具直接集成进IDE里了，而且可以和代码编辑器切换使用，比传统的拖拽式布局好用，也给产品经理提供了便捷

6. 文档方面，全本地化中文的文档看起来非常轻松，内容排版也更符合国人的阅读习惯，不过官方的视频课程内容稍微有一点落后，反正不是最新的内容，估计新版本内容正在制作，学习还是建议看开发文档，推荐一下入门的几个模块的文档（按顺序排列）：

   方舟开发框架（ArkUI）概述

   HarmonyOS 开发基础知识

   ArkTS语言学习

现在国内各个厂商在卷一个方向的同时也在做自己的差异化，都想自家生态内产品都全部自己掌控，不管是包装系统还是真自研系统，要是百花齐放就算是制造了更多不同的就业岗位，那对开发者们也相当痛苦的，毕竟各家都有一定的市场占有率，也不知道能不能打破分久必合合久必分的规则。

华为的生态布局不算最早，但研发能力和行动速度是真的强，胆量也比其他厂商大，可能是有着不同的经历和不同的品牌影响力。
我虽然是个数码爱好者，但要说购买华为的产品兴趣其实并不大，也是对技术的兴趣驱动了我学习和去体验。我更在乎硬件配置的性价比，也可能是消费力还没达到生态内旗舰的水平（不想买低端产品但高端又觉得贵），但这并不影响他的强大也不影响我对他的佩服，可能受《任正非传》的影响，祝愿越来越好吧！