作者：万合

间隔HarmonyOS 2.0正式公布曾经过来三个多月了，最新数据显示已有超过1亿台设施降级到了HarmonyOS操作系统。然而，对于宽广的利用开发者而言，HarmonyOS仿佛和Android没有什么差别，更多地也就是做一些原有性能的适配或迁徙。针对HarmonyOS最外围的技术亮点——分布式软总线，还不分明如何实现，更不分明该如何与本人的业务相结合。

在1688直播域供应侧，咱们始终在一直摸索如何进步商家开播能力、升高商家开播老本，当理解到分布式软总线的个性后，咱们发现HarmonyOS的这些能力十分切合1688商家多设施开播诉求，于是咱们研发了这个联合分布式软总线的多设施开播计划。

本文我将联合业务场景从技术角度，分享下1688直播供应侧是如何基于HarmonyOS的分布式软总线技术，实现多设施协同开播，助力1688商家升高开播老本、进步开播能力。

与通常的手机开播不同，咱们的计划波及到多设施多屏幕，实现除了录制主播以外，还能够连贯额定的摄像头专门录制商品，大屏展现直播的数据和预览，协播与主播大屏互动等性能。先通过一段视频理解下咱们技术产品计划的实现成果，请点击下述链接查看视频：

1688 商家基于 HarmonyOS 的多屏协同直播技术计划

一、业务背景

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

1.1 痛点

不同于淘宝直播的主播很多是商家请来的业余MCN团队，1688直播的主播大多数就是商家本人，他们对本人的货品一五一十，但却对电商直播不足业余的开播能力和开播设施。如何在1688商家投入无限资源的前提下，帮忙商家升高开播门槛、进步开播品质呢，通过线下走访商家，咱们发现几个常见的开播相干的问题。

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

主播与协播繁多设施互动

工厂环境简陋便携性艰难

总结下，1688直播商家在开播设施方面次要存在以下三大痛点：

1. 直播不足特定性能设施

  • 不足商品摄像头，以后摄像头间隔商品远，主播须要频繁走近开播设施能力展现商品细节，影响直播观感；
  • 不足互动大屏，手机直播互动屏幕小，主播须要走近开播设施能力看清观众留言与观众互动，影响直播体验。

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

  • 开播工具协同难，主播用到的录制设施、互动设施和协播应用的中控设施之间不互通操作艰难；
  • 主播协播互动难，通常主播解说商品、协播下品发券，因为单方的设施间不足互动只能口播沟通不足私密性。

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

  • 开播设施投入低，1688的很多主播自身是中小商家，直播投入谋求性价比，开播设施参差不齐；
  • 开播设施便携差，在工厂车间等简单场景须要驻播和走播协同开播，设施难以便携，不足多机位开播能力。

1.2 现状

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

开播设施选型比照：

  1. 手机开播，手机别离负责推流、互动，有肯定的协同便携能力，然而存在屏幕小和摄像头不可配等问题；
  2. PC开播，具备可配置的摄像头和大屏，硬件老本不高，但设施大便携性差而且性能集中在一台设施不足互动性；
  3. 直播一体机开播，专门为直播开播定制的设施有大屏性能强，然而硬件门槛较高而且硬件都是烧录无奈定制。

综上，咱们冀望提供给商家直播的开播工具须要具备多设施协同、大屏互动、连贯线路少、硬件可配、高性价比，那么，有没有同时满足这些长处的开播计划呢？

二、方案设计

以后咱们App曾经有很多主播是HarmonyOS用户，针对曾经具备HarmonyOS设施的中小商家，咱们提出了基于分布式软总线的多设施协同开播计划。

2.1 计划概述

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

2.2 计划特点

该计划同时具备上述开播工具的长处：

  1. 多设施间高效协同。专门录制主播解说的摄像头，专门采集商品画面的摄像头，大屏设施展现主播解说画面合并散发视频流，主播手机操控所有开播设施，协播手机播放视频流观看；
  2. 大屏互动。大屏设施展现直播数据和互动信息，主播手机能够操控大屏互动，协播手机能够与主播、观众大屏互动；
  3. 便携线路少。多设施间在同一局域网内实现无线连接；
  4. 设施可配。录制主播和录制商品的摄像头可选配置，大屏互动设施可选配置；
  5. 高性价比设施。主播、协播一般HarmonyOS手机，一般显示器外接HarmonyOS设施，摄像头依据清晰度需要可配。

三、技术实现

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

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

从下面的架构图中，咱们能够看到分布式软总线封装了多种通信协定，并且将设施的发现、连贯、传输对立封装成对外通明的接口，开发者只须要通过简略的调用就能够实现多设施间的互联互通，无需关怀联通的细节。

咱们计划中的直播互动正是基于分布式软总线实现多设施迁徙流转，音视频流也是通过软总线通道实现跨设施的传输，上面给大家具体介绍下这两个技术产品能力的实现。

3.1 直播互动的迁徙流转

产品性能

直播互动在多设施上迁徙流转次要三个性能：

  1. 直播实时数据迁徙大屏；
  2. 主播、协播互动迁徙大屏；
  3. 主播中台管制操作大屏。

技术计划

  1. 主播端App革新原有Android我的项目，减少HarmonyOS Ability依赖，新增开播管制的FA；
  2. 大屏端App是原有App上新增了大屏的HAP，包含直播数据FA 、实时互动FA；
  3. 协播端APP是也原有Android我的项目新增与主播和买家互动的FA。

主播App首先发现并连贯左近大屏，而后将直播数据FA和实时互动FA，无缝流转迁徙到大屏设施，主播App跳转至开播管制FA，主播App通过中台管制能够操作大屏和协播App，设施间的互动通过IDL通信实现。须要留神的是，上述三个设施的App都是基于原有我的项目革新新增的能力，三者为同一个App。

代码实现

咱们以主播端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 音视频流的协同传输

产品性能

音视频流在跨设施上的协同传输次要四个性能：

  1. 主播音视频采集流转到大屏摄像头；
  2. 唤起商品摄像头采集商品画面并流转大屏设施；
  3. 大屏设施合并商品和主播画面播放并推流；
  4. 音视频流传输到协播手机播放观看。

技术计划

  1. 主播App在连贯大屏设施后将敞开音视频采集、预览性能；
  2. 大屏App上新增录制预览能力和合流推流能力，同时须要减少编码将采集到的音视频流传输到协播App上；
  3. 商品摄像头上减少采集音视频和传输到大屏设施的能力；
  4. 协播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 总结

咱们的计划具备以下三个特点：

  1. 软件计划解决硬件限度。 利用HarmonyOS分布式软总线技术，采纳软件计划突破1688直播场景的硬件限度，将利用性能打散到最匹配的硬件设施上，实现硬件资源的互助互补
  2. 联合场景拓展开播能力。 联合1688商家直播的场景特点，基于HarmonyOS的分布式软总线的个性，解决直播互动、音视频传输的无缝流转，实现大屏互动、多设施开播性能
  3. 低本高效解决商家痛点。 在根本不扭转原有1688开播性能的根底上，软件层面实现同一个利用在多设施上不同能力表白，硬件层面可依据商家实力抉择适合设施，开发成本低，商家投入少

分布式软总线是HarmonyOS操作系统独有的能力，以后计划最大的毛病就是无奈在其余操作系统的手机上实现，所以只有HarmonyOS的用户才具备这个能力。将来咱们会摸索在Android和iOS上实现相似的性能，同时也心愿咱们在电商直播的多设施协同开播的实际，可能带启发更多技术产品利用分布式软总线能力落地业务场景。

4.2 瞻望

基于咱们积淀的直播互动迁徙和音视频协同传输两大技术能力，将来咱们会在这两个方向进一步摸索

  1. 多机位多摄像头开播，丰盛直播内容。 随着团体Artc逐渐适配HarmonyOS并提供更多流解决能力，咱们能够提供业余高清的摄像头录制商品，可挪动的摄像头走播工厂，多角度的摄像头采集直播画面，进一步晋升咱们的直播内容品质
  2. 标准化的中控盒子，升高开播老本。 将音视频流合流散发、投屏展现、开播管制的能力集中在一个中控设施上，主播只须要领有该设施就能够实现以上打包的开播能力

以后咱们的计划次要还是软件应用的开发并不波及硬件的开发，所以理论应用的时候须要的摄像头和大屏设施能力都是采纳HarmonyOS的手机实现的，如果咱们具备烧录OpenHarmony的摄像头和投屏盒子，将进一步升高商家的老本、丰盛开播的能力。随着5G和万物互联时代的倒退，目之可及的前景还是非常广大。

参考：

  • 分布式语音照相 https://gitee.com/panthole/ha...
  • 跨设施迁徙视频内容 https://gitee.com/panthole/ha...
  • HamonyOS视频解码能力播放预览画面 https://gitee.com/panthole/ha...

关注咱们，每周 3 篇挪动技术实际&干货给你思考！