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

基础知识

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信息、应用组件信息

写在最后

• 如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
• 点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。
• 关注小编，同时可以期待后续文章ing
  声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/你好赵伟/article/detail/520849