HarmonyOS 第2章 Ability的开发，鸿蒙HarmonyOS 应用开发入门

第2章 Ability的开发
本章内容
本章介绍HarmonyOS的核心组件Ability的开发。
2.1 Ability概述
2.2 FA模型介绍
2.3 Stage模型介绍
2.4 Ability内页面的跳转和数据传递
2.5 Want概述
2.6 实战：显式Want启动Ability
2.7 实战：隐式Want打开应用管理
2.8 小结
2.9 习题
2.1 Ability概述
Ability翻译成中文就是“能力”的意思。在HarmonyOS中，Ability是应用所具备能力的抽象，也是应用程序的重要组成部分。

2.1.1 单Ability应用和多Ability应用
2.1.2 HarmonyOS应用模型
2.1.1 单Ability应用和多Ability应用

一个应用可以具备多种能力，也就是说可以包含多个Ability。HarmonyOS支持应用以Ability为单位进行部署。

2.1.2 HarmonyOS应用模型

HarmonyOS应用模型的构成要素
应用组件
应用进程模型
应用线程模型
应用任务管理模型
应用配置文件
截至目前，在HarmonyOS中，Ability框架模型结构具有以下两种形态:
FA模型：API 8及更早版本的应用程序只能使用FA模型进行开发。
Stage模型：从API 9开始，Ability框架引入并支持使用Stage模型进行开发，也是目前HarmonyOS所推荐的开发方式。
FA模型和Stage模型的工程目录结构存在差异，Stage模型目前只支持使用ArkTS语言进行开发。本书示例也是采用Stage模型开发的。

2.2 FA模型介绍

FA（Feature Ability）模型是HarmonyOS早期版本（API 8及更早版本）开始支持的模型，目前已经不再主推。

2.2.1 FA模型中的Ability

FA模型中的Ability分为PageAbility、ServiceAbility、DataAbility、FormAbility四种类型。其中：
PageAbility是具备UI实现的Ability，是用户具体可见并可以交互的Ability实例。
ServiceAbility也是Ability的一种，但是没有UI，为其他Ability提供调用自定义的服务，在后台运行。
DataAbility也是没有UI的Ability，为其他Ability提供进行数据增、删、查的服务，在后台运行。
FormAbility是卡片Ability，是一种界面展示形式。
2.2.2 FA模型的生命周期

2.2.3 FA模型的进程线程模型

2.3 Stage模型介绍
Stage模型是HarmonyOS 3.1版本开始新增的模型，也是目前HarmonyOS主推且会长期演进的模型。在该模型中，由于提供了AbilityStage、WindowStage等类作为应用组件和Window窗口的“舞台”，因此称这种应用模型为Stage模型。
本节主要介绍以Stage模型为主的开发方式。
2.3.1 Stage模型的设计思想
2.3.2 Stage模型的Ability生命周期
2.3.3 Stage模型的Ability启动模式
2.3.1 Stage模型的设计思想
Stage模型的设计基于如下3个出发点：
为复杂应用而设计
支持多设备和多窗口形态
平衡应用能力和系统管控成本
2.3.2 Stage模型的Ability生命周期
Ability的生命周期包括Create、Foreground、Background、Destroy四个状态，WindowStageCreate和WindowStageDestroy为窗口管理器（WindowStage）在Ability中管理UI界面功能的两个生命周期回调，从而实现Ability与窗口之间的弱耦合

2.3.3 Stage模型的Ability启动模式
Ability的启动模式是指Ability实例在启动时的不同呈现状态。针对不同的业务场景，系统提供了3种启动模式：
singleton（单实例模式）。
standard（标准实例模式）。
specified（指定实例模式）。

singleton启动模式
每次调用startAbility()方法时，如果应用进程中该类型的Ability实例已经存在，则复用系统中的Ability实例。系统中只存在唯一一个该Ability实例，即在最近任务列表中只存在一个该类型的Ability实例。此时，应用的Ability实例已创建，当再次调用startAbility()方法启动该Ability实例时，只会进入该Ability的onNewWant()回调，不会进入其onCreate()和onWindowStageCreate()生命周期回调。
如果需要使用singleton启动模式，将module.json5配置文件中的"launchType"字段配置为"singleton’'即可。

{"module": {..."abilities": [{"launchType": "singleton",...}]}
}

standard启动模式
在standard启动模式下，每次调用startAbility()方法时，都会在应用进程中创建一个新的该类型的Ability实例，即在最近任务列表中可以看到有多个该类型的Ability实例。这种情况下，可以将Ability配置为standard。
如果需要使用standard启动模式，将module.json5配置文件中的"launchType"字段配置为"standard"即可。
在specified启动模式下，在Ability实例创建之前，允许开发者为该实例创建一个唯一的字符串Key，创建的Ability实例绑定Key之后，后续每次调用startAbility()方法时，都会询问应用使用哪个Key对应的Ability实例来响应startAbility请求。运行时由Ability内部业务决定是否创建多个实例，如果匹配有该Ability实例的Key，则直接拉起与之绑定的Ability实例，否则创建一个新的Ability实例。
例如，用户在应用中重复打开同一个文档时，启动的均是最近任务列表中的同一个任务，以及在应用中重复新建文档时，启动的均是最近任务列表中的新任务。这种情况下，可以将Ability配置为specified。当再次调用startAbility()方法启动该Ability实例，且AbilityStage的onAcceptWant()回调匹配到一个已创建的Ability实例时，再次启动该Ability，只会进入该Ability的onNewWant()回调，不会进入其onCreate()和onWindowStageCreate()生命周期回调。
如果需要使用specified启动模式，将module.json5配置文件的"launchType"字段配置为"specified"即可。

2.4 Ability内页面的跳转和数据传递
Ability的数据传递包括Ability内页面的跳转和数据传递、Ability间的数据跳转和数据传递。本节主要讲解Ability内页面的跳转和数据传递。
2.4.1 新建Ability内页面
2.4.2 页面跳转及传参
2.4.3 参数接收
2.4.4 运行
2.4.1 新建Ability内页面
初始化工程之后，会生成以下内容：
在src/main/ets/entryability目录下，初始会生成一个Ability文件EntryAbility.ts。可以在EntryAbility.ts文件中根据业务需要实现Ability的生命周期回调内容。
在src/main/ets/pages目录下，会生成一个Index页面。这也是基于Ability实现的应用的入口页面。可以在Index页面中根据业务需要实现入口页面的功能。
为了实现页面的跳转和数据传递，需要新建一个页面。在src/main/ets/pages目录下，可以通过右击New→Page来新建页面

在原有Index页面的基础上，新建一个名为Second的页面

Second页面创建完成之后，会自动做两个动作。一个动作是在src/main/ets/pages目录

下创建一个Second.ets文件。Second.ets文件内容如下：

@Entry
@Component
struct Second {@State message: string = 'Hello World'build() {Row() {Column(