鸿蒙进阶——Framework之Want 隐式匹配机制概述

news2025/5/24 16:00:06

文章大纲

引言
一、Want概述
二、Want的类型
- 1、显式Want
- 2、隐式Want
- 3、隐式Want的匹配
三、隐式启动Want 源码概述
- 1、有且仅有一个Ability匹配
- 2、有多个Ability 匹配需要弹出选择对话框
- 3、ImplicitStartProcessor::ImplicitStartAbility
- - - 3.1、GenerateAbilityRequestByAction
    - - 3.1.1、GetBundleManagerHelper 获取BMS对象
      - 3.1.2、GetBundleManagerHelper()->ImplicitQueryInfos
      - 3.1.3、ImplicitStartProcessor::FilterAbilityList
    - 3.2、定义回调
    - 3.3、根据dialogAppInfos和deviceType的组合进行不同的分支处理
  - 4、当有多个匹配结果时会先执行FilterAbilityList(有条件执行)
小结

引言

在Android 中Activity及其他四大组件之间是通过Intent来传递信息的，在我们的鸿蒙操作系统中同样有自己组件的“Intent”，今天我们介绍下鸿蒙中的“Intent”。

暂且对照着Android中的Intent 来理解。

一、Want概述

Want 是对象间信息传递的载体，可以用于应用组件间的信息传递。其使用场景之一是作为startAbility()的参数，包含了指定的启动目标以及启动时需携带的相关数据，如bundleName和abilityName字段分别指明目标Ability所在应用的包名以及对应包内的Ability名称。当UIAbilityA启动UIAbilityB并需要传入一些数据给UIAbilityB时，Want可以作为一个载体将数据传给UIAbilityB。

二、Want的类型

1、显式Want

在启动Ability时指定了abilityName和bundleName的Want称为显式Want。
当有明确处理请求的对象时，通过提供目标Ability所在应用的包名信息（bundleName），并在Want内指定abilityName便可启动目标Ability。显式Want通常用于在当前应用开发中启动某个已知的Ability。

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

在这里插入图片描述

2、隐式Want

当请求处理的对象不明确时，希望在当前应用中使用其他应用提供的某个能力（通过skills标签定义），而不关心提供该能力的具体应用，可以使用隐式Want。例如使用隐式Want描述需要打开一个链接的请求，而不关心通过具体哪个应用打开，系统将匹配声明支持该请求的所有应用。

3、隐式Want的匹配

根据系统中待匹配Ability的匹配情况不同，使用隐式Want启动Ability时会出现以下三种情况。

未匹配到满足条件的Ability：启动失败。
匹配到一个满足条件的Ability：直接启动该Ability。
匹配到多个满足条件的Ability（UIAbility）：弹出选择框让用户选择。

匹配约束：

调用方传入的want参数中不带有abilityName和bundleName，则不允许通过隐式Want启动所有应用的ServiceExtensionAbility。
调用方传入的want参数中带有bundleName，则允许使用startServiceExtensionAbility()方法隐式Want启动ServiceExtensionAbility，默认返回优先级最高的ServiceExtensionAbility，如果优先级相同，返回第一个。

  let wantInfo: Want = {
    deviceId: "",
    action: "ohos.want.action.viewData",
    entities: ['entity.system.videoPlayer'],
    abilityName: "",
    uri: "",
    type: "",
    parameters: {}
  }

在这里插入图片描述

通过上面表格可以除了bundleName和moduleName，只有uri、type、action、entities 字段参与匹配，换句话说提供相应能力的hap中的moudle.json5 里的skills 的这四个字段的值会影响到匹配结果。
在这里插入图片描述

三、隐式启动Want 源码概述

foundation/ability/ability_runtime/services/abilitymgr/src/implicit_start_processor.cpp 处理隐式匹配规则
foundation/ability/ability_runtime/services/abilitymgr/src/system_dialog_scheduler.cpp 弹出模态对话框

1、有且仅有一个Ability匹配

在这里插入图片描述

2、有多个Ability 匹配需要弹出选择对话框

在这里插入图片描述

3、ImplicitStartProcessor::ImplicitStartAbility

对应的代码由ImplicitStartProcessor::ImplicitStartAbility开始处理，首先AbilityRequest的callType = 0，传入的DeviceType为tablet，而社区默认是default。

3.1、GenerateAbilityRequestByAction

传入std::vector dialogAppInfos、deviceType 成功创建AbilityRequest对象，

3.1.1、GetBundleManagerHelper 获取BMS对象

3.1.2、GetBundleManagerHelper()->ImplicitQueryInfos

3.1.3、ImplicitStartProcessor::FilterAbilityList

3.2、定义回调

auto startAbilityTask = [imp = shared_from_this(), request, userId, identity]
    (const std::string& bundle, const std::string& abilityName) mutable {
    HILOG_INFO("implicit start ability call back.");
    IPCSkeleton::SetCallingIdentity(identity);
    AAFwk::Want targetWant = request.want;
    targetWant.SetElementName(bundle, abilityName);
    auto callBack = [imp, targetWant, request, userId]() -> int32_t {
        return imp->ImplicitStartAbilityInner(targetWant, request, userId);
    };
    return imp->CallStartAbilityInner(userId, targetWant, callBack, request.callType);
};

3.3、根据dialogAppInfos和deviceType的组合进行不同的分支处理

dialogAppInfos.size() == 0 && (deviceType == STR_PHONE || deviceType == STR_DEFAULT
dialogAppInfos.size() == 0 && deviceType != STR_PHONE && deviceType != STR_DEFAULT
dialogAppInfos.size() == 0 && deviceType != STR_PHONE && deviceType != STR_DEFAULT
deviceType == STR_PHONE || deviceType == STR_DEFAULT
DelayedSingleton::GetInstance()->GetSelectorDialogWant(dialogAppInfos, request.want, request.callerToken)

以上四种情况之外的

4、当有多个匹配结果时会先执行FilterAbilityList(有条件执行)

MatchTypeAndUri
AddAbilityInfoToDialogInfos
循环从extensionInfos中获取dialogAppInfo信息并存入dialogAppInfos

小结

弹出对话框的SelectorDialog_Service是一个ServiceExtensionAbility，进程为com.ohos.amsdialog，连接上Selector_Dialog_Service后会触发其onCreate->OnRequest函数执行，createWindow时
在这里插入图片描述

  private async createWindow(name: string, windowType: number, rect) {
    let deviceTypeInfo = deviceInfo.deviceType;
    console.info(TAG, 'create window');
    try {
      win = await window.create(globalThis.selectExtensionContext, name, windowType);
      if (windowType === window.WindowType.TYPE_DIALOG) {
        await win.bindDialogTarget(globalThis.callerToken.value, () => {
          win.destroyWindow();
          winNum--;
          if (winNum === 0) {
            globalThis.selectExtensionContext.terminateSelf();
          }
        });
      }
      if (deviceTypeInfo !== 'default') {
        await win.hideNonSystemFloatingWindows(true);
      }
      await win.moveTo(rect.left, rect.top);
      await win.resetSize(rect.width, rect.height);
      if (globalThis.params.deviceType === 'phone' || globalThis.params.deviceType === 'tablet') {
        await win.loadContent('pages/selectorPhoneDialog');
      } else {
        await win.loadContent('pages/selectorPcDialog');
      }
      await win.setBackgroundColor('#00000000');
      await win.show();
    } catch (e) {
      console.error(TAG, 'window create failed: ' + JSON.stringify(e));
    }
  }

然后去触发方舟编译器解包ams_system_dialog.hap执行，
在这里插入图片描述
最终结论：
1、win.hideNonSystemFloatingWindows(true); 的父类实现中默认报异常中断，所以需要在子类中实现该函数。（但是问题来了，里面的细节如何实现呢？社区中都是直接返回true）
2、在不同的设备上弹出的匹配对话框的位置和尺寸大小还需要适配，在
this.createWindow(‘SelectorDialog’ + startId, windowType, navigationBarRect);