鸿蒙应用开发-初见：入门知识、应用模型

基础知识

Stage模型应用程序包结构

开发并打包完成后的App的程序包结构如图

1. 开发者通过DevEco Studio把应用程序编译为一个或者多个.hap后缀的文件，即HAP
2. 一个应用中的.hap文件合在一起称为一个Bundle，bundleName是应用的唯一标识

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

3. 所有的HAP最终会编译到一个App Pack中（以.app为后缀的包文件），用于发布到应用市场

HAP

1. HAP是HarmonyOS应用安装的基本单位，包含了编译后的代码、资源、三方库及配置文件
2. 打包后的HAP包结构包括ets、libs、resources等文件夹和resources.index、module.json、pack.info等文件。

• ets目录用于存放应用代码编译后的字节码文件
• libs目录用于存放库文件。库文件是HarmonyOS应用依赖的第三方代码（.so二进制文件）。
• resources目录用于存放应用的资源文件（字符串、图片等）
• resources.index是资源索引表，由IDE编译工程时生成
• module.json是HAP的配置文件，内容由工程配置中的module.json5和app.json5组成，该文件是HAP中必不可少的文件。

Entry类型的HAP

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

Feature类型的HAP

1. 应用的动态特性模块，在 module.json5配置文件 中的type标签配置为“feature”类型。
2. 一个应用程序包可以包含一个或多个Feature类型的HAP，也可以不包含；
3. Feature类型的HAP通常用于实现应用的特性功能，可以配置成按需下载安装，也可以配置成随Entry类型的HAP一起下载安装

Module

1. 一个开发态的Module编译后生成一个部署态的HAP，Module和HAP一一对应
2. Module是HarmonyOS应用/服务的基本功能单元，包含了源代码、资源文件、第三方库及应用/服务配置文件，每一个Module都可以独立进行编译和运行。一个DevEco Studio工程可以包含多个Module
3. Module分为“Ability”和“Library”两种类型

• “Ability”类型的Module对应于编译后的HAP（Harmony Ability Package）；
• “Library”类型的Module对应于 HAR 静态共享包（Harmony Archive），或者 HSP 动态共享包（Harmony Shared Package）

4. 一个Module可以包含一个或多个 UIAbility 组件

• Ability组件是一种包含用户界面的应用组件，用于与用户交互
• Ability组件是系统调度的基本单元，为应用提供绘制界面的窗口
• 一个Ability组件中可以通过多个页面来实现一个模块功能

建议将不同模块功能拆解为不同的Ability组件单独实现，即将一个独立的功能模块放到一个Ability组件中，以多页面的形式呈现。每一个Ability组件实例，都对应于一个任务，可以在最近任务列表中呈现

鸿蒙支持快速修复包

快速修复包结构

appqf（Application Quick Fix）

1. appqf与应用的app pack包是一一对应关系
2. appqf包是HarmonyOS应用用于发布到应用市场的单元，不能够直接安装到设备上
3. 由一个或多个hqf组成，这些hqf包在应用市场会从appqf包中拆分出来，再被分发到具体的设备上

hqf（Harmony Ability Package Quick Fix）

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

• .abc文件：应用中修改后的ts代码，编译后生成的字节码文件
• libs目录：存放.so库文件的差分文件，以.so.diff为后缀。区分的不同的系统cpu架构，例如arm平台、x86平台
• patch.json：用于描述hqf包版本信息的配置文件，由开发者填写

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

Stage模型

应用组件

AbilityStage组件容器

1. AbilityStage是一个 Module 级别的组件容器，应用的HAP在首次加载时会创建一个AbilityStage实例，可以对该Module进行初始化等操作
2. AbilityStage与Module一一对应，即一个Module拥有一个AbilityStage
3. AbilityStage 拥有 onCreate()] 生命周期回调和 onAcceptWant() 、onConfigurationUpdated()、onMemoryLevel() 事件回调

onCreate() 生命周期回调

1. 在开始加载对应Module的第一个UIAbility实例之前会先创建AbilityStage，并在AbilityStage创建完成之后执行其onCreate()生命周期回调
2. AbilityStage模块提供在Module加载的时候，通知开发者，可以在此进行该Module的初始化（如资源预加载，线程创建等）能力

onAcceptWant()事件回调

UIAbility 指定实例模式（specified）启动时候触发的事件回调

onConfigurationUpdated()事件回调

当系统全局配置发生变更时触发的事件，系统语言、深浅色等，配置项目前均定义在 Configuration 类中

onMemoryLevel() 事件回调

当系统调整内存时触发的事件

应用上下文Context

1. Context 是应用中对象的上下文，其提供了应用的一些基础信息
2. UIAbility组件和各种ExtensionAbility派生类组件都有各自不同的Context类。分别有基类Context、ApplicationContext、AbilityStageContext、UIAbilityContext、ExtensionContext、ServiceExtensionContext等Context

UIAbility组件

• 包含UI界面，提供展示UI的能力，主要用于和用户交互。详细介绍请参见 UIAbility组件概述。

UIAbility组件生命周期

UIAbility组件启动模式

• singleton（单实例模式）

1. 每次调用startAbility()方法时，如果应用进程中该类型的UIAbility实例已经存在，则复用系统中的UIAbility实例。
2. 系统中只存在唯一一个该UIAbility实例，即在最近任务列表中只存在一个该类型的UIAbility实例
3. 在 module.json5配置文件 中的"launchType"字段配置为"singleton"

• standard（标准实例模式）

1. 每次调用startAbility()方法时，都会在应用进程中创建一个新的该类型UIAbility实例
2. 即在最近任务列表中可以看到有多个该类型的UIAbility实例
3. 在 module.json5配置文件 中的"launchType"字段配置为"standard"

• specified（指定实例模式）

1. 在UIAbility实例创建之前，允许开发者为该实例创建一个唯一的字符串Key
2. 创建的UIAbility实例绑定Key之后，后续每次调用startAbility()方法时，都会询问应用使用哪个Key对应的UIAbility实例来响应startAbility()请求。通过AbilityStage的onAcceptWant实现
3. 运行时由UIAbility内部业务决定是否创建多实例，如果匹配有该UIAbility实例的Key，则直接拉起与之绑定的UIAbility实例，否则创建一个新的UIAbility实例
4. module.json5配置文件 的"launchType"字段配置为"specified"

UIAbility组件与UI的数据同步

基于HarmonyOS的应用模型，可以通过以下两种方式来实现UIAbility组件与UI之间的数据同步

1. EventHub：基于发布订阅模式来实现，事件需要先订阅后发布，订阅者收到消息后进行处理。

• 在使用EventHub之前，首先需要获取EventHub对象。基类Context 提供了EventHub对象

2. globalThis：ArkTS引擎实例内部的一个全局对象，在ArkTS引擎实例内部都能访问

UIAbility组件间交互（设备内）

1. UIAbility是系统调度的最小单元。在设备内的功能模块之间跳转时，会涉及到启动特定的UIAbility，该UIAbility可以是应用内的其他UIAbility，也可以是其他应用的UIAbility
2. 通过调用startAbility并传递给它 want 参数启动其他UIAbility，如果期望其他Ability返回结果则可以使用startAbilityForResult

• want中如果传入了abilityName则进行显示跳转，否则进行隐式跳转

ExtensionAbility组件

提供特定场景（如卡片、输入法）的扩展能力，满足更多的使用场景。详细介绍请参见 ExtensionAbility组件。

FormExtensionAbility ：FORM类型的ExtensionAbility组件，用于提供服务卡片场景相关能力

ArkTS运行机制

进程模型

Stage模型有三类进程，是从系统总体资源占用考虑，希望由系统负责应用进程的创建和销毁。所以不支持应用自定义配置多进程，也不支持通过接口启动进程

主进程

开发者编写的UIAbility入口及其依赖的代码都在该进程中运行。它是由UIAbility组件的启动触发创建的。

ExtensionAbility进程

开发者编写的同一种类型的ExtensionAbility组件实例都会在同一个进程中运行。不同类型的ExtensionAbility组件实例则在不同的进程中运行。该类进程是由系统服务在特定场景下创建，并根据用户对特定场景的使用，决定其何时销毁。同时该类进程独立于主进程创建，并且不支持与主进程之间进行IPC通信

渲染进程

为了支持WebView的运行，每个应用只能创建一个Render进程用于运行WebView的渲染引擎。这个Render进程也是由系统负责创建和销毁

基于HarmonyOS的进程模型，系统提供了 公共事件机制 用于一对多的通信场景，公共事件发布者可能存在多个订阅者同时接收事件

线程模型

1. ArkTS引擎实例的创建 一个进程可以运行多个应用组件实例，所有应用组件实例共享一个ArkTS引擎实例。
2. 线程模型 ArkTS引擎实例在主线程上创建。
3. 进程内支持对象共享

HarmonyOS应用中每个进程都会有一个主线程，主线程有如下职责：

1. 执行UI绘制；
2. 管理主线程的ArkTS引擎实例，使多个UIAbility组件能够运行在其之上；
3. 管理其他线程（例如Worker线程）的ArkTS引擎实例，例如启动和终止其他线程；
4. 分发交互事件；
5. 处理应用代码的回调，包括事件处理和生命周期管理；
6. 接收Worker线程发送的消息；

HarmonyOS可以使用Worker线程执行耗时操作，这些线程无法直接操作UI。Worker线程在主线程中创建，与主线程相互独立。最多可以创建8个Worker

线程间通信目前主要有Emitter和Worker两种方式，其中Emitter主要适用于线程间的事件同步， Worker主要用于新开一个线程执行耗时任务

Stage模型只提供了主线程和Worker线程，Emitter主要用于主线程内或者主线程和Worker线程的事件同步

应用配置文件

使用app.json5描述应用信息，module.json5描述HAP信息、应用组件信息

为了能让大家更好的学习鸿蒙 (Harmony OS) 开发技术，这边特意整理了《鸿蒙 (Harmony OS)开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05

《鸿蒙 (Harmony OS)开发学习手册》

入门必看：https://qr21.cn/FV7h05

1. 应用开发导读(ArkTS)
2. 应用开发导读(Java)

HarmonyOS 概念：https://qr21.cn/FV7h05

1. 系统定义
2. 技术架构
3. 技术特性
4. 系统安全

如何快速入门：https://qr21.cn/FV7h05

1. 基本概念
2. 构建第一个ArkTS应用
3. 构建第一个JS应用
4. ……

开发基础知识：https://qr21.cn/FV7h05

1. 应用基础知识
2. 配置文件
3. 应用数据管理
4. 应用安全管理
5. 应用隐私保护
6. 三方应用调用管控机制
7. 资源分类与访问
8. 学习ArkTS语言
9. ……

基于ArkTS 开发：https://qr21.cn/FV7h05

1. Ability开发
2. UI开发
3. 公共事件与通知
4. 窗口管理
5. 媒体
6. 安全
7. 网络与链接
8. 电话服务
9. 数据管理
10. 后台任务(Background Task)管理
11. 设备管理
12. 设备使用信息统计
13. DFX
14. 国际化开发
15. 折叠屏系列
16. ……