乐趣区

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

jiezi

本文作者：徐浩

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

  1. entities 匹配规定

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

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

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

  1. 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 匹配通过。否则匹配不通过。

  1. 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 到了吗？心愿开发者们能够将隐式查问利用于更多的场景和畛域中。

退出移动版