1 概述

上一章节我们学习了UIAbility组件【鸿蒙开发】第十一章 Stage模型应用组件-UIAbility，其中组件间的交互传递信息的媒介就是Want，本章节我们来更加深入学习Want的相关知识。
Want是一种对象，用于在应用组件之间传递信息。

2 类型

1. 显式Want：在启动目标应用组件时，调用方传入的want参数中指定了abilityName和bundleName，称为显式Want。
2. 隐式Want：在启动目标应用组件时，调用方传入的want参数中未指定abilityName，称为隐式Want。

import Want from '@ohos.app.ability.Want';

// 1. 显式Want
let wantInfo: Want = {
  deviceId: '', // deviceId为空表示本设备
  bundleName: 'com.example.myapplication',
  abilityName: 'FuncAbility',
}

// 2. 隐式Want
let wantInfo: Want = {
  // uncomment line below if wish to implicitly query only in the specific bundle.
  // bundleName: 'com.example.myapplication',
  action: 'ohos.want.action.search',
  // entities can be omitted
  entities: [ 'entity.system.browsable' ],
  uri: 'https://www.test.com:8080/query/student',
  type: 'text/plain',
};

3 匹配规则

调用方传入的want参数中设置的参数如何与目标应用组件声明的配置文件进行匹配

1. 调用方传入的want参数，表明调用方需要执行的操作，并提供相关数据以及其他应用类型限制。
2. 待匹配应用组件的skills配置，声明其具备的能力（module.json5配置文件中的skills标签参数）。

系统将调用方传入的want参数（包含action、entities、uri和type属性）与已安装待匹配应用组件的skills配置（包含actions、entities、uris和type属性）依次进行匹配。当四个属性匹配均通过，则此应用才会被应用选择器展示给用户进行选择。

3.1 want参数的action匹配规则

3.2 want参数的entities匹配规则

3.3 want参数的uri和type匹配规则

调用方传入的want参数中设置uri和type参数发起启动应用组件的请求，系统会遍历当前系统已安装的组件列表，并逐个匹配待匹配应用组件的skills配置中的uris数组，如果待匹配应用组件的skills配置中的uris数组中只要有一个可以匹配调用方传入的want参数中设置的uri和type即为匹配成功。

为了简化描述：

1. 称调用方传入的want参数中的uri参数为w_uri；待匹配应用组件的skills配置中uri为s_uri，其中每个元素为s_uri。
2. 称调用方传入的want参数的type参数为w_type，待匹配应用组件的skills数组中uris的type数据为s_type。
   

3.4 uri匹配规则

具体的匹配规则如下：

1. 如果s_uri的scheme为空，当w_uri为空时匹配成功，否则匹配失败。
2. 如果s_uri的host为空，当w_uri和s_uri的scheme相同时匹配成功，否则匹配失败。
3. 如果s_uri的port为空，当w_uri和s_uri中的scheme和host相同时匹配成功，否则匹配失败。
4. 如果s_uri的path、pathStartWith和pathRegex都为空，当w_uri和s_uri中的scheme，host和port相同时匹配成功，否则匹配失败。
5. 如果s_uri的path不为空，当w_uri和s_uri全路径表达式相同时匹配成功，否则继续进行pathStartWith的匹配。
6. 如果s_uri的pathStartWith不为空，当w_uri包含s_uri前缀表达式时匹配成功，否则继续进行pathRegex的匹配。
7. 如果s_uri的pathRegex不为空，当w_uri满足uri正则表达式时匹配成功，否则匹配失败。

说明：
待匹配应用组件的skills配置的uris中scheme、host、port、path、pathStartWith和pathRegex属性拼接，如果依次声明了path、pathStartWith和pathRegex属性时，uris将分别拼接为如下三种表达式：

1. 前缀uri表达式：当配置文件只配置scheme，或者只配置scheme和host，或者只配置scheme，host和port时，参数传入以配置文件为前缀的Uri

	scheme://
	scheme://host
	scheme://host:port

2. 全路径表达式：scheme://host:port/path
3. 前缀表达式：scheme://host:port/pathStartWith
4. 正则表达式：scheme://host:port/pathRegex

3.5 type匹配规则

type匹配规则的适用性需建立在want参数内type不为空的基础上。当want参数内type为空时请参见want参数的uri和type匹配规则。

具体的匹配规则如下：

1. 如果s_type为空，则匹配失败。
2. 如果s_type或者w_type为通配符*/*，则匹配成功。
3. 如果s_type最后一个字符为通配符*，如prefixType/*，则当w_type包含prefixType/时匹配成功，否则匹配失败。
4. 如果w_type最后一个字符为通配符*，如prefixType/*，则当s_type包含prefixType/时匹配成功，否则匹配失败。

4 action与entities

4.1 action

action：表示调用方要执行的通用操作（如查看、分享、应用详情）。在隐式Want中，您可定义该字段，配合uri或parameters来表示对数据要执行的操作。如打开，查看该uri数据。例如，当uri为一段网址，action为ohos.want.action.viewData则表示匹配可查看该网址的应用组件。在Want内声明action字段表示希望被调用方应用支持声明的操作。在被调用方应用配置文件skills字段内声明actions表示该应用支持声明操作。

1. ACTION_HOME：启动应用入口组件的动作，需要和ENTITY_HOME配合使用；系统桌面应用图标就是显式的入口组件，点击也是启动入口组件；入口组件可以配置多个。
2. ACTION_CHOOSE：选择本地资源数据，例如联系人、相册等；系统一般对不同类型的数据有对应的Picker应用，例如联系人和图库。
3. ACTION_VIEW_DATA：查看数据，当使用网址uri时，则表示显示该网址对应的内容。
4. ACTION_VIEW_MULTIPLE_DATA：发送多个数据记录的操作。

4.2 entities

entities：表示目标应用组件的类别信息（如浏览器、视频播放器），在隐式Want中是对action的补充。在隐式Want中，开发者可定义该字段，来过滤匹配应用的类别，例如必须是浏览器。在Want内声明entities字段表示希望被调用方应用属于声明的类别。在被调用方应用配置文件skills字段内声明entites表示该应用支持的类别。

1. ENTITY_DEFAULT：默认类别无实际意义。
2. ENTITY_HOME：主屏幕有图标点击入口类别。
3. ENTITY_BROWSABLE：指示浏览器类别。

参考文献：
[1]OpenHarmoney应用开发文档