基于HarmonyOS的分镜头App开发技术详解

《分镜头App》的创作灵感来源于殷冬的日常观察，他发现平常人们在自拍时，往往会用前置摄像头，由于像素、取景景别等因素的限制，前摄拍出来的效果往往不是很理想；此外，当我们帮别人拍照时，对方也无法实时看到照片的取景角度和构图，拍出来的照片也很难让对方满意；对于照片的分享和美化，更是众口难调。为了解决这些痛点，提升用户的拍照体验，经过不断摸索，殷冬发现HarmonyOS的分布式技术有着很大的应用潜力。于是他基于HarmonyOS从0到1完成了《分镜头App》的开发。

以下将为大家分享该款应用的开发者殷冬的开发心得。

一，HarmonyOS技术使用

《分镜头App》主要用到了分布式文件服务、分布式硬件虚拟化、以及分布式数据服务。

分布式文件服务

利用分布式文件服务，可以自动同步其他设备拍摄的照片和视频，实现分布式相册功能。

起初殷冬以为分布式文件服务使用起来会很复杂，例如是否需要自己控制同步、初始化功能等等。而真正接触后他发现，在底层上，分布式文件服务已经将复杂的工作都处理好了，只需用一行代码，就可以使用分布式文件服务，就相当于调用本地文件系统一样，只不过再继续向下，底层会帮助开发者处理很多业务。

分布式硬件虚拟化

分布式硬件虚拟化的特性，可以调用其他设备的硬件，实现相关的功能。在《分镜头App》中，调用其他设备的相机画面，就用到了分布式硬件虚拟化。并且可以控制拍摄画面的比例，实现不一样的拍摄效果。

殷冬最初接触硬件虚拟化这个概念的时候，只是知道是基于分布式软总线实现的虚拟化，至于怎么使用，并不是很清楚，后来通过深入的学习发现，主动调用其他设备的接口，可以使用分布式任务调度或者IDL接口两种方法实现。而分布式任务调度和IDL接口，都可以传递实现Sequenceable接口的实现类对象。

而硬件功能关键类都实现了Sequenceable接口，比如：相机预览画面的关键类Surface，就实现了Sequenceable接口。因此可以通过IDL将设备A的Surface对象，以参数的形式，传递到设备B。设备B的Service Ability执行相机初始化操作，就可以拿到设备B相机的拍摄画面。

由此，就在代码编辑层面实现了硬件虚拟化。

分布式数据服务

在《分镜头App》中，有很多的协同操作。协同操作的核心逻辑，利用了分布式数据服务的数据变更通知功能。当一个设备触发协同操作时，通过变更通知，从设备触发UI和效果的变化，实现分布式协同功能。

分布式数据服务有两个功能，可以为开发者带来很大的便捷。第一个是多端数据同步功能，当通过一个设备修改了数据库中的数据，其他设备也会做同步。第二个是在添加、修改、删除数据库数据时，其他设备如果创建了数据库的链接，并绑定了数据变更监听时，就会触发该监听。开发者可以利用这两个功能特性，做多端的协同功能。

数据库初始化：

数据库变更监听：

分布式相册实现

相册主要存储图片、视频文件，可以使用分布式文件服务进行存储。此项功能殷冬还需要实现动态添加的效果，即：其他设备拍摄时，本机的相册列表动态显示刚刚拍摄的照片缩略图。这种效果可以在确定使用分布式文件服务存储照片和视频后，使用HarmonyOS的公共事件与通知功能，从而实现动态加载的效果。

在拍摄完成时，通过公共事件功能发送一条广播。

同时，在相册模块，注册公共事件，用于处理接收到通知后的动态添加缩略图逻辑。

分布式文件服务负责同步拍摄的照片、视频等信息，公共事件通知则主动进行页面的刷新，二者合用，实现动态添加的效果。

二、多设备协同实现

目标设备未打开协同页面问题处理

多设备协同实际上有个隐藏的前提，那就是所有设备都处于同一个协同页面中。这需要处理目标设备不在协同页面的问题。

此时可以创建一个单版本分布式数据库，key值为设备id，value值为协同页面是否启动true/false。当进入到协同页面时，在onStart方法中设置值为true。当退出页面时，在onInactive方法中设置值为false。

在发起协同前，可以通过单版本分布式数据库，获取到目标设备是否启动了协同页面。

如果没有启动，可以先通过abilitySlice.startAbility（）将目标设备拉起，进入到协同页面，然后再进入协同状态。

如果目标设备已经处于协同页面，就可以直接进入到协同状态。

统一管理分布式操作

由于分布式数据服务每个应用最多同时打开16个KvStore，所以不能每一个协同操作都使用一个数据库。这里可以在value值上做文章，以实现通过一个分布式数据库，就可以实现一个页面中的多个操作的协同。

首先，可以使用一个常量作为分布式协同数据库的key。每次put时，都使用这个常量作为key，以替换之前的数据。

其次，需要创建一个实体类。成员变量中，需要有两个基础变量：

operationType：int型，当前协同操作的类型；

targetDeviceId：List《String》，需要协同的设备id数组；

operationType字段主要是用来区分当前的操作类型，这样方便调用相同的功能进行协同操作。targetDeviceId主要是存储向哪些设备发起协同操作，可以通过判断本设备id是否在数组当中，如果不存在，就不做任何操作。

此时需要将实体类转换成字符串，再存储到分布式协同数据库中。因此，可以通过JSONObject.toJSONString（），将实体类转换成字符串并进行存储。

被调用方需要为分布式数据库，绑定数据变更监听。这样，其他设备添加或修改数据的时候，就会触发监听。监听类型要设备其他设备触发的变化，这样可以避免本地修改也会触发本地的监听的问题。

在监听中就可以处理协同的功能。首先要判断变更的数据是否为空，避免后续出错。然后可以将key的json值取出，并做非空判断。

接下来需要将json字符串转换成实体类，便于后续操作。这里可以使用JSONArray.parseObject（json， class）进行转换。

然后进行判断，是否需要本设备进行协同。

当本设备需要协同时，可以通过switch根据操作类型，调用不同的方法进行协同即可。

总结

殷冬通过官方文档、论坛、HarmonyOS技术社区等途径，系统的学习和了解HarmonyOS的特性，最终开发了本次大赛的《分镜头App》作品。未来，他还将持续深入了解HarmonyOS，尝试开发更为有趣的HarmonyOS分布式应用，也期待更多开发者加入到HarmonyOS生态，一起创造无限可能！

责任编辑：haq