中国总决赛
√
全球总决赛
√
学习进度
完成
省赛
√
能力分类
主要子系统
能力模型
应用开发模型(Stage)
应用开发模型
重点概述
HarmonyOS 的应用软件包以 APP Pack(Application Package)形式发布,它是由一个 或多个 HAP(HarmonyOS Ability Package)以及描述每个 HAP 属性的 pack.info 组成。 HAP 是 Ability 的部署包,HarmonyOS 应用代码围绕 Ability 组件展开。 一个 HAP 是由代码、资源、第三方库及应用配置文件组成的模块包,可分为 entry 和 feature 两种模块类型。
- entry:应用的主模块。一个 APP 中,对于同一设备类型必须有且只有一个 entry 类型 的 HAP,可独立安装运行。
- feature:应用的动态特性模块。一个 APP 可以包含一个或多个 feature 类型的 HAP, 也可以不含。只有包含 Ability 的 HAP 才能够独立运行。
HarmonyOS的应用分为FA(Feature Ability)和PA(Particle Ability)。
- FA:Feature Ability,元服务,代表有界面的Ability,用于与用户进行交互。
- PA:Particle Ability,元能力,代表无界面的Ability,主要为Feature Ability提供支持,例如作为后台服务提供计算能力,或作为数据仓库提供数据访问能力。
- 一个HarmonyOS的应用由一个或多个FA或PA组成。
APP Pack
Ability
Ability 是应用所具备的能力的抽象,一个应用可以包含一个或多个 Ability。Ability 分为两 种类型:FA(Feature Ability)和 PA(Particle Ability)。FA/PA 是应用的基本组成单元, 能够实现特定的业务功能。FA 有 UI 界面,而 PA 无 UI 界面。
库文件
库文件是应用依赖的第三方代码(例如 so、jar、bin、har 等二进制文件),存放在 libs 目录。
资源文件
应用的资源文件(字符串、图片、音频等)存放于 resources 目录下,便于开发者使用和维 护,详见资源文件的分类。
配置文件
配置文件 (config.json) 是应用的 Ability 信息,用于声明应用的 Ability,以及应用所需权 限等信息,详见应用配置文件。
pack.info
描述应用软件包中每个 HAP 的属性,由 IDE 编译生成,应用市场根据该文件进行拆包和 HAP 的分类存储。HAP 的具体属性包括:
- delivery-with-install: 表示该 HAP 是否支持随应用安装。“true”表示支持随应用安 装;“false”表示不支持随应用安装。
- name:HAP 文件名。
- module-type:模块类型,entry 或 feature。
- device-type:表示支持该 HAP 运行的设备类型。
HAR
HAR(HarmonyOS Ability Resources)可以提供构建应用所需的所有内容,包括源代码、
资源文件和 config.json 文件。HAR 不同于 HAP,HAR 不能独立安装运行在设备上,只能 作为应用模块的依赖项被引用。
应用模型的构成要素
应用模型是HarmonyOS为开发者提供的应用程序所需能力的抽象提炼,它提供了应用程序必备的组件和运行机制。有了应用模型,开发者可以基于一套统一的模型进行应用开发,使应用开发更简单、高效。
HarmonyOS应用模型的构成要素包括:
- 应用组件
应用组件是应用的基本组成单位,是应用的运行入口。用户启动、使用和退出应用过程中,应用组件会在不同的状态间切换,这些状态称为应用组件的生命周期。应用组件提供生命周期的回调函数,开发者通过应用组件的生命周期回调感知应用的状态变化。应用开发者在编写应用时,首先需要编写的就是应用组件,同时还需编写应用组件的生命周期回调函数,并在应用配置文件中配置相关信息。这样,操作系统在运行期间通过配置文件创建应用组件的实例,并调度它的生命周期回调函数,从而执行开发者的代码。
- 应用进程模型
应用进程模型定义应用进程的创建和销毁方式,以及进程间的通信方式。
- 应用线程模型
应用线程模型定义应用进程内线程的创建和销毁方式、主线程和UI线程的创建方式、线程间的通信方式。
- 应用任务管理模型
应用任务管理模型定义任务(Mission)的创建和销毁方式,以及任务与组件间的关系。HarmonyOS应用任务管理由系统应用负责,三方应用无需关注,下文不做具体介绍。
- 应用配置文件
应用配置文件中包含应用配置信息、应用组件信息、权限信息、开发者自定义信息等,这些信息在编译构建、分发和运行阶段分别提供给编译工具、应用市场和操作系统使用。
Ability Kit(程序框架服务)
Ability Kit(程序框架服务)提供了应用程序开发和运行的应用模型,是系统为开发者提供的应用程序所需能力的抽象提炼,它提供了应用程序必备的组件和运行机制。有了应用模型,开发者可以基于一套统一的模型进行应用开发,使应用开发更简单、高效。
使用场景
- 应用的多Module开发:应用可通过不同类型的Module(HAP、HAR、HSP)来实现应用的功能开发。其中,HAP用于实现应用的功能和特性,HAR与HSP用于实现代码和资源的共享。
- 应用内的交互:应用内的不同组件之间可以相互跳转。比如,在支付应用中,通过入口UIAbility组件启动收付款UIAbility组件。
- 应用间的交互:当前应用可以启动其他应用,来完成某个任务或操作。比如,启动浏览器应用来打开网站、启动文件应用来浏览或编辑文件等。
- 应用的跨设备流转:通过应用的跨端迁移和多端协同,获得更好的使用体验。比如,在平板上播放的视频,迁移到智慧屏继续播放。
能力范围
- 提供应用进程创建和销毁、应用生命周期调度能力。
- 提供应用组件运行入口、应用组件生命周期调度、组件间交互等能力。
- 提供应用上下文环境、系统环境变化监听等能力。
- 提供应用流转能力。
- 提供多包机制、共享包、应用信息配置等能力,详见应用程序包概述。
- 提供程序访问控制能力,详见访问控制概述。
- 提供安全密码自动填充能力,详见密码自动填充服务概述。
亮点/特征
- 为复杂应用而设计
- 多个应用组件共享同一个ArkTS引擎(运行ArkTS语言的虚拟机)实例,应用组件之间可以方便的共享对象和状态,同时减少复杂应用运行对内存的占用。
- 采用面向对象的开发方式,使得复杂应用代码可读性高、易维护性好、可扩展性强。
- 提供模块化能力开发的支持。
- 原生支持应用组件级的跨端迁移和多端协同
- 在跨端迁移场景下,系统在多设备的应用组件之间迁移数据/状态后,UI便可利用ArkUI的声明式特点,通过应用组件中保存的数据/状态恢复用户界面,便捷实现跨端迁移。
- 在多端协同场景下,应用组件具备组件间通信的RPC调用能力,天然支持跨设备应用组件的交互。
Stage模型实现了应用组件与UI解耦。
- 支持多设备和多窗口形态
- 便于系统对应用组件进行裁剪(无屏设备可裁剪窗口)。
- 便于系统扩展窗口形态。
- 在多设备(如桌面设备和移动设备)上,应用组件可使用同一套生命周期。
应用组件管理和窗口管理在架构层面解耦。
- 平衡应用能力和系统管控成本
- 提供特定场景(如服务卡片、输入法)的应用组件,以便满足更多的使用场景。
- 规范化后台进程管理:为保障用户体验,Stage模型对后台应用进程进行了有序治理,应用程序不能随意驻留在后台,同时应用后台行为受到严格管理,防止恶意应用行为。
Stage模型重新定义应用能力的边界,平衡应用能力和系统管控成本。
与相关Kit的关系
- ArkUI: 在Ability Kit的UIAbility组件中,可以使用ArkUI提供的组件、事件、动效、状态管理等能力。
- ArkTS: ArkTS提供了语言运行时相关能力。
Stage模型
Stage模型开发概述
图1 Stage模型概念图

- AbilityStage
每个Entry类型或者Feature类型的HAP在运行期都有一个AbilityStage类实例,当HAP中的代码首次被加载到进程中的时候,系统会先创建AbilityStage实例。
- UIAbility组件和ExtensionAbility组件
- UIAbility组件是一种包含UI界面的应用组件,主要用于和用户交互。例如,图库类应用可以在UIAbility组件中展示图片瀑布流,在用户选择某个图片后,在新的页面中展示图片的详细内容。同时用户可以通过返回键返回到瀑布流页面。UIAbility的生命周期只包含创建/销毁/前台/后台等状态,与显示相关的状态通过WindowStage的事件暴露给开发者。
- ExtensionAbility组件是一种面向特定场景的应用组件。开发者并不直接从ExtensionAbility派生,而是需要使用ExtensionAbility的派生类。目前ExtensionAbility有用于卡片场景的FormExtensionAbility,用于闲时任务场景的WorkSchedulerExtensionAbility等多种派生类,这些派生类都是基于特定场景提供的。例如,用户在桌面创建应用的卡片,需要应用开发者从FormExtensionAbility派生,实现其中的回调函数,并在配置文件中配置该能力。ExtensionAbility派生类实例由用户触发创建,并由系统管理生命周期。在Stage模型上,普通应用开发者不能开发自定义服务,而需要根据自身的业务场景通过ExtensionAbility的派生类来实现。
Stage模型提供UIAbility和ExtensionAbility两种类型的组件,这两种组件都有具体的类承载,支持面向对象的开发方式。
- WindowStage
每个UIAbility类实例都会与一个WindowStage类实例绑定,WindowStage类起到了应用进程内窗口管理器的作用,它包含一个主窗口。也就是说,UIAbility通过WindowStage持有了一个窗口,该窗口为ArkUI提供了绘制区域。
- Context
在Stage模型上,Context及其派生类向开发者提供在运行期可以调用的各种能力。UIAbility组件和各种ExtensionAbility派生类都有各自不同的Context类,他们都继承自基类Context,但是各自又根据所属组件,提供不同的能力。
开发流程
基于Stage模型开发应用时,在应用模型部分,涉及如下开发过程。
任务 | 简介 | 相关指导 |
应用组件开发 | 本章节介绍了如何使用Stage模型的UIAbility组件和ExtensionAbility组件开发应用。 | |
了解进程模型 | 本章节介绍了Stage模型的进程模型以及几种常用的进程间通信方式。 | - 公共事件 |
了解线程模型 | 本章节介绍了Stage模型的线程模型以及几种常用的线程间通信方式。 | |
应用配置文件 | 本章节介绍Stage模型中应用配置文件的开发要求。 |
例题
30.[单选题]
在 Stage 模型中,模块的配置文件是
A. main_pages.json
B. module.json5
C. app.json5
D. package.json
答案:B
2.[多选题]
在Stage模型中,系统中应用间和应用内都会存在多个进程的情况,以下哪些是系统提供的进程间的通信机制。
A:公共事件机制
B:后台服务机制
C:前台机制
D:广播机制
正确答案:AB
答案解析:暂无
UIAbility组件
UIAbility组件是系统调度的基本单元,为应用提供绘制界面的窗口;一个UIAbility组件中可以通过多个页面来实现一个功能模块。每一个UIAbility组件实例,都对应于一个最近任务列表中的任务。
UIAbility组件生命周期
UIAbility的生命周期包括Create、Foreground、Background、Destroy四个状态,如下图所示。

UIAbility组件启动模式
UIAbility的启动模式是指UIAbility实例在启动时的不同呈现状态。针对不同的业务场景,系统提供了三种启动模式:
在module.json5配置文件中的"launchType"字段配置为"singleton"即可
- singleton(单实例模式)
- 每次调用startAbility()方法时,如果应用进程中该类型的UIAbility实例已经存在,则复用系统中的UIAbility实例。系统中只存在唯一一个该UIAbility实例,即在最近任务列表中只存在一个该类型的UIAbility实例。
- 应用的UIAbility实例已创建,该UIAbility配置为单实例模式,再次调用startAbility()方法启动该UIAbility实例,此时只会进入该UIAbility的onNewWant()回调,不会进入其onCreate()和onWindowStageCreate()生命周期回调。
- multiton(多实例模式)
- multiton启动模式为多实例模式,每次调用startAbility()方法时,都会在应用进程中创建一个新的该类型UIAbility实例。即在最近任务列表中可以看到有多个该类型的UIAbility实例。这种情况下可以将UIAbility配置为multiton(多实例模式)。
- specified(指定实例模式)
- specified启动模式为指定实例模式,针对一些特殊场景使用(例如文档应用中每次新建文档希望都能新建一个文档实例,重复打开一个已保存的文档希望打开的都是同一个文档实例)。
- 在UIAbility实例创建之前,允许开发者为该实例创建一个唯一的字符串Key,创建的UIAbility实例绑定Key之后,后续每次调用startAbility()方法时,都会询问应用使用哪个Key对应的UIAbility实例来响应startAbility()请求。运行时由UIAbility内部业务决定是否创建多实例,如果匹配有该UIAbility实例的Key,则直接拉起与之绑定的UIAbility实例,否则创建一个新的UIAbility实例。
UIAbility组件与UI的数据同步
基于HarmonyOS的应用模型,可以通过以下几种方式来实现UIAbility组件与UI之间的数据同步。
- 使用EventHub进行数据通信:基于发布订阅模式来实现,事件需要先订阅后发布,订阅者收到消息后进行处理。
- 使用globalThis进行数据同步:ArkTS引擎实例内部的一个全局对象,在ArkTS引擎实例内部都能访问。
- 使用AppStorage/LocalStorage进行数据同步:ArkUI提供了AppStorage和LocalStorage两种应用级别的状态管理方案,可用于实现应用级别和UIAbility级别的数据同步。
进程模型
HarmonyOS的进程模型:
- 应用中(同一包名)的所有UIAbility运行在同一个独立进程中。
- WebView拥有独立的渲染进程。
基于HarmonyOS的进程模型,系统提供了公共事件机制用于一对多的通信场景,公共事件发布者可能存在多个订阅者同时接收事件。
主进程:UIAbility、ServiceExtensionAbility、DataShareExtensionAbility。
ExtensionAbility进程:FormExtensionAbility Process、InputMethodExtensionAbility Process、其他ExtensionAbility Process等分别运行在各自的进程中。
渲染进程:WebView拥有独立的渲染进程。
重点:
- 应用中(同一Bundle名称)的所有UIAbility、ServiceExtensionAbility、DataShareExtensionAbility都是运行在应用主进程中的。
- 应用中(同一Bundle名称)的同一类型ExtensionAbility(除ServiceExtensionAbility和DataShareExtensionAbility外)也是运行在各自独立进程中,仅WebView拥有独立的渲染进程。
公共事件服务(进程模型)
HarmonyOS通过CES(Common Event Service,公共事件服务)为应用程序提供订阅、发布、退订公共事件的能力。
分类(考点)
公共事件从系统角度可分为:系统公共事件和自定义公共事件。
- 系统公共事件:CES内部定义的公共事件,只有系统应用和系统服务才能发布,例如HAP安装,更新,卸载等公共事件。
- 自定义公共事件:应用自定义一些公共事件用来实现跨进程的事件通信能力。
公共事件按发送方式可分为:无序公共事件、有序公共事件和粘性公共事件。
- 无序公共事件:CES转发公共事件时,不考虑订阅者是否接收到,且订阅者接收到的顺序与其订阅顺序无关。
- 有序公共事件:CES转发公共事件时,根据订阅者设置的优先级等级,优先将公共事件发送给优先级较高的订阅者,等待其成功接收该公共事件之后再将事件发送给优先级较低的订阅者。如果有多个订阅者具有相同的优先级,则他们将随机接收到公共事件。
- 粘性公共事件:能够让订阅者收到在订阅前已经发送的公共事件就是粘性公共事件。普通的公共事件只能在订阅后发送才能收到,而粘性公共事件的特殊性就是可以先发送后订阅。发送粘性事件必须是系统应用或系统服务,且需要申请ohos.permission.COMMONEVENT_STICKY权限。
公共事件订阅
动态订阅是指当应用在运行状态时对某个公共事件进行订阅,在运行期间如果有订阅的事件发布那么订阅了这个事件的应用将会收到该事件及其传递的参数。例如,某应用希望在其运行期间收到电量过低的事件,并根据该事件降低其运行功耗,那么该应用便可动态订阅电量过低事件,收到该事件后关闭一些非必要的任务来降低功耗。
接口名 | 接口描述 |
createSubscriber(subscribeInfo: CommonEventSubscribeInfo, callback: AsyncCallback<CommonEventData>): void | 创建订阅者对象(callback) |
createSubscriber(subscribeInfo: CommonEventSubscribeInfo): Promise<CommonEventSubscriber> | 创建订阅者对象(promise) |
subscribe(subscriber: CommonEventSubscriber, callback: AsyncCallback): void | 订阅公共事件 |
动态订阅者完成业务需要时,需要主动取消订阅,订阅者通过调用unsubscribe()方法取消订阅事件。
接口名 | 接口描述 |
unsubscribe(subscriber: CommonEventSubscriber, callback?: AsyncCallback) | 取消订阅公共事件 |
公共事件发布
当需要发布某个自定义公共事件时,可以通过publish()方法发布事件。发布的公共事件可以携带数据,供订阅者解析并进行下一步处理。(当需要发布某个自定义公共事件时,可以通过publish()方法发布事件。发布的公共事件可以携带数据,供订阅者解析并进行下一步处理)
publish(event: string, callback: AsyncCallback) | 发布公共事件。 |
publish(event: string, options: CommonEventPublishData, callback: AsyncCallback) | 指定发布信息并发布公共事件。 |
例题
13.[单选题]
公共事件模块需要引入以下哪个模块?
A: import CommonEventManager from ‘@ohos.commonEventManager’;
B: import Common from '@ohos.common';
C: import EventManager from '@ohos.eventManager';
D: import CommonEvent from '@ohos.commonEvent';
正确答案:A
答案解析:import commonEventManager from '@ohos.commonEventManager';
10.[多选题]
下列关于公共事件的说法正确的有?
A:自定义公共事件:应用自定义一些公共事件用来实现跨进程的事件通信能力。
B:有序公共事件:CES转发公共事件时,根据订阅者设置的优先级等级,在接收到优先级较高的一个订阅者回复后,再向下一个优先级较低的订阅者转发公共事件。具有相同优先级的订阅者将按随机顺序收到公共事件。
C:系统公共事件:CES内部定义的公共事件,只有系统应用和系统服务才能发布,例如HAP安装,更新,卸载等公共事件。
D:无序公共事件:CES转发公共事件时,不考虑订阅者是否接收到,且订阅者接收到的顺序与其订阅顺序有关。
正确答案:ABC
答案解析:暂无
线程模型
HarmonyOS应用中每个进程都会有一个主线程,主线程有如下职责:
- 执行UI绘制;
- 管理主线程的ArkTS引擎实例,使多个UIAbility组件能够运行在其之上;
- 管理其他线程(例如Worker线程)的ArkTS引擎实例,例如启动和终止其他线程;
- 分发交互事件;
- 处理应用代码的回调,包括事件处理和生命周期管理;
- 接收Worker线程发送的消息;
除主线程外,还有一类与主线程并行的独立线程Worker,主要用于执行耗时操作,但不可以直接操作UI。Worker线程在主线程中创建,与主线程相互独立。最多可以创建8个Worker:

基于HarmonyOS的线程模型,不同的业务功能运行在不同的线程上,业务功能的交互就需要线程间通信。线程间通信目前主要有Emitter和Worker两种方式,其中Emitter主要适用于线程间的事件同步, Worker主要用于新开一个线程执行耗时任务。
说明
- Stage模型只提供了主线程和Worker线程,Emitter主要用于主线程和Worker线程、Worker线程和Worker线程之间的事件同步。
- UIAbility组件与UI均在主线程中,他们之间的数据同步请参见UIAbility组件与UI的数据同步。
- 执行hdc shell命令,进入设备的shell命令行。在shell命令行中,执行ps -p <pid> -T命令,可以查看指定应用进程的线程信息。其中,<pid>为需要指定的应用进程的进程ID。
使用Emitter进行线程间通信
Emitter主要提供线程间发送和处理事件的能力,包括对持续订阅事件或单次订阅事件的处理、取消订阅事件、发送事件到事件队列等。
- import emitter from "@ohos.events.emitter";
使用Worker进行线程间通信
Worker是与主线程并行的独立线程。创建Worker的线程被称为宿主线程,Worker工作的线程被称为Worker线程。创建Worker时传入的脚本文件在Worker线程中执行,通常在Worker线程中处理耗时的操作,需要注意的是,Worker中不能直接更新Page。
- 在工程的模块级build-profile.json5文件的buildOption属性中添加配置信息。
- import worker from '@ohos.worker';
FA模型
表1 FA模型开发流程
任务 | 简介 | 相关指导 |
应用组件开发 | 本章节介绍了如何使用FA模型的PageAbility、ServiceAbility、DataAbility以及服务卡片进行应用开发。 | |
了解进程模型 | 本章节介绍了FA模型的进程模型以及几种常用的进程间通信方式。 | |
了解线程模型 | 本章节介绍了FA模型的线程模型以及几种常用的线程间通信方式。 | |
应用配置文件 | 本章节介绍FA模型中应用配置文件的开发要求。 |
进程模型
HarmonyOS的进程模型如下图所示:
- 应用中(同一包名)的所有PageAbility、ServiceAbility、DataAbility、FormAbility运行在同一个独立进程中,即图中绿色部分的“Main Process”。
- WebView拥有独立的渲染进程,即图中黄色部分的“Render Process”。
图1 进程模型示意图

基于HarmonyOS的进程模型,系统提供了公共事件机制用于一对多的通信场景,公共事件发布者可能存在多个订阅者同时接收事件。
线程模型
FA模型下的线程主要有如下三类:
- 主线程
负责管理其他线程
- Ability线程
- 每个Ability一个线程
- 输入事件分发
- UI绘制
- 应用代码回调(事件处理,生命周期)
- 接收Worker发送的消息
- Worker线程
执行耗时操作
基于HarmonyOS的线程模型,不同的业务功能运行在不同的线程上,业务功能的交互就需要线程间通信。线程间通信目前主要有Emitter和Worker两种方式,其中Emitter主要适用于线程间的事件同步, Worker主要用于新开一个线程执行耗时任务。
说明:
FA模型每个ability都有一个独立的线程,Emiter可用于Ability线程内、Ability线程间、Ability线程与Worker线程的事件同步。