OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile

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

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile
成翔

 

OpenAtom OpenHarmony(以下简称“OpenHarmony”)作为分布式操作系统,让多个设备之间能够相互感知,进而整合成一个超级终端。从而实现设备与设备之间取长补短、相互帮助,为用户提供自然流畅的分布式体验。

 

那么超级终端中,设备的能力和状态如何管理?设备之间如何进行信息协同?要回答这些问题,就不得不提我们本期的主角——DeviceProfile。

 

一、什么是DeviceProfile?

超级终端中的设备之间如何能实现取长补短、相互帮助?首先,就必须知道每个设备的能力,以及设备是否在线。对此,OpenHarmony 提出了“设备画像”,也就是通过 DeviceProfile 来记录设备的能力和状态等信息。

 

DeviceProfile 是设备硬件能力和系统软件特征的管理器,记录的典型设备信息有设备类型、设备名称、存储容量、是否折叠屏、有无屏幕、分辨率、设备安全等级、设备 OS 类型、OS 版本号等。

 

(备注:DeviceProfile 支持分布式部署在多个设备上,所以 DeviceProfile 也称为分布式 DeviceProfile)

 

二、DeviceProfile的组成结构

接下来,我们来看看 DeviceProfile 的组成结构。

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile图1 DeviceProfile的组成结构

 

如图 1 所示, DeviceProfile 主要包含以下模块:

ㆍ 数据管理:提供设备信息的插入、删除、查询、同步等数据管理功能;

ㆍ 订阅管理:订阅和取消订阅远端设备的同步完成事件和数据变更事件;

ㆍ 安全管理:管控本地设备 DeviceProfile 的访问权限,保障数据在可信范围内获取。

 

三、DeviceProfile的典型业务流程

分布式 DeviceProfile 基于分布式软总线、分布式数据管理、分布式 Profile 等技术特性,构建统一的设备信息管理机制。支持对设备信息的插入、删除、查询、跨设备同步、同步完成及数据变更事件监听等操作。

 

图 2 展示了两个设备的分布式 DeviceProfile 及其内部业务流程。

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile
图2 分布式DeviceProfile

 

在介绍业务流程之前,先让我们来认识一下图 2 中涉及到的几个模块。

 

ㆍ DP Client 和 CS(Content Sensor)都是 DeviceProfile 一部分。DP Client 是 DeviceProfile 的客户端,其他服务可以通过 DP Client 来调用 DeviceProfile 的接口进行数据同步、数据变更等。CS 负责采集本设备的设备信息;

ㆍ HiChain:设备互信认证服务,管理设备的可信群组;

ㆍ 分布式数据管理服务:DeviceProfile 通过分布式数据管理服务插入、更新、查询、删除及同步设备信息。

 

接下来,我们就来详细介绍分布式 DeviceProfile 的典型业务流程。

 

1. 插入/删除本地设备信息

 

CS 模块定期探测本地设备的能力信息。当设备能力发生变化时,CS 发送给本地 DeviceProfile,本地 DeviceProfile 再通过分布式数据管理服务插入或更新设备信息。

当设备的某项能力很久未使用,本地 DeviceProfile 会通过分布式数据管理服务删除设备信息。

 

设备信息插入的内部流程图如图 3 所示。本地 DeviceProfile 通过 PutDeviceProfile 接口,请求写入一条设备信息记录。如果数据库已经初始化完成,DeviceProfileStorageManager 会直接调用 OnLineSyncTable 的 PutDeviceProfile 写入数据库。如果数据库经初始化未完成,则先将数据写入临时缓存,等初始化完成后再写入数据库,并清理缓存。

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile
图3 设备信息插入流程图

 

2. 跨设备同步设备信息

 

跨设备同步设备信息分为两种场景:

 

(1)设备上线时自动触发同步

 

如图 2,当 Device B 上线时,Device A 的 DeviceProfile 会从分布式软总线收到上线通知。DeviceProfile 的安全管理模块通过与 HiChain 交互,获知 Device B 在可信群组内。此时,自动触发同步,Device A 将自己的设备信息推送给 Device B 实现同步。同样的,Device A 上线时,Device B 也会收到上线通知,触发 Device B 主动推送自己的设备信息给 Device A 实现同步。

 

(2)通过 DP Client 调用接口触发同步

 

系统服务也可以通过 DP Client 调用 SyncDeviceProfile 接口,触发两个设备的分布式数据库的数据同步。

 

跨设备同步设备信息的内部流程如图 4 所示。设备 A 的 DeviceProfile 通过 SyncDeviceProfile 接口发起同步请求,再通过 CheckTrustGroup 接口获取本设备(即设备 A)和需要同步设备(即设备 B)的可信群组信息。如果两个设备的 GroupType 类型为 1(同账号组网)或者 256(点对点无账号组网),并且 Visibility(可见性)为 public,则说明两个设备之间可信。设备 A 将自己的设备信息推送给设备 B。

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile
图4 跨设备同步设备信息

 

3. 查询设备信息

 

跨设备同步设备信息之后,本地设备上除了自己设备的信息,还有远端设备的信息。因而,在本地设备上就可以查询本地和远端设备信息,DeviceProfile 通过 deviceid 来判断是否为远端设备。DeviceProfile 提供的查询接口为 GetDeviceProfile 接口,具体查询流程如图 5 所示。

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile
图5 查询远端设备信息

 

4. 订阅同步完成/数据变更事件

 

DeviceProfile 提供两类事件的订阅和取消订阅功能:

 

ㆍ 同步完成事件

 

跨设备同步设备信息时,支持订阅同步完成事件。比如 Device A 同步 Device B 的设备信息,如果 Device B 订阅了同步完成事件,则同步完成后 Device B 会收到 Device A 发送的同步完成通知。如果 Device B 取消订阅同步完成事件,则后续同步完成后不再收到通知。

 

DeviceProfile 提供的同步完成事件订阅接口为 SubscribeProfileEvent 接口,取消订阅的接口为 UnsubscribeProfileEvent 接口。

 

ㆍ 数据变更事件

 

DeviceProfile 支持远程订阅数据变更事件,比如,Device B 可以订阅 Device A 的数据变更事件。当 Device A 的数据发生变更,Device B 会收到数据变更通知。如果 Device B 取消订阅数据变更事件,则后续不再收到数据变更通知。

 

DeviceProfile 提供的数据变更事件订阅接口为 SubscribeProfileChange 接口,取消订阅的接口为 SubscribeProfileChange 接口。

 

同步完成事件、数据变更事件的订阅流程相似。图 6 展示了同步完成事件的订阅流程。

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile
图6 同步完成事件的订阅流程

 

四、结束语

本期我们介绍了 DeviceProfile 的概念、组成和典型的业务流程。你是否已经了解了呢?

 

还想深入了解的开发者,可以参考以下链接查看 DeviceProfile 的实现代码和介绍:https://gitee.com/openharmony/device_profile_core

 

 

OpenHarmony 3.1 Beta版本关键特性解析——分布式DeviceProfile

举报
发表评论

相关文章

当前内容话题
  • 0