OpenHarmony 3.1 Beta 版本关键特性解析——探秘隐式查询

2022-03-22 18:43:16

（以下内容来自开发者分享，不代表 OpenHarmony 项目群工作委员会观点）

徐浩

隐式查询是 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（不可以为空），匹配通过。否则匹配不通过。

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

典型隐式查询匹配示例

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

示例一：

查询方应用的 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/query/student，与 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/query/student，与 want 信息中的 uri 一致，uri 匹配通过。
skills 信息中的 type 为 text/*（*表示通配），want 信息中的 type 为 text/plain，type 匹配通过。

此示例，四个属性均匹配成功，则此应用匹配成功，会被应用选择器展示给用户进行选择。
通过以上示例，相信大家已经清楚隐式查询匹配规则了。
全文介绍了隐式查询是什么，并对隐式查询的相关代码和匹配规则进行了深入剖析。隐式查询，你都 get 到了吗？希望开发者们可以将隐式查询应用于更多的场景和领域中。