关于openharmony:OpenHarmony-31-Beta版本关键特性解析探秘隐式查询

本文作者：徐浩

隐式查问是 OpenAtom OpenHarmony（以下简称“OpenHarmony”）的一个根底能力，被广泛应用于各种利用中（如视频播放、阅读器播放等）。利用通过隐式查问能够借助其余利用提供的能力，从而缩小开发者工作量，同时给用户带来更好的体验。那么隐式查问是什么？隐式查问是如何实现的？等等一连串疑难想必是开发者们最关怀的问题，本期将对这些问题进行具体的解答。

什么是隐式查问？

当一个利用执行某操作时，如果利用本人不具备此操作须要的能力，则会触发零碎的隐式查问性能。零碎去查找其余具备此项能力的利用，并通过利用选择器展现给用户，让用户抉择应用哪个利用来实现操作。

为了帮忙大家了解，咱们来举个例子：

在微信中关上 pdf 文件时， 如果没有设置默认的 pdf 文件阅读器，那么零碎会通过隐式查问查找所有具备 pdf 浏览能力的利用，并通过利用选择器将其展现给用户进行抉择。

隐式查问代码解析

从下面隐式查问的定义，咱们理解到：

1. 查问方利用须要执行要执行的操作。
2. 其余利用须要申明本人具备的能力。

上面咱们联合示例，看看具体的代码实现吧。

第一步：在查问方利用的 Ability 中通过 want 信息指定要执行的操作。

want 信息示例代码如下：

"want"{       "action":"action.system.play",       "entities":["entity.system.video", "entity.system.camera"],       "uri" :"https://www.test.com:8080/query/student/name",       "type":"text/plain"   }

当利用调用 startAbility 接口启动 Ability 时，通过 want 信息中的 action、entities、uri 和 type 属性指定要执行的操作。

第二步：在其余利用的配置文件 config.json 中通过 skills 参数申明具备的能力。

skills 信息示例代码如下：

"skills": [     {       "actions": ["action.system.play"],       "entities": ["entity.system.video", "entity.system.camera"],       "uris": [         {           "scheme": "https",           "host": "www.test.com",           "port": "8080",           "path": "query/student/name",            "pathStartWith":"query/student",           "pathRegex":"query/.*/name",          "type": "text/plain"         }       ]     }   ]

实现下面两步，零碎就能够进行隐式查问了。零碎依照隐式查问规定，将其余利用的 skills 信息与查问方利用的 want 信息进行匹配，而后将匹配胜利的利用通过利用选择器展现给用户进行抉择。

上面咱们为大家具体解说隐式查问的匹配规定。

隐式查问匹配规定详解

零碎将其余利用的 skills 信息（蕴含 actions、entities 和 uris 属性）与查问方利用的 want 信息（蕴含 action、entities、uri 和 type 属性）进行匹配，具体匹配规定如下：

1. action 匹配规定

将其余利用 skills 信息中的 actions 与查问方利用 want 信息中的 action 进行匹配。

• 如果 skills 信息中的 actions 为空，匹配不通过。

• 如果 skills 信息中的 actions 不为空，且其蕴含 want 信息中的 action（能够为空），匹配通过。否则匹配不通过。

2. entities 匹配规定

将其余利用 skills 信息中的 entities 与查问方利用 want 信息中的 entities 进行匹配。

• 如果 skills 信息中的 entities 为空，则只有当 want 信息中的 entities 为空时才匹配通过。否则匹配不通过。

• 如果 skills 信息中的 entities 不为空，且其蕴含 want 信息中的 entities（能够为空），匹配通过。否则匹配不通过。

3. uri 匹配规定

将其余利用 skills 信息的 uris 中的 scheme、host、port、path、pathStartWith 和 pathRegex 属性拼接成 uri（scheme://host:port/(path;pathStartWith;pathRegex)），将此 uri 与查问方利用 want 信息中的 uri 进行匹配。其中，path 为残缺门路匹配，pathStartWith 为前缀匹配，pathRegx 为正则匹配。

skills 信息的 uris 中的 type 与 want 信息中的 type 进行匹配，反对*通配符匹配。

• 如果 skills 信息拼接的 uri 为空，则只有当 want 信息中的 uri 为空时才匹配通过。否则匹配不通过。

• 如果 skills 信息拼接的 uri 不为空，且其蕴含 want 信息中的 uri（不能够为空），uri 匹配通过。否则匹配不通过。

4. type 匹配规定

将其余利用 skills 信息的 uris 中的 type 与查问方利用 want 信息中的 type 进行匹配，反对*通配符匹配。

• 如果 skills 信息中的 type 为空，则只有当 want 信息中的 type 为空时才匹配通过。否则匹配不通过。

• 如果 skills 信息中的 type 不为空，且其蕴含 want 信息中的 type（不能够为空），匹配通过。否则匹配不通过。

当利用的以上四个属性都匹配通过，此利用才会被利用选择器展现给用户进行抉择。

典型隐式查问匹配示例

为了让大家更好地了解，上面咱们看看几个典型的匹配示例：

示例1：
查问方利用的 want 信息示例代码：

featureAbility.startAbility({     "want": {       "action": "action.system.play"     }, }).then((data) => {})

其余利用的 skills 信息示例代码：

  "skills": [        {          "actions": ["action.system.play"]        }      ] 

• skills 信息中的 actions 不为空，且其蕴含 want 信息中的 action，action 匹配通过。
• skills 信息中的 entities 为空，want 信息中的 entities 也为空，entities 匹配通过。同理，uri 和 type 也匹配通过。
此示例，四个属性均匹配胜利，则此利用匹配胜利，会被利用选择器展现给用户进行抉择。

示例二：
查问方利用的 want 信息示例代码：

featureAbility.startAbility({     "want": {       "type": "prefixType/suffixType",     }, }).then((data) => {}) 

其余利用的 skills 信息示例代码：

  "skills": [      {         "actions": ["action.system.play"],      "uris": [          {            "type": "prefixType/suffixType"          }        ]      }    ]

• skills 信息中的 actions 不为空， want 信息中的 action 为空，action 匹配通过。
• skills 信息中的 entities 为空，want 信息中的 entities 也为空，entities 匹配通过。同理，uri 也匹配通过。
• skills 信息中的 type 不为空，且其蕴含 want 信息中的 type，type 匹配通过。
此示例，四个属性均匹配胜利，则此利用匹配胜利，会被利用选择器展现给用户进行抉择。

示例三：
查问方利用的 want 信息示例代码：

featureAbility.startAbility({    "want": {      "type": "text/plain",      "uri": "https://www.test.com:8080/query/student"    }, }).then((data) => {})  

其余利用的 skills 信息示例代码：

"skills": [     {        "actions": ["action.system.play"],     "uris": [         {           "scheme": "https",           "host": "www.test.com",           "port": "8080",           "path": "query/student",           "type": "text/*"         }       ]     }  

• skills 信息中的 actions 不为空， want 信息中的 action 为空，action 匹配通过。
• skills 信息中的 entities 为空，want 信息中的 entities 也为空，entities 匹配通过。
• skills 信息的 uris 中 scheme、host、port 和 path 属性拼接出 uri 为 https://www.test.com:8080/que...，与 want 信息中的 uri 统一，uri 匹配通过。
• skills 信息中的 type 为 text/（示意通配），want 信息中的 type 为 text/plain，type 匹配通过。
此示例，四个属性均匹配胜利，则此利用匹配胜利，会被利用选择器展现给用户进行抉择。

示例四：
查问方利用的 want 信息示例代码：

featureAbility.startAbility({    "want": {      "action": "action.system.play",      "entities":["entity.system.video"],      "type": "text/plain",      "uri": "https://www.test.com/query/student"    }, }).then((data) => {}) 

其余利用的 skills 信息示例代码：

"skills": [     {       "actions": ["action.system.play"],       "entities": ["entity.system.video"],       "uris": [         {           "scheme": "https",           "host": "www.test.com",           "pathStartWith": "query",           "type": "text/plain"         }       ]     }   ]

• skills 信息中的 actions 不为空， want 信息中的 action 为空，action 匹配通过。
• skills 信息中的 entities 为空，want 信息中的 entities 也为空，entities 匹配通过。
• skills 信息的 uris 中 scheme、host、port 和 path 属性拼接出 uri 为 https://www.test.com:8080/que...，与 want 信息中的 uri 统一，uri 匹配通过。
• skills 信息中的 type 为 text/（示意通配），want 信息中的 type 为 text/plain，type 匹配通过。
此示例，四个属性均匹配胜利，则此利用匹配胜利，会被利用选择器展现给用户进行抉择。
通过以上示例，置信大家曾经分明隐式查问匹配规定了。
全文介绍了隐式查问是什么，并对隐式查问的相干代码和匹配规定进行了深刻分析。隐式查问，你都 get 到了吗？心愿开发者们能够将隐式查问利用于更多的场景和畛域中。