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

基础知识

Stage模型应用程序包结构

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

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

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

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

HAP

HAP是HarmonyOS应用安装的基本单位，包含了编译后的代码、资源、三方库及配置文件
打包后的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

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

Feature类型的HAP

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

Module

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

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

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

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

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

鸿蒙支持快速修复包

快速修复包结构

appqf（Application Quick Fix）

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

hqf（Harmony Ability Package Quick Fix）

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

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

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

Stage模型

应用组件

AbilityStage组件容器

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

onCreate() 生命周期回调

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

onAcceptWant()事件回调

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

onConfigurationUpdated()事件回调

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

onMemoryLevel() 事件回调

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

应用上下文Context

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

UIAbility组件

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

UIAbility组件生命周期

UIAbility组件启动模式

singleton（单实例模式）

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

standard（标准实例模式）

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

specified（指定实例模式）

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

UIAbility组件与UI的数据同步

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

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

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

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

UIAbility组件间交互（设备内）

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

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

ExtensionAbility组件

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

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

ArkTS运行机制

进程模型

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

主进程

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

ExtensionAbility进程

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