前提：基于官网3.1/4.0文档。参考官网文档
基于Android开发体系来进行比较和思考。（或有偏颇，自行斟酌）
一、 AbilityStage
1.概念
AbilityStage是一个Module级别的组件容器，应用的HAP在首次加载时会创建一个AbilityStage实例，可以对该Module进行初始化等操作。
AbilityStage与Module一一对应，即一个Module拥有一个AbilityStage。
类同Application
2.功能与使用
1. 配置
module.json5中：
{
"module": {
"name": "entry",
"type": "entry",
"srcEntry": "./ets/myabilitystage/MyAbilityStage.ts",
...
}
}
2.使用
import AbilityStage from '@ohos.app.ability.AbilityStage';
export default class MyAbilityStage extends AbilityStage {
onCreate() {
// 应用的HAP在首次加载的时，为该Module初始化操作
}
onAcceptWant(want) {
// 仅specified模式下触发
return "MyAbilityStage";
}
}
- onCreate()生命周期回调：在开始加载对应Module的第一个UIAbility实例之前会先创建AbilityStage，并在AbilityStage创建完成之后执行其
onCreate()生命周期回调。AbilityStage模块提供在Module加载的时候，通知开发者，可以在此进行该Module的初始化（如资源预加载，线程创建等）能力。- onAcceptWant()事件回调：UIAbility指定实例模式（specified）启动时候触发的事件回调，具体使用请参见UIAbility启动模式综述。
- onConfigurationUpdated()事件回调：当系统全局配置发生变更时触发的事件，系统语言、深浅色等，配置项目前均定义在Configuration类中。
- onMemoryLevel()事件回调：当系统调整内存时触发的事件。
二、Context
1.概念
2.功能与使用
与Android类似。
三、Want
1.概念
Want是对象间信息传递的载体，可以用于应用组件间的信息传递。其使用场景之一是作为startAbility()的参数，包含了指定的启动目标以及启动时需携带的相关数据，如bundleName和abilityName字段分别指明目标Ability所在应用的包名以及对应包内的Ability名称。当UIAbilityA启动UIAbilityB并需要传入一些数据给UIAbilityB时，Want可以作为一个载体将数据传给UIAbilityB。
类似Android中的Bundle。
2.功能与使用
1.显式与隐式规则
传递的数据包含参数:
deviceId、bundleName、moduleName、abilityName、uri、type、action、entities、flags、parameters。
其中abilityName指定了值则为显式规则，否则为隐式规则。
匹配规则偏向于正则表达式匹配规则、包含关系。
2.action与entities
action
表示调用方要执行的通用操作（如查看、分享、应用详情）
ACTION_HOME：启动应用入口组件的动作，需要和ENTITY_HOME配合使用；
ACTION_CHOOSE：选择本地资源数据，例如联系人、相册等；
ACTION_VIEW_DATA：查看数据，当使用网址uri时，则表示显示该网址对应的内容。
ACTION_VIEW_MULTIPLE_DATA：发送多个数据记录的操作
entities
表示目标Ability的类别信息（如浏览器、视频播放器），在隐式Want中是对action的补充。在隐式Want中，开发者可定义该字段，来过滤匹配应用的类别，例如必须是浏览器。在Want内声明entities字段表示希望被调用方应用属于声明的类别。在被调用方应用配置文件skills字段内声明entites表示该应用支持的类别。
ENTITY_DEFAULT：默认类别无实际意义。
ENTITY_HOME：主屏幕有图标点击入口类别。
ENTITY_BROWSABLE：指示浏览器类别。
action ->action
entities -> intent-filter?
3.案例
1.显式跳转
import common from '@ohos.app.ability.common';
// ...
async explicitStartAbility() {
try {
// Explicit want with abilityName specified.
let want = {
deviceId: "",
bundleName: "com.example.myapplication",
abilityName: "calleeAbility"
};
let context = getContext(this) as common.UIAbilityContext;
await context.startAbility(want);
console.info(`explicit start ability succeed`);
} catch (error) {
console.info(`explicit start ability failed with ${error.code}`);
}
}
// ...
注意这里对调用方法使用了async和await。归根到底应该是使用了await导致整个方法是async。 startAbility是异步的的好理解，但是为什么要单独加上那个await修饰符呢？
2.隐式跳转
1.被调用放设置
"skills": [
{
"entities": [
"entity.system.browsable"
// ...
],
"actions": [
"ohos.want.action.viewData"
// ...
],
"uris": [
{
"scheme": "https",
"host": "www.test.com",
"port": "8080",
// prefix matching
"pathStartWith": "query",
"type": "text/*"
},
{
"scheme": "http",
// ...
}
// ...
]
},
]
- 调用方调用
async implicitStartAbility() {
try {
let want = {
// uncomment line below if wish to implicitly query only in the specific bundle.
// bundleName: "com.example.myapplication",
"action": "ohos.want.action.viewData",
// entities can be omitted.
"entities": [ "entity.system.browsable" ],
"uri": "https://www.test.com:8080/query/student",
"type": "text/plain"
}
let context = getContext(this) as common.UIAbilityContext;
await context.startAbility(want)
console.info(`explicit start ability succeed`)
} catch (error) {
console.info(`explicit start ability failed with ${error.code}`)
}
}
匹配规则为链式，顺序为：action->entities->urls->type，满足前序条件才能进行到后续匹配。
四、总结
AbilityStage->Application
Context->Contenxt
Want->Bundle
