共计 2808 个字符，预计需要花费 8 分钟才能阅读完成。
分布式能力作为 OpenHarmony 操作系统的要害能力，始终备受关注，同时它也是开源社区能力构建的重点。在 3 月底公布的 OpenHarmony v3.1 Release 版本中，媒体子系统新增了两个分布式能力：分布式媒体库 和分布式相机。本期就带大家一起来理解这两个新增的分布式能力~
一、万物互联带给多媒体框架的挑战
现在咱们在生活中曾经被越来越多的电子设备所突围。这些设施有不同的性能（音箱、大屏、摄像头、冰箱等）、不同的交互界面（语音、触屏、红外遥控等），给人们提供了足够便当的同时，却给开发者带来了微小的挑战：
- 设施的硬件和性能差别微小。
这就导致了各产品利用间存在人造的隔离，要实现设施之间的多媒体互通互助也困难重重。如何屏蔽设施间的差别，提供绝对统一的多媒体能力接口？
- 随着各种外围电子设备的减少，各设施间的连贯网络也变得更加简单。
试想一下：当你须要在蓝牙音箱上播放电视的音频时，你不得不用遥控器在电视的菜单中进行繁琐的设置；当你想将声音切换到蓝牙耳机时，又不得不从新实现繁琐的设置操作。这样感觉是人在服务于这些设施，而不是设施服务于人。随着更多的电子设备进入人们的生存，简单的硬件环境带给人们的简单操作会越来越多。如何在人们须要的时候给出最佳的组网形式，并且可能实现媒体数据传输的最佳路由？
- 在全屋智能化的明天，“丰盛的利用场景”层出不穷。
每个繁多设施可能只有一个性能，比方：体脂秤、摄像头、投影仪等，然而用户的利用场景却大多汇合了多种性能。如何让不同的设施组织起来，独特给用户提供一个残缺的媒体性能？
如何解决下面这些问题呢？这就须要构建一个人造反对分布式的操作系统。OpenHarmony 在初始设计阶段就将焦点放在如何实现分布式能力下面，这使它人造具备分布式个性，可能轻松实现设施间的硬件互助、数据共享、服务迁徙，同时使利用轻松接入分布式能力，给用户提供顺畅的跨设施交互体验。
上面咱们要介绍的两个分布式能力——分布式媒体库和分布式相机，别离用于撑持媒体库和相机的分布式场景，为用户提供跨设施的多媒体交互体验。
二、分布式媒体库
上面从框架图和 API 接口的应用两个方面，为大家介绍分布式媒体库。
1. 框架图
分布式媒体库的框架图如下：
图 1 分布式媒体库框架图
分布式媒体库次要由以下两局部组成：
● MediaLibrary JS API：通过 JS API 接口向应用层提供媒体文件的治理和操作的能力。
● MediaLibraryDataAbility：通过 SyncTable、RDB Utils、File Utils 功能模块，与媒体子系统内部的分布式数据库和分布式文件系统交互，从而取得对分布式数据的增删改查能力。
2. API 接口的应用
开发者次要通过 JS API 接口来应用分布式媒体库能力。上面通过两个典型操作来解说如何应用分布式媒体库的 JS API 接口：
（1）获取设施的 networkId
通过 getActivePeers()接口能够获取以后组网中所有可拜访的设施。获取到的 PeerInfo 信息中蕴含一个 networkId 参数，以此作为分布式数据库拜访的要害参数，来辨别要拜访的设施。
（2）应用 networkId 进行数据操作
MediaFetchOptions 提供对媒体库进行拜访操作的参数汇合，其中的 networkId 参数会追随 MediaFetchOptions 一起通过 getFileAssets()接口下发给媒体库服务接口，并且依此来拜访对应设施上的数据。
更多的接口详情，请从码云 OpenHarmony 我的项目的媒体库 JS API 申明文件中获取。
https://gitee.com/openharmony…
上面咱们从零碎相册利用的实现代码中抽取几个要害的代码段，看看利用拜访分布式媒体库的操作流程：
零碎相册利用的残缺代码及开发阐明，从码云 OpenHarmony 我的项目中获取。
https://gitee.com/openharmony…
三、分布式相机
上面从框架图和 API 接口的阐明两个方面，为大家介绍分布式相机。
1. 框架图
分布式相机的框架图如下：
图 2 分布式相机框架图
从图 2 中能够看出，分布式相机框架（Distributed Hardware）分为主控端和被控端。设施 B 领有本地相机设施，分布式组网中的设施 A 能够分布式调用设施 B 的相机设施。这种场景下，设施 A 是主控端，设施 B 是被控端，两个设施通过软总线进行交互。VirtualCameraHAL 作为硬件适配层（HAL）的一部分，负责和分布式相机框架中的主控端交互，将主控端 CameraFramwork 下发的指令传输给分布式相机框架的 SourceMgr 解决。SourceMgr 则通过软总线将管制信息传递给被控端的 CameraClient，CameraClient 间接通过调用被控端 CameraFramwork 的接口来实现对设施 B 相机的管制。从设施 B 反馈的预览图像数据会通过分布式相机框架的 ChannelSink 回传到设施 A 的 HAL 层，进而反馈给利用。通过这种形式，设施 A 的利用就能够像应用本地设施一样应用设施 B 的相机。
2. API 接口的应用
开发者次要通过 JS API 接口来应用分布式相机能力。上面通过两个典型操作来解说如何应用分布式相机的 JS API 接口：
（1）获取可用的相机设施
通过 getCameras()接口能够取得以后组网中所有可用的相机设施（包含分布式相机设施）。在获取到的 Camera 信息中，有两个参数须要关注：
● cameraId：相机设施的惟一标识。
● connectionType：相机设施的连贯类型。当参数值为 CAMERA_CONNECTION_REMOTE 时，示意此相机设施为分布式相机设施。
（阐明：在分布式相机的 JS API 中，所有的接口都是本地相机设施和分布式相机设施共用的，接口通过参数 cameraId 来指定执行操作的相机设施。）
（2）创立相机设施输出流
createCameraInput()接口为创立相机设施输出流的接口，其中 cameraId 参数用于辨别关上哪个相机设施。如果传入的是一个无效的分布式相机的 cameraId，则主动会触发分布式相机个性。
更多的接口详情，请从码云 OpenHarmony 我的项目 Camera JS API 申明文件中获取。
https://gitee.com/openharmony…
上面咱们从零碎相机利用的实现代码中抽取几个要害的代码段，看看利用拜访分布式相机的操作流程：
零碎相机利用的残缺代码，请从从码云 OpenHarmony 我的项目中获取。
https://gitee.com/openharmony…
四、结束语
从凋谢的代码能够看出，以后构建的多媒体分布式能力还比拟根底，局部分布式能力接口也还没有向三方利用凋谢。咱们会持续致力，心愿在下个版本上，分布式能力能扩大到音频、播控等更多个性，为大家提供更加丰盛的分布式多媒体体验。
OpenHarmony，加油吧！