文章大纲引言一、Want概述二、Want的类型1、显式Want2、隐式Want3、隐式Want的匹配三、隐式启动Want 源码概述1、有且仅有一个Ability匹配2、有多个Ability 匹配需要弹出选择对话框3、ImplicitStartProcessor::ImplicitStartAbility3.1、GenerateAbilityRequestByAction3.1.1、GetBundleManagerHelper 获取BMS对象3.1.2、GetBundleManagerHelper()-ImplicitQueryInfos3.1.3、ImplicitStartProcessor::FilterAbilityList3.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。匹配到多个满足条件的AbilityUIAbility弹出选择框让用户选择。匹配约束调用方传入的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()-ImplicitQueryInfos3.1.3、ImplicitStartProcessor::FilterAbilityList3.2、定义回调autostartAbilityTask[impshared_from_this(),request,userId,identity](conststd::stringbundle,conststd::stringabilityName)mutable{HILOG_INFO(implicit start ability call back.);IPCSkeleton::SetCallingIdentity(identity);AAFwk::Want targetWantrequest.want;targetWant.SetElementName(bundle,abilityName);autocallBack[imp,targetWant,request,userId]()-int32_t{returnimp-ImplicitStartAbilityInner(targetWant,request,userId);};returnimp-CallStartAbilityInner(userId,targetWant,callBack,request.callType);};3.3、根据dialogAppInfos和deviceType的组合进行不同的分支处理dialogAppInfos.size() 0 (deviceType STR_PHONE || deviceType STR_DEFAULTdialogAppInfos.size() 0 deviceType ! STR_PHONE deviceType ! STR_DEFAULTdialogAppInfos.size() 0 deviceType ! STR_PHONE deviceType ! STR_DEFAULTdeviceType STR_PHONE || deviceType STR_DEFAULTDelayedSingleton::GetInstance()-GetSelectorDialogWant(dialogAppInfos, request.want, request.callerToken)以上四种情况之外的4、当有多个匹配结果时会先执行FilterAbilityList(有条件执行)MatchTypeAndUriAddAbilityInfoToDialogInfos循环从extensionInfos中获取dialogAppInfo信息并存入dialogAppInfos小结弹出对话框的SelectorDialog_Service是一个ServiceExtensionAbility进程为com.ohos.amsdialog连接上Selector_Dialog_Service后会触发其onCreate-OnRequest函数执行createWindow时private asynccreateWindow(name:string,windowType:number,rect){let deviceTypeInfodeviceInfo.deviceType;console.info(TAG,create window);try{winawait window.create(globalThis.selectExtensionContext,name,windowType);if(windowTypewindow.WindowType.TYPE_DIALOG){await win.bindDialogTarget(globalThis.callerToken.value,(){win.destroyWindow();winNum--;if(winNum0){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.deviceTypephone||globalThis.params.deviceTypetablet){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); 的父类实现中默认报异常中断所以需要在子类中实现该函数。但是问题来了里面的细节如何实现呢社区中都是直接返回true2、在不同的设备上弹出的匹配对话框的位置和尺寸大小还需要适配在this.createWindow(‘SelectorDialog’ startId, windowType, navigationBarRect);