作者：萬合

距離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 現狀

現有的裝置是否滿足商家大屏多攝像頭、裝置間協同互動、便攜低門檻的開播訴求呢？我們先來對比下它們的特性：

開播裝置選型對比：

手機開播，手機分別負責推流、互動，有一定的協同便攜能力，但是存在螢幕小和攝像頭不可配等問題；
PC開播，具備可配置的攝像頭和大屏，硬體成本不高，但裝置大便攜性差而且功能集中在一臺裝置缺乏互動性；
直播一體機開播，專門為直播開播定製的裝置有大屏功能強，但是硬體門檻較高而且硬體都是燒錄無法定製。

綜上，我們期望提供給商家直播的開播工具需要具備多裝置協同、大屏互動、連線線路少、硬體可配、高價效比，那麼，有沒有同時滿足這些優點的開播方案呢？

二、方案設計

當前我們App已經有很多主播是HarmonyOS使用者，針對已經具備HarmonyOS裝置的中小商家，我們提出了基於分散式軟匯流排的多裝置協同開播方案。

2.1 方案概述

主播使用手機開播時，當遇到大屏裝置，可以一鍵將直播能力流轉到大屏裝置上，這時候主播的手機呈現遙控器狀態，大屏螢幕上分別展示實時資料看板、實時互動資訊和主播講解的採集畫面。如果場景中有商品攝像頭，主播手機也可以喚起商品攝像頭，商品攝像頭會將採集的音視訊資料傳輸給大屏裝置顯示，最終由大屏裝置完成合流推流。協播可以通過連線大屏裝置，從而獲取實時音視訊流播放，實現與主播觀眾的協同互動。該方案主要有兩大核心技術能力，分別是直播互動在跨裝置上的遷移流轉、音視訊流在多裝置上的協同傳輸。

2.2 方案特點

該方案同時具備上述開播工具的優點：

多裝置間高效協同。專門錄製主播講解的攝像頭，專門採集商品畫面的攝像頭，大屏裝置展示主播講解畫面合併分發視訊流，主播手機操控所有開播裝置，協播手機播放視訊流觀看；
大屏互動。大屏裝置展示直播資料和互動資訊，主播手機可以操控大屏互動，協播手機可以與主播、觀眾大屏互動；
便攜線路少。多裝置間在同一區域網內完成無線連線；
裝置可配。錄製主播和錄製商品的攝像頭可選配置，大屏互動裝置可選配置；
高價效比裝置。主播、協播普通HarmonyOS手機，普通顯示器外接HarmonyOS裝置，攝像頭根據清晰度需求可配。

三、技術實現

實現上述產品方案的核心技術能力是直播互動的遷移流轉和音視訊流的協同傳輸，這兩個技術能力的底層都是基於HarmonyOS的分散式軟匯流排在我們專案上的擴充封裝。接下來，我先簡單介紹下分散式軟匯流排。

分散式匯流排是華為鴻蒙提出的概念，它的靈感應該來自於計算機系統，在計算機系統裡把CPU、輸入、輸出裝置等之間傳送資訊的公共通路叫匯流排。而軟匯流排是通過建立多裝置間的虛擬通訊連線，完成多裝置間無物理線路連線的互聯互通，從而低時延高頻寬的裝置間資訊傳輸功能，使得各個裝置之間可以通過無線的方式實現高效的資料傳輸。

從上面的架構圖中，我們可以看到分散式軟匯流排封裝了多種通訊協議，並且將裝置的發現、連線、傳輸統一封裝成對外透明的介面，開發者只需要通過簡單的呼叫就可以實現多裝置間的互聯互通，無需關心聯通的細節。

我們方案中的直播互動正是基於分散式軟匯流排實現多裝置遷移流轉，音視訊流也是通過軟匯流排通道實現跨裝置的傳輸，下面給大家詳細介紹下這兩個技術產品能力的實現。

3.1 直播互動的遷移流轉

產品功能

直播互動在多裝置上遷移流轉主要三個功能：

直播實時資料遷移大屏；
主播、協播互動遷移大屏；
主播中臺控制操作大屏。

技術方案

主播端App改造原有Android專案，增加HarmonyOS Ability依賴，新增開播控制的FA；
大屏端App是原有App上新增了大屏的HAP，包括直播資料FA 、實時互動FA；
協播端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 音視訊流的協同傳輸

產品功能

音視訊流在跨裝置上的協同傳輸主要四個功能：

主播音視訊採集流轉到大屏攝像頭；
喚起商品攝像頭採集商品畫面並流轉大屏裝置；
大屏裝置合併商品和主播畫面播放並推流；
音視訊流傳輸到協播手機播放觀看。

技術方案

主播App在連線大屏裝置後將關閉音視訊採集、預覽功能；
大屏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開播功能的基礎上，軟體層面實現同一個應用在多裝置上不同能力表達，硬體層面可根據商家實力選擇合適裝置，開發成本低，商家投入少

分散式軟匯流排是HarmonyOS作業系統獨有的能力，當前方案最大的缺點就是無法在其他作業系統的手機上實現，所以只有HarmonyOS的使用者才具備這個能力。未來我們會探索在Android和iOS上實現類似的功能，同時也希望我們在電商直播的多裝置協同開播的實踐，能夠帶啟發更多技術產品利用分散式軟匯流排能力落地業務場景。

4.2 展望

基於我們沉澱的直播互動遷移和音視訊協同傳輸兩大技術能力，未來我們會在這兩個方向進一步探索

多機位多攝像頭開播，豐富直播內容。 隨著集團Artc逐步適配HarmonyOS並提供更多流處理能力，我們可以提供專業高清的攝像頭錄製商品，可移動的攝像頭走播工廠，多角度的攝像頭採集直播畫面，進一步提升我們的直播內容質量
標準化的中控盒子，降低開播成本。 將音視訊流合流分發、投屏展示、開播控制的能力集中在一箇中控裝置上，主播只需要擁有該裝置就可以實現以上打包的開播能力

當前我們的方案主要還是軟體應用的開發並不涉及硬體的開發，所以實際使用的時候需要的攝像頭和大屏裝置能力都是採用HarmonyOS的手機完成的，如果我們具有燒錄OpenHarmony的攝像頭和投屏盒子，將進一步降低商家的成本、豐富開播的能力。隨著5G和萬物互聯時代的發展，目之可及的前景還是十分廣闊。

參考：

分散式語音照相 https://gitee.com/panthole/ha...
跨裝置遷移視訊內容 https://gitee.com/panthole/ha...
HamonyOS視訊解碼能力播放預覽畫面 https://gitee.com/panthole/ha...

關注我們，每週 3 篇移動技術實踐&乾貨給你思考！

1688 商家基於 HarmonyOS 的多屏協同直播技術方案

一、業務背景

1.1 痛點

1.2 現狀

二、方案設計

2.1 方案概述

2.2 方案特點

三、技術實現

3.1 直播互動的遷移流轉

產品功能

技術方案

程式碼實現

難點和限制

3.2 音視訊流的協同傳輸

產品功能

技術方案

程式碼實現

難點和限制

四、總結和展望

4.1 總結

4.2 展望

參考：

相關文章