1688 商家基于 HarmonyOS 的多屏协同直播技术方案
文章图片
作者:万合
距离HarmonyOS 2.0正式发布已经过去三个多月了,最新数据显示已有超过1亿台设备升级到了HarmonyOS操作系统。然而,对于广大的应用开发者而言,HarmonyOS似乎和Android没有什么差异,更多地也就是做一些原有功能的适配或迁移。针对HarmonyOS最核心的技术亮点——分布式软总线,还不清楚如何实现,更不清楚该如何与自己的业务相结合。
在1688直播域供给侧,我们一直在不断探索如何提高商家开播能力、降低商家开播成本,当了解到分布式软总线的特性后,我们发现HarmonyOS的这些能力非常切合1688商家多设备开播诉求,于是我们研发了这个结合分布式软总线的多设备开播方案。
【1688 商家基于 HarmonyOS 的多屏协同直播技术方案】本文我将结合业务场景从技术角度,分享下1688直播供给侧是如何基于HarmonyOS的分布式软总线技术,实现多设备协同开播,助力1688商家降低开播成本、提高开播能力。
与通常的手机开播不同,我们的方案涉及到多设备多屏幕,实现除了录制主播以外,还可以连接额外的摄像头专门录制商品,大屏展示直播的数据和预览,协播与主播大屏互动等功能。先通过一段视频了解下我们技术产品方案的实现效果,请点击下述链接查看视频:
1688 商家基于 HarmonyOS 的多屏协同直播技术方案
一、业务背景
1688是国内领先的B2B电商平台,我们服务的客户主要包括工厂老板、淘宝卖家、实体店主、档口商家等。由于疫情导致线下实体生意的萎缩,越来越多的工厂、档口老板寻求线上直播带货转型,随着业务的发展,今年我们也孵化了专门面向商家侧的App——1688商家版,提供给商家更加专业的服务,包括直播、洽谈、 工作台等,本文的实践案例正是在1688商家版直播域场景。
文章图片
1.1 痛点
不同于淘宝直播的主播很多是商家请来的专业MCN团队,1688直播的主播大多数就是商家自己,他们对自己的货品如数家珍,但却对电商直播缺乏专业的开播能力和开播设备。如何在1688商家投入有限资源的前提下,帮助商家降低开播门槛、提高开播质量呢,通过线下走访商家,我们发现几个常见的开播相关的问题。
文章图片
主播频繁走近摄像头展示商品细节
文章图片
主播与协播单一设备互动
文章图片
工厂环境简陋便携性困难
总结下,1688直播商家在开播设备方面主要存在以下三大痛点:
1. 直播缺乏特定功能设备
- 缺乏商品摄像头,当前摄像头距离商品远,主播需要频繁走近开播设备才能展示商品细节,影响直播观感;
- 缺乏互动大屏,手机直播互动屏幕小,主播需要走近开播设备才能看清观众留言与观众互动,影响直播体验。
- 开播工具协同难,主播用到的录制设备、互动设备和协播使用的中控设备之间不互通操作困难;
- 主播协播互动难,通常主播讲解商品、协播上品发券,由于双方的设备间缺乏互动只能口播沟通缺乏私密性。
- 开播设备投入低,1688的很多主播本身是中小商家,直播投入追求性价比,开播设备参差不齐;
- 开播设备便携差,在工厂车间等复杂场景需要驻播和走播协同开播,设备难以便携,缺乏多机位开播能力。
文章图片
开播设备选型对比:
- 手机开播,手机分别负责推流、互动,有一定的协同便携能力,但是存在屏幕小和摄像头不可配等问题;
- PC开播,具备可配置的摄像头和大屏,硬件成本不高,但设备大便携性差而且功能集中在一台设备缺乏互动性;
- 直播一体机开播,专门为直播开播定制的设备有大屏功能强,但是硬件门槛较高而且硬件都是烧录无法定制。
二、方案设计 当前我们App已经有很多主播是HarmonyOS用户,针对已经具备HarmonyOS设备的中小商家,我们提出了基于分布式软总线的多设备协同开播方案。
2.1 方案概述 主播使用手机开播时,当遇到大屏设备,可以一键将直播能力流转到大屏设备上,这时候主播的手机呈现遥控器状态,大屏显示屏上分别展示实时数据看板、实时互动信息和主播讲解的采集画面。如果场景中有商品摄像头,主播手机也可以唤起商品摄像头,商品摄像头会将采集的音视频数据传输给大屏设备显示,最终由大屏设备完成合流推流。协播可以通过连接大屏设备,从而获取实时音视频流播放,实现与主播观众的协同互动。该方案主要有两大核心技术能力,分别是直播互动在跨设备上的迁移流转、音视频流在多设备上的协同传输。
文章图片
2.2 方案特点 该方案同时具备上述开播工具的优点:
- 多设备间高效协同。专门录制主播讲解的摄像头,专门采集商品画面的摄像头,大屏设备展示主播讲解画面合并分发视频流,主播手机操控所有开播设备,协播手机播放视频流观看;
- 大屏互动。大屏设备展示直播数据和互动信息,主播手机可以操控大屏互动,协播手机可以与主播、观众大屏互动;
- 便携线路少。多设备间在同一局域网内完成无线连接;
- 设备可配。录制主播和录制商品的摄像头可选配置,大屏互动设备可选配置;
- 高性价比设备。主播、协播普通HarmonyOS手机,普通显示器外接HarmonyOS设备,摄像头根据清晰度需求可配。
分布式总线是华为鸿蒙提出的概念,它的灵感应该来自于计算机系统,在计算机系统里把CPU、输入、输出设备等之间传送信息的公共通路叫总线。而软总线是通过建立多设备间的虚拟通信连接,完成多设备间无物理线路连接的互联互通,从而低时延高带宽的设备间信息传输功能,使得各个设备之间可以通过无线的方式实现高效的数据传输。
文章图片
从上面的架构图中,我们可以看到分布式软总线封装了多种通讯协议,并且将设备的发现、连接、传输统一封装成对外透明的接口,开发者只需要通过简单的调用就可以实现多设备间的互联互通,无需关心联通的细节。
我们方案中的直播互动正是基于分布式软总线实现多设备迁移流转,音视频流也是通过软总线通道实现跨设备的传输,下面给大家详细介绍下这两个技术产品能力的实现。
3.1 直播互动的迁移流转 产品功能
文章图片
直播互动在多设备上迁移流转主要三个功能:
- 直播实时数据迁移大屏;
- 主播、协播互动迁移大屏;
- 主播中台控制操作大屏。
文章图片
- 主播端App改造原有Android项目,增加HarmonyOS Ability依赖,新增开播控制的FA;
- 大屏端App是原有App上新增了大屏的HAP,包括直播数据FA 、实时互动FA;
- 协播端APP是也原有Android项目新增与主播和买家互动的FA。
代码实现
我们以主播端App唤起大屏端App同时自身跳转中台控制为例:
文章图片
1、在LiveControlAbility的进行流转设备注册;
ContinuationRegisterManager continuationRegisterManager = getContinuationRegisterManager();
continuationRegisterManager.register(getBundleName(), null, callback, requestCallback);
2、在ContinuationDeviceCallback连接设备回调成功后调用connectAbility唤起大屏PA ScreenServiceAbility并传递相关参数;
private IContinuationDeviceCallback callback = new IContinuationDeviceCallback() {
@Override
public void onDeviceConnectDone(String selectDeviceId, String deviceType) {
connectAa(selectDeviceId);
continuationRegisterManager.updateConnectStatus(abilityToken, selectDeviceId, DeviceConnectState.CONNECTED.getState(), null);
}
}
};
3、在大屏ScreenServiceAbility的onConnect接收数据并拉起大屏FA ScreenPageAbility;
public IRemoteObject onConnect(Intent intent) {
jumpScreen();
return new ScreenRemoteForController();
}
4、ScreenRemoteForController继承自HarmonyControllerInterfaceSkeletonScreen在OnConnect回调以后初始化,并且接收从主播App发送的指令如唤起其他设备,再通过EventHandler进行事件分发。
class ScreenRemoteForController extends HarmonyControllerInterfaceSkeleton {
ScreenRemoteForController() {
super("IScreenRemoteInterface");
}@Override
public void sendCommand(String command) throws RemoteException {
MyApplication.getHandler().sendEvent(command);
}
难点和限制
跨设备通信
HarmonyOS的设备当前通信方式只支持以IDL的方式,并且IDL是单向通信的,为了实现设备之间双向通信,我们采取在IDL中的增加回调的方法,或者采用创建两个双向IDL的方式实现设备间的双通。
Android与HarmonyOS混合兼容开发
当前我们的所有功能都是在原有Android项目上进行的HarmonyOS增量开发,然后再进行混合打包。这里的功能开发受限于还有很多基础库尚未完成HarmonyOS的迁移适配、HarmonyOS和Android间的兼容与通信等。
3.2 音视频流的协同传输 产品功能
文章图片
音视频流在跨设备上的协同传输主要四个功能:
- 主播音视频采集流转到大屏摄像头;
- 唤起商品摄像头采集商品画面并流转大屏设备;
- 大屏设备合并商品和主播画面播放并推流;
- 音视频流传输到协播手机播放观看。
文章图片
- 主播App在连接大屏设备后将关闭音视频采集、预览功能;
- 大屏App上新增录制预览能力和合流推流能力,同时需要增加编码将采集到的音视频流传输到协播App上;
- 商品摄像头上增加采集音视频和传输到大屏设备的能力;
- 协播App去掉之前从云端拉取流的方式,改为本地解码后播放音视频流。
代码实现
我们以商品摄像头被唤起后采集音视频传输到大屏端为例:
1、当商品摄像头被唤起后,首先初始化SurfaceProvider,并在其surfaceCallback回调中连接后台ScreenServiceAbility服务,同时打开摄像头;
protected SurfaceOps.Callback surfaceCallback = new SurfaceOps.Callback() {
@Override
public void surfaceCreated(SurfaceOps surfaceOps) {
previewSurface = surfaceOps.getSurface();
Intent intent = new Intent();
Operation operation = new Intent.OperationBuilder()
.withDeviceId("")
.withBundleName(mCameraAbility.getBundleName())
.withAbilityName("com.alibaba.screencamera.ScreenServiceAbility")
.build();
intent.setOperation(operation);
intent.setParam("client_role", "camera");
mCameraAbility.connectAbility(intent, mAbilityConnection);
openCamera();
}
};
2、启动的后台服务ScreenServiceAbility在onConnect时将音视频数据进行传输;
public IRemoteObject onConnect(Intent intent) {
return new ScreenRemoteFoSlave() {
@Override
public void onPcmReady(byte[] pcmData) throws RemoteException {
mControllerCallback.onPcmReady(pcmData);
}@Override
public void onYuvData(int type, int length, int seq, byte[] cameraData) throws RemoteException {mControllerCallback.onReturnData(type, length, seq, cameraData);
}
}
return null;
}
3、以商品摄像头采集的视频数据为例,将YUV数据格式编码后发送;
mCodec.registerCodecListener(new Codec.ICodecListener() {
@Override
public void onReadBuffer(ByteBuffer byteBuffer, BufferInfo bufferInfo, int trackId) {
byte[] msg = new byte[bufferInfo.size];
byteBuffer.clear();
byteBuffer.get(msg);
sendEncodedDataToRemote(msg, bufferInfo);
}}
);
mCodec.setCodecFormat(fmt);
mCodec.start();
4、将转化后的YUV视频帧数据先做切片然后通过ScreenService后台服务进行发送;
private void sendEncodedDataToRemote(byte[] data, BufferInfo bufferInfo) {
byte[] msgTemp = new byte[bufferInfo.size];
System.arraycopy(data, position, msgTemp, 0, msgTemp.length);
mScreenServiceProxy.onYuvData(CameraUtil.IRemoteMsg.MSG_TYPE_SLICE_END, bufferInfo.size, 0, data);
}
5、大屏设备收到商品摄像头发送的音视频数据进行解码后播放。
private ControllerCallbackStub mControllerCallback = new ControllerCallbackStub("com.alibaba.cameraohos.IControlFaCallback") {
@Override
public void onPcmReady(byte[] pcmData) throws RemoteException {
mPlayRecord.playTransData(pcmData);
}@Override
public void onReturnData(int type, int length, int seq, byte[] cameraData) throws RemoteException {
createMyDecoder();
initMuxer();
}
};
难点和限制
音视频流本地编解码传输
有别于传统的本地编码推流,本方案里面设备间音视频流都是在局域网内传输,由于分布式软总线的带宽有限,而视频数据较大,我们采用对本地视频流YUV数据进行编解码,通过切片合流的方式,达到了720P的视频流传输。
多设备的组网
HarmonyOS的设备组网需要基于前提条件,包括同一WiFi、开启蓝牙、暂时只支持登录相同华为账号,之所以条件苛刻的原因我想主要还是安全性考虑,不过在我们这个场景中,设备都是服务于同一个直播账号,登录相同的华为账号再进行开播场景也合理。
四、总结和展望 4.1 总结 我们的方案具备以下三个特点:
- 软件方案解决硬件限制。 利用HarmonyOS分布式软总线技术,采用软件方案打破1688直播场景的硬件限制,将应用功能打散到最匹配的硬件设备上,实现硬件资源的互助互补
- 结合场景拓展开播能力。 结合1688商家直播的场景特点,基于HarmonyOS的分布式软总线的特性,解决直播互动、音视频传输的无缝流转,实现大屏互动、多设备开播功能
- 低本高效解决商家痛点。 在基本不改变原有1688开播功能的基础上,软件层面实现同一个应用在多设备上不同能力表达,硬件层面可根据商家实力选择合适设备,开发成本低,商家投入少
4.2 展望 基于我们沉淀的直播互动迁移和音视频协同传输两大技术能力,未来我们会在这两个方向进一步探索
- 多机位多摄像头开播,丰富直播内容。 随着集团Artc逐步适配HarmonyOS并提供更多流处理能力,我们可以提供专业高清的摄像头录制商品,可移动的摄像头走播工厂,多角度的摄像头采集直播画面,进一步提升我们的直播内容质量
- 标准化的中控盒子,降低开播成本。 将音视频流合流分发、投屏展示、开播控制的能力集中在一个中控设备上,主播只需要拥有该设备就可以实现以上打包的开播能力
参考:
- 分布式语音照相 https://gitee.com/panthole/ha...
- 跨设备迁移视频内容 https://gitee.com/panthole/ha...
- HamonyOS视频解码能力播放预览画面 https://gitee.com/panthole/ha...
推荐阅读
- 基于微信小程序带后端ssm接口小区物业管理平台设计
- 基于|基于 antd 风格的 element-table + pagination 的二次封装
- 基于爱,才会有“愿望”当“要求”。2017.8.12
- javaweb|基于Servlet+jsp+mysql开发javaWeb学生成绩管理系统
- JavaScript|vue 基于axios封装request接口请求——request.js文件
- 韵达基于云原生的业务中台建设 | 实战派
- EasyOA|EasyOA 基于SSM的实现 未完成总结与自我批判
- 基于stm32智能风扇|基于stm32智能风扇_一款基于STM32的智能灭火机器人设计
- stm32|基于STM32和freeRTOS智能门锁设计方案
- Python|Python 基于datetime库的日期时间数据处理