了解更多开源请访问：开源基础软件社区https://ost.51cto.com，前面写过，分布式能力是鸿蒙的亮点之一。无论是分布式数据库、分布式文件管理，还是分布式任务流，都给我们的日常使用习惯带来了很大的改变。很多时候我在想，我们还能如何应用分布式？正在百思不得其解的时候，我的脑海里突然想起了爱因斯坦的小提琴。音乐！一个好的乐队，一个好的管弦乐队，不就是由小零件组成的吗？因此，自由乐队诞生了。本文将重点介绍自由乐队分布式协同演出的技术实现路线。重点是想法。如果不好，请多多包涵。2.Route1通过监控数据库的方式实现网络中设备的协同性能。主要流程如上图所示。核心是分布式状态数据库和分布式音乐性能数据库。通过对这两个数据库的监控，实现网络中设备的组队和协同性能功能。分布式状态数据库用于团队信息的传输，分布式协同演奏数据库用于乐器仿真关键信息的传输。1、分布式音乐演奏数据库的初始化如下图所示。软件初始化时，会创建并监控属于设备的DeviceKvStore。同时我们在DataAbility中有一个deviceKvStores，用来保存deviceId和DeviceKvStore的对应关系。2.判断是否为本地终端。如下图所示，我们通过intent携带的关键字来判断是否是本地终端。当本端调用协同端时，写入这个关键字：3.点击事件的处理如下图所示。当检测到点击事件时，统一调用DataAbility.clickSound()。为了防止阻塞，我们使用异步调用的方式。而DataAbility.clickSound()会通过DeviceId获取DeviceKvStore，同时写入按钮点击事件的mSrc（即对应按钮的ID）。4.DeviceKvStore数据库的监控如下图所示。首先会判断是否是本端，如果是本端则处理点击事件。处理点击事件的核心是获取被点击按钮的mSrc。首先通过notification.getDeviceId()获取DeviceId，然后通过DeviceId获取对应的DeviceKvStore，再通过key获取mSrc，然后调用DataAbility.playClip()。DataAbility.playClip()是模拟乐器演奏的相关函数。5、分布式状态数据库的初始化6、分布式状态数据库的监控核心是获取此时出队设备的DeviceId。如果当前设备为本端，则停止对该设备的监控，并弹出该设备出队提示；如果当前设备是合作端，同时发起退出的设备的DeviceId是当前团队的本端，则说明团队已经解散，当前设备成为本端，并弹出团队已解散的提示。值得一提的是，分布式状态数据库在所有设备初始化时通过DataAbility.STATE_KEY监听同一个分布式状态数据库DeviceKvStore，而分布式音乐演奏数据库使用自己唯一的DataAbility.storeId来创建一个分布式音乐演奏数据库DeviceKvStore，即也就是说，会有多个分布式音乐表演数据库。因此，我们在DataAbility中通过deviceKvStores存储DeviceId和DeviceKvStore的对应关系。团队组建的本质是监控相应的分布式音乐表演数据库。多个DeviceKvStore可以实例化多个KvStoreObserver来监控多个数据库并并行处理，减少并发的影响，降低协同性能的延迟。7、模拟乐器的协同演奏协同终端与本地终端相同。当检测到单击事件时，它还会调用DataAbility.clickSound()。同样在DataAbility.clickSound()中，通过DeviceId获取DeviceKvStore，然后将按钮点击事件的mSrc写入对应的DeviceKvStore分布式数据库中。不同的是，合作端的KvStoreObserver虽然监听到了数据变化，但判断当前设备为合作端，不会发挥模拟仪器性能。而此时，团队本地端也同时监测到了数据的变化，然后进行了模拟乐器演奏。3.Route2我们想到的实现分布式协同性能的第二种方法，类似于Codelabs中分布式gamepad的写法（链接在文末）。本端调用协作端时，通过IAbilityConnection进行连接。同时，合作端通过proxy.senDataToRemote()将关键信息发送给本端，本端通过onRemoteRequest()处理合作端发送的信息。详细解释可以参考Codelabs中的代码。同时Demo中也打包了一些包，大家不用再重复造轮子了。具体的代码实现是我之前测试的时候写的。BUT，因为太卡了，我们放弃了这条路线，代码回滚了。（也可能是我们水平有限，代码优化不是很好）我们最开始写的是通过订阅分布式数据库实现协同性能，但是我是在订阅单板分布式数据库才实现的第一的。一起玩，感觉效果不太理想，于是尝试了第二条路线。试用之后发现路由2没有以前那么慢了，所以最终还是决定采用路由1。同时对路由1做了相关的优化，比如使用订阅分布式状态数据库，多分布式音乐性能数据库，异步处理点击事件，线程阻塞等技术降低延迟，最终实现了至少三台设备（当时手上只有三台设备）可以协同播放一首音乐的程度。4.协同性能实现路线总结我们研究了两种方法，一种是监控数据库，另一种是直接建立连接。两者都可以实现功能，但是协同性能最重要的一点就是延迟。如果延迟太大，真的只能大声听到。个人感觉鸿蒙在分布式和降低延迟方面还有很长的路要走。代码实验室：分布式游戏手柄（Java）。了解更多开源知识，请访问：开源基础软件社区https://ost.51cto.com。
