1688直播基于HarmonyOS分布式软总线助力商家多设备开播-阿里云开发者社区

引言

距离HarmonyOS 2.0正式发布已经过去三个多月了，最新数据显示已有超过1亿台设备升级到了HarmonyOS操作系统。然而，对于广大的应用开发者而言，HarmonyOS似乎和Android没有什么差异，更多地也就是做一些原有功能的适配或迁移。针对HarmonyOS最核心的技术亮点——分布式软总线，还不清楚如何实现，更不清楚该如何与自己的业务相结合。

在1688直播域供给侧，我们一直在不断探索如何提高商家开播能力、降低商家开播成本，当了解到分布式软总线的特性后，我们发现HarmonyOS的这些能力非常切合1688商家多设备开播诉求，于是我们研发了这个结合分布式软总线的多设备开播方案。

与通常的手机开播不同，我们的方案涉及到多设备多屏幕，实现除了录制主播以外，还可以连接额外的摄像头专门录制商品，大屏展示直播的数据和预览，协播与主播大屏互动等功能。先通过一段视频了解下我们技术产品方案的实现效果

  <source id="mp4" src="https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/660a50ad-a951-44a9-9304-e2e2835de6bb.mp4" type="video/mp4">

一、业务背景

1688是国内领先的B2B电商平台，我们服务的客户主要包括工厂老板、淘宝卖家、实体店主、档口商家等。由于疫情导致线下实体生意的萎缩，越来越多的工厂、档口老板寻求线上直播带货转型，随着业务的发展，今年我们也孵化了专门面向商家侧的App——1688商家版，提供给商家更加专业的服务，包括直播、洽谈、工作台等，本文的实践案例正是在1688商家版直播域场景。

1.1 痛点

不同于淘宝直播的主播很多是商家请来的专业MCN团队，1688直播的主播大多数就是商家自己，他们对自己的货品如数家珍，但却对电商直播缺乏专业的开播能力和开播设备。如何在1688商家投入有限资源的前提下，帮助商家降低开播门槛、提高开播质量呢，通过线下走访商家，我们发现几个常见的开播相关的问题。

主播频繁走近摄像头展示商品细节

主播与协播单一设备互动

工厂环境简陋便携性困难

总结下，1688直播商家在开播设备方面主要存在以下三大痛点：
1. 直播缺乏特定功能设备

缺乏商品摄像头，当前摄像头距离商品远，主播需要频繁走近开播设备才能展示商品细节，影响直播观感
缺乏互动大屏，手机直播互动屏幕小，主播需要走近开播设备才能看清观众留言与观众互动，影响直播体验

2. 直播设备之间难以协同

开播工具协同难，主播用到的录制设备、互动设备和协播使用的中控设备之间不互通操作困难
主播协播互动难，通常主播讲解商品、协播上品发券，由于双方的设备间缺乏互动只能口播沟通缺乏私密性

3. 直播设备投入低能力差

开播设备投入低，1688的很多主播本身是中小商家，直播投入追求性价比，开播设备参差不齐
开播设备便携差，在工厂车间等复杂场景需要驻播和走播协同开播，设备难以便携，缺乏多机位开播能力

1.2 现状

现有的设备是否满足商家大屏多摄像头、设备间协同互动、便携低门槛的开播诉求呢？我们先来对比下它们的特性

<br>
<div style="
display: inline-block;
color: #999;">开播设备选型对比</div>

手机开播，手机分别负责推流、互动，有一定的协同便携能力，但是存在屏幕小和摄像头不可配等问题。
PC开播，具备可配置的摄像头和大屏，硬件成本不高，但设备大便携性差而且功能集中在一台设备缺乏互动性。
直播一体机开播，专门为直播开播定制的设备有大屏功能强，但是硬件门槛较高而且硬件都是烧录无法定制。

综上，我们期望提供给商家直播的开播工具需要具备多设备协同、大屏互动、连接线路少、硬件可配、高性价比，那么，有没有同时满足这些优点的开播方案呢？

二、方案设计

当前我们App已经有很多主播是HarmonyOS用户，针对已经具备HarmonyOS设备的中小商家，我们提出了基于分布式软总线的多设备协同开播方案。

2.1 方案概述

主播使用手机开播时，当遇到大屏设备，可以一键将直播能力流转到大屏设备上，这时候主播的手机呈现遥控器状态，大屏显示屏上分别展示实时数据看板、实时互动信息和主播讲解的采集画面。如果场景中有商品摄像头，主播手机也可以唤起商品摄像头，商品摄像头会将采集的音视频数据传输给大屏设备显示，最终由大屏设备完成合流推流。协播可以通过连接大屏设备，从而获取实时音视频流播放，实现与主播观众的协同互动。该方案主要有两大核心技术能力，分别是直播互动在跨设备上的迁移流转、音视频流在多设备上的协同传输。

2.2 方案特点

该方案同时具备上述开播工具的优点：

多设备间高效协同

专门录制主播讲解的摄像头，专门采集商品画面的摄像头，大屏设备展示主播讲解画面合并分发视频流，主播手机操控所有开播设备，协播手机播放视频流观看

大屏互动

大屏设备展示直播数据和互动信息，主播手机可以操控大屏互动，协播手机可以与主播、观众大屏互动

便携线路少

多设备间在同一局域网内完成无线连接
4.设备可配
录制主播和录制商品的摄像头可选配置，大屏互动设备可选配置
5.高性价比设备
主播、协播普通HarmonyOS手机，普通显示器外接HarmonyOS设备，摄像头根据清晰度需求可配

三、技术实现

实现上述产品方案的核心技术能力是直播互动的迁移流转和音视频流的协同传输，这两个技术能力的底层都是基于HarmonyOS的分布式软总线在我们项目上的拓展封装。接下来，我先简单介绍下分布式软总线。

分布式总线是华为鸿蒙提出的概念，它的灵感应该来自于计算机系统，在计算机系统里把CPU、输入、输出设备等之间传送信息的公共通路叫总线。而软总线是通过建立多设备间的虚拟通信连接，完成多设备间无物理线路连接的互联互通，从而低时延高带宽的设备间信息传输功能，使得各个设备之间可以通过无线的方式实现高效的数据传输。

从上面的架构图中，我们可以看到分布式软总线封装了多种通讯协议，并且将设备的发现、连接、传输统一封装成对外透明的接口，开发者只需要通过简单的调用就可以实现多设备间的互联互通，无需关心联通的细节。

我们方案中的直播互动正是基于分布式软总线实现多设备迁移流转，音视频流也是通过软总线通道实现跨设备的传输，下面给大家详细介绍下这两个技术产品能力的实现。

3.1 直播互动的迁移流转

3.1.1 产品功能

直播互动在多设备上迁移流转主要三个功能：1. 直播实时数据迁移大屏；2. 主播、协播互动迁移大屏；3. 主播中台控制操作大屏

3.1.2 技术方案

主播端App改造原有Android项目，增加HarmonyOS Ability依赖，新增开播控制的FA
大屏端App是原有App上新增了大屏的HAP，包括直播数据FA 、实时互动FA
协播端APP是也原有Android项目新增与主播和买家互动的FA

主播App首先发现并连接附近大屏，然后将直播数据FA和实时互动FA，无缝流转迁移到大屏设备，主播App跳转至开播控制FA，主播App通过中台控制可以操作大屏和协播App，设备间的互动通过IDL通信实现。需要注意的是，上述三个设备的App都是基于原有项目改造新增的能力，三者为同一个App。

3.1.3 代码实现

我们以主播端App唤起大屏端App同时自身跳转中台控制为例

在LiveControlAbility的进行流转设备注册

ContinuationRegisterManager continuationRegisterManager = getContinuationRegisterManager();
continuationRegisterManager.register(getBundleName(), null, callback, requestCallback);

在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);
            }
        }
    };

在大屏ScreenServiceAbility的onConnect接收数据并拉起大屏FA ScreenPageAbility

    public IRemoteObject onConnect(Intent intent) {
            jumpScreen();
            return new ScreenRemoteForController();
    }

ScreenRemoteForController继承自HarmonyControllerInterfaceSkeletonScreen在OnConnect回调以后初始化，并且接收从主播App发送的指令如唤起其他设备，再通过EventHandler进行事件分发

    class ScreenRemoteForController extends HarmonyControllerInterfaceSkeleton {
        ScreenRemoteForController() {
            super("IScreenRemoteInterface");
        }

        @Override
        public void sendCommand(String command) throws RemoteException {
             MyApplication.getHandler().sendEvent(command);   
        }

3.1.4 难点和限制

跨设备通信

HarmonyOS的设备当前通信方式只支持以IDL的方式，并且IDL是单向通信的，为了实现设备之间双向通信，我们采取在IDL中的增加回调的方法，或者采用创建两个双向IDL的方式实现设备间的双通。

Android与HarmonyOS混合兼容开发

当前我们的所有功能都是在原有Android项目上进行的HarmonyOS增量开发，然后再进行混合打包。这里的功能开发受限于还有很多基础库尚未完成HarmonyOS的迁移适配、HarmonyOS和Android间的兼容与通信等。

3.2 音视频流的协同传输

3.2.1 产品功能

音视频流在跨设备上的协同传输主要四个功能：1.主播音视频采集流转到大屏摄像头 2. 唤起商品摄像头采集商品画面并流转大屏设备 3.大屏设备合并商品和主播画面播放并推流 4.音视频流传输到协播手机播放观看

3.2.2 技术方案

主播App在连接大屏设备后将关闭音视频采集、预览功能
大屏App上新增录制预览能力和合流推流能力，同时需要增加编码将采集到的音视频流传输到协播App上
商品摄像头上增加采集音视频和传输到大屏设备的能力
协播App去掉之前从云端拉取流的方式，改为本地解码后播放音视频流

主播App 在连接大屏设备后，会唤起大屏设备的摄像头录制音视频并显示预览，大屏设备启动后拉起商品摄像头，同时对采集的音视频流编码，将流传输到大屏设备上合流并推流，协播手机可以获取大屏音视频流播放

3.2.3 代码实现

我们以商品摄像头被唤起后采集音视频传输到大屏端为例

当商品摄像头被唤起后，首先初始化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;
}

以商品摄像头采集的视频数据为例，将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();

将转化后的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);

    }

大屏设备收到商品摄像头发送的音视频数据进行解码后播放

 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();
        }
    };

3.2.4 难点和限制

音视频流本地编解码传输
有别于传统的本地编码推流，本方案里面设备间音视频流都是在局域网内传输，由于分布式软总线的带宽有限，而视频数据较大，我们采用对本地视频流YUV数据进行编解码，通过切片合流的方式，达到了720P的视频流传输。
多设备的组网
HarmonyOS的设备组网需要基于前提条件，包括同一WiFi、开启蓝牙、暂时只支持登录相同华为账号，之所以条件苛刻的原因我想主要还是安全性考虑，不过在我们这个场景中，设备都是服务于同一个直播账号，登录相同的华为账号再进行开播场景也合理。

四、总结和展望

4.1 总结

我们的方案具备以下三个特点：

软件方案解决硬件限制
利用HarmonyOS分布式软总线技术，采用软件方案打破1688直播场景的硬件限制，将应用功能打散到最匹配的硬件设备上，实现硬件资源的互助互补
结合场景拓展开播能力
结合1688商家直播的场景特点，基于HarmonyOS的分布式软总线的特性，解决直播互动、音视频传输的无缝流转，实现大屏互动、多设备开播功能
低本高效解决商家痛点
在基本不改变原有1688开播功能的基础上，软件层面实现同一个应用在多设备上不同能力表达，硬件层面可根据商家实力选择合适设备，开发成本低，商家投入少

分布式软总线是HarmonyOS操作系统独有的能力，当前方案最大的缺点就是无法在其他操作系统的手机上实现，所以只有HarmonyOS的用户才具备这个能力。未来我们会探索在Android和iOS上实现类似的功能，同时也希望我们在电商直播的多设备协同开播的实践，能够带启发更多技术产品利用分布式软总线能力落地业务场景。

4.2 展望

基于我们沉淀的直播互动迁移和音视频协同传输两大技术能力，未来我们会在这两个方向进一步探索

1. 多机位多摄像头开播，丰富直播内容
随着集团Artc逐步适配HarmonyOS并提供更多流处理能力，我们可以提供专业高清的摄像头录制商品，可移动的摄像头走播工厂，多角度的摄像头采集直播画面，进一步提升我们的直播内容质量

2. 标准化的中控盒子，降低开播成本
将音视频流合流分发、投屏展示、开播控制的能力集中在一个中控设备上，主播只需要拥有该设备就可以实现以上打包的开播能力

当前我们的方案主要还是软件应用的开发并不涉及硬件的开发，所以实际使用的时候需要的摄像头和大屏设备能力都是采用HarmonyOS的手机完成的，如果我们具有烧录OpenHarmony的摄像头和投屏盒子，将进一步降低商家的成本、丰富开播的能力。随着5G和万物互联时代的发展，目之可及的前景还是十分广阔。

五、参考

1.分布式语音照相 https://gitee.com/panthole/harmonyos-codelabs/tree/master/VoiceCamera
2.跨设备迁移视频内容 https://gitee.com/panthole/harmonyos-codelabs/tree/master/DistributedVideoCodelab
3.HamonyOS视频解码能力播放预览画面 https://gitee.com/panthole/harmonyos-codelabs/tree/master/CodecDemo

1688直播基于HarmonyOS分布式软总线助力商家多设备开播

引言

一、业务背景

1.1 痛点

1.2 现状

二、方案设计

2.1 方案概述

2.2 方案特点

三、技术实现

3.1 直播互动的迁移流转

3.1.1 产品功能

3.1.2 技术方案

3.1.3 代码实现

3.1.4 难点和限制

3.2 音视频流的协同传输

3.2.1 产品功能

3.2.2 技术方案

3.2.3 代码实现

3.2.4 难点和限制

四、总结和展望

4.1 总结

4.2 展望

五、参考

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

1688直播基于HarmonyOS分布式软总线助力商家多设备开播

引言

一、 业务背景

1.1 痛点

1.2 现状

二、 方案设计

2.1 方案概述

2.2 方案特点

三、技术实现

3.1 直播互动的迁移流转

3.1.1 产品功能

3.1.2 技术方案

3.1.3 代码实现

3.1.4 难点和限制

3.2 音视频流的协同传输

3.2.1 产品功能

3.2.2 技术方案

3.2.3 代码实现

3.2.4 难点和限制

四、总结和展望

4.1 总结

4.2 展望

五、参考

热门文章

最新文章

相关课程

相关电子书

相关实验场景

一、业务背景

二、方案设计