基础知识
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）
4. 一个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通信
渲染进程
为了支持WebView的运行，每个应用只能创建一个Render进程用于运行WebView的渲染引擎。这个Render进程也是由系统负责创建和销毁
基于HarmonyOS的进程模型，系统提供了 公共事件机制 用于一对多的通信场景，公共事件发布者可能存在多个订阅者同时接收事件
线程模型
- ArkTS引擎实例的创建 一个进程可以运行多个应用组件实例，所有应用组件实例共享一个ArkTS引擎实例。
- 线程模型 ArkTS引擎实例在主线程上创建。
- 进程内支持对象共享
HarmonyOS应用中每个进程都会有一个主线程，主线程有如下职责：
- 执行UI绘制；
- 管理主线程的ArkTS引擎实例，使多个UIAbility组件能够运行在其之上；
- 管理其他线程（例如Worker线程）的ArkTS引擎实例，例如启动和终止其他线程；
- 分发交互事件；
- 处理应用代码的回调，包括事件处理和生命周期管理；
- 接收Worker线程发送的消息；
HarmonyOS可以使用Worker线程执行耗时操作，这些线程无法直接操作UI。Worker线程在主线程中创建，与主线程相互独立。最多可以创建8个Worker
线程间通信目前主要有Emitter和Worker两种方式，其中Emitter主要适用于线程间的事件同步， Worker主要用于新开一个线程执行耗时任务
Stage模型只提供了主线程和Worker线程，Emitter主要用于主线程内或者主线程和Worker线程的事件同步
应用配置文件
使用app.json5描述应用信息，module.json5描述HAP信息、应用组件信息
