HarmonyOS鸿蒙Next分布式协同演奏技术实现路线(Java)
HarmonyOS鸿蒙Next分布式协同演奏技术实现路线(Java) 一、写在前面的话
分布式能力是鸿蒙的一大亮点,不管是分布式数据库,还是分布式文件管理,抑或是分布式任务流转,都给我们日常的使用习惯带来很大的变革。很多时候我就在想,我们还能怎样应用分布式呢?百思不得其解之时,爱因斯坦的小提琴就莫名其妙地浮现在了脑海里。音乐!一个好的乐队、好的乐团,不正是由一个个小的部分组成的吗?于是,自由乐队就蕴育而出了。
本文将重点讲述下自由乐队分布式协同演奏的技术实现路线,重点讲的是思路,讲的不好的地方还请大家多多包涵~
路线一
采用监听数据库的方法实现组网间设备的协同演奏
主要流程如上图,核心就是分布式状态数据库和分布式音乐演奏数据库,通过监听这两个数据库实现组网间设备的组队和协同演奏功能。分布式状态数据库用于组队信息的传输,分布式协同演奏数据库用于乐器模拟按键信息的传输。
分布式音乐演奏数据库的初始化:
如下图,我们软件初始化的时候就会创建属于该设备的DeviceKvStore,并对其进行监听。
同时,我们在DataAbility里有个deviceKvStores用来保存deviceId和DeviceKvStore的对应关系。
判断是否为本地端:
如下图,我们采用通过intent携带的关键字来判断是否为本地端。
本地端调起协同端时,写入该关键字:
点击事件的处理:
如下图,当监听到点击事件发生的时候,统一调用DataAbility.clickSound(),为防止阻塞,我们使用异步调用的方式。
而DataAbility.clickSound()则会通过DeviceId获取到DeviceKvStore,同时将按键点击事件的mSrc(即相应按键的ID)写入。
DeviceKvStore数据库的监听:
如下图,首先会判断是否为本地端,若为本地端则处理点击事件。处理点击事件的核心就是获取到点击按键的mSrc,首先通过notification.getDeviceId()获取到DeviceId,然后通过DeviceId去获取响应的DeviceKvStore,然后通过key来拿到mSrc,进而调用DataAbility.playClip()。DataAbility.playClip()就是模拟乐器演奏的相关函数。
分布式状态数据库的初始化:
分布式状态数据库的监听:
核心就是获取此时退出队伍设备的DeviceId,若当前设备为本地端,则停止对该设备进行监听,同时弹出该设备退出队伍的提示;若当前设备为协同端,同时发起退出设备的DeviceId为当前队伍的本地端,则表示该队伍已解散,当前设备变为本地端,同时弹出队伍已解散的提示。
值得一提的是,分布式状态数据库是所有设备初始化的时候都通过DataAbility.STATE_KEY来监听同一个分布式状态数据库DeviceKvStore,而分布式音乐演奏数据库则是每个设备都会根据自己唯一的DataAbility.storeId来创建分布式音乐演奏数据库DeviceKvStore,也就是说会有多个分布式音乐演奏数据库。
因此,我们是在DataAbility里通过deviceKvStores来储存DeviceId和DeviceKvStore的对应关系。组队的实质就是实现对相应分布式音乐演奏数据库的监听。多个DeviceKvStore就能够实例化多个KvStoreObserver来对多个数据库进行监听,并行进行处理,减少并发带来的影响,降低协同演奏的延时。
协同演奏模拟乐器:
协同端和本地端一样,当监听到点击事件的时候,也是调用DataAbility.clickSound()。同样在DataAbility.clickSound()里通过DeviceId获取DeviceKvStore,然后将按键点击事件的mSrc写入相应的DeviceKvStore分布式数据库。
不同的是协同端的KvStoreObserver虽然监听到了数据变化,但是判断当前设备为协同端,则不会去进行模拟乐器演奏的播放。而此时,组队本地端也同时监听到了数据变化,进而去进行模拟乐器演奏的播放。
路线二
我们想到的第二种实现分布式协同演奏的方法就是类似于Codelabs里面的分布式游戏手柄的写法(链接在文末),本地端调起协同端的时候通过IAbilityConnection进行连接。同时,协同端通过proxy.senDataToRemote()将按键信息发送给本地端,本地端通过onRemoteRequest()来处理协同端发来的信息。详细讲解可以参考Codelabs里面的代码,同时有一些包也在Demo里面封装好了,可以不用重复造轮子。
具体代码实现我之前测试的时候都写好了。BUT,因为太卡了,我们就放弃了这条路线,代码也给回退了。(也可能是我们的水平有限,代码优化的不是很好)我们当时是先写的通过订阅分布式数据库来实现协同演奏的,但是我最开始是只通过订阅一个单板本分布式数据库实现的协同演奏,感觉效果不太理想,就尝试了路线二。尝试了之后发现,路线二还没有之前的延迟小呢,就最终确定了采用路线一,同时后面又对路线一进行了相关的优化,比如采用订阅分布式状态数据库和多个分布式音乐演奏数据库、异步处理点击事件、线程阻塞等等技术来降低延迟,最终实现了至少三个设备(当时手上只有三个设备)可以协同演奏一首曲子的程度。
总结
协同演奏的实现路线我们研究了两条,分别是监听数据库和直接建立连接。两者都可以实现功能,但是协同演奏很重要的一点就是延迟,延迟太大就真的只能听个响了。个人觉得,就目前来看,鸿蒙在分布式减少延迟这块还是有很长的路要走的。
最后,还是老规矩,有讲的不对的地方,欢迎大家在评论区指正~
Codelabs:分布式游戏手柄(Java) (huawei.com)
(本文原创,转载请标明出处和原文链接)
更多关于HarmonyOS鸿蒙Next分布式协同演奏技术实现路线(Java)的实战教程也可以访问 https://www.itying.com/category-93-b0.html
是不是应该要注明用的什么SDK,API之类的?
SDK版本: 3.0.0.1(API Version 7)
我想着是要是想复现或者开发相关的话,肯定也基本上用最新版本的SDK,这个是我们今年三四月份开发的,重点是实现的思路~,
HarmonyOS鸿蒙Next的分布式协同演奏技术主要依赖于其分布式能力框架,通过设备间的协同工作实现多设备间的实时数据同步和交互。具体实现路线如下:
-
分布式软总线:鸿蒙Next的分布式软总线技术是实现设备间通信的基础。通过软总线,不同设备可以建立低延迟、高带宽的连接,确保演奏数据的实时传输。
-
分布式数据管理:鸿蒙Next提供了分布式数据管理能力,允许不同设备共享和同步数据。在协同演奏中,各设备的演奏数据可以通过分布式数据库进行实时同步,确保所有设备的状态一致。
-
分布式任务调度:鸿蒙Next的分布式任务调度机制可以协调不同设备的计算资源,确保演奏任务的合理分配和执行。例如,主设备可以负责节奏控制,而从设备负责音效处理。
-
分布式设备虚拟化:通过设备虚拟化技术,鸿蒙Next可以将多个物理设备虚拟化为一个逻辑设备。在协同演奏中,用户可以通过一个设备控制多个设备的演奏行为,实现统一的演奏体验。
-
分布式安全机制:鸿蒙Next提供了多层次的安全机制,确保协同演奏过程中的数据安全和设备安全。通过身份认证、数据加密等技术,防止未经授权的设备接入和数据泄露。
-
分布式UI框架:鸿蒙Next的分布式UI框架支持跨设备的界面协同。在协同演奏中,用户可以在不同设备上查看和控制演奏状态,实现无缝的用户体验。
通过以上技术路线,HarmonyOS鸿蒙Next能够实现高效的分布式协同演奏,提供流畅、稳定的多设备协同体验。
HarmonyOS鸿蒙Next的分布式协同演奏技术实现路线主要包括以下步骤:
-
设备发现与连接:使用
DistributedDeviceManager
进行设备发现,并通过DeviceInfo
获取设备信息,建立连接。 -
数据同步:利用
DistributedDataManager
实现设备间的数据同步,确保演奏数据的实时性和一致性。 -
音频处理:通过
AudioManager
和AudioTrack
进行音频数据的采集、处理和播放,确保音质和同步。 -
事件分发:使用
DistributedEventManager
进行事件的分发和响应,确保各设备间的演奏动作同步。 -
错误处理与恢复:实现错误检测和恢复机制,确保在设备断开或数据丢失时能够快速恢复演奏。
通过这些步骤,可以实现多设备间的协同演奏,提升用户体验。