所在項目之前做過互動直播的需求，在這里總結(jié)一下，更多的是想整理一下互動直播中各端的邏輯，重點是整理下跟前端相關(guān)的教師端IM的部分和web/wap學生端。希望通過這份整理，對于前端在維護時可以盡快的理解互動直播的流程，提高項目的可維護性；對于客戶端和教師端來說，可以了解到前端提供的接口和消息的實現(xiàn)。也能提高對整個請麥過程的理解，便于聯(lián)調(diào)和后期的定位問題。

●●●

概況

互動直播涉及到服務端，教師客戶端，iOS/android學生端，web/wap學生端。本文重點介紹的是請麥的交互流程，前端請麥模塊的設(shè)計，前端互動和聊天組件的設(shè)計。對于聊天室本身的聊天功能的實現(xiàn)，因為接入云信IM SDK，主要是通過api調(diào)用封裝實現(xiàn)的，就不細說了。

在設(shè)計系統(tǒng)之前，首先需要考慮以下幾個問題：

????? 各端的需求定義以及功能劃分，各端如何交互

????? 各端之間的協(xié)議

????? 客戶端請麥與教師端接收

????? 客戶端進入互動直播房間后互動信息的同步

帶著以上幾個問題，我們先整理一下可以依賴的的服務，通過網(wǎng)易云提供的以下服務如圖1所示，結(jié)合自有系統(tǒng)的需求設(shè)計，讓我們能迅速集成IM和互動直播的功能。

????? 云信IM服務提供了一整套即時通訊基礎(chǔ)能力，可以將即時通訊、實時網(wǎng)絡(luò)能力快速集成至企業(yè)自身應用中。

????? 云信的互動直播功能，支持主播和觀眾實時連麥互動。

圖 1

●●●

架構(gòu)

我們的基本需求主要是以下三部分：

1.??? 學生在app客戶端進入聊天室，可以發(fā)起請麥；

2.??? 在教師端可以對學生的請麥進行同意或拒絕的處理；

3.??? 在教師同意某位學生的請麥后，這位學生可以進入直播間進行互動。

結(jié)合需求整理出以下的基本請麥，連麥，互動的流程， 如圖2，不同樣式的數(shù)據(jù)流向代表不同的協(xié)議。

圖 2

這里有幾個概念補充介紹一下：

1、客戶端云信IM的sdk，客戶端通過云信IM發(fā)送p2p消息到教師端

2、客戶端互動直播sdk，客戶端接入互動直播

3、教師端云信sdk，接受p2p消息，

4、教師端互動直播sdk，與客戶端直播互動

5、web端云信IM的sdk，發(fā)送接收消息

6、自定義消息，各端發(fā)送信息的數(shù)據(jù)結(jié)構(gòu)

??????

●●●

設(shè)計與實現(xiàn)

實現(xiàn)這節(jié)主要介紹上一節(jié)概述中提到的教師客戶端 ，web/wap學生端的實現(xiàn)。主要包括以下幾部分：流程細化、教師IM模塊、web學生端模塊、配置、優(yōu)勢、存在的問題。

流程細化??????

先來介紹一下教師端的實現(xiàn)，按照圖2中的標號順序，對其中的一些細節(jié)做補充說明。教師端主要有兩部分，一部分是native，本文中稱為教師端native，另一部分是web頁面，本文中稱為教師IM。教師端native和教師IM通過jsbridge以及自定義消息進行通信。

首先，整理一下教師端native與教師IM通信的jsbridge如下：

- notifyQueueChange?

- notifyVolume

- notifyCustomMsg

- checkUpdate

- notifyLiveStatus

結(jié)合以上的流程圖，再對流程進行一下細化說明：

1、客戶端初始化

各端通過請求服務端獲取統(tǒng)一的聊天室地址

2、教師端初始化

教師IM，在初始化后，通過服務端請求（getPresenterLiveInfo），獲取聊天室地址，取得聊天室單例，通知教師端native聊天室就緒，獲取互動直播數(shù)據(jù)。

3、請麥的過程

????? 客戶端發(fā)送p2p消息到教師端native，教師端native通過jsbridge, 調(diào)用教師IM的notifyCustomMsg，教師IM更新自身維護的請麥請求等待隊列。

????? 教師IM點擊同意或拒絕，通過消息通知教師端native，教師端native通過p2p通知請麥的客戶端

????? 客戶端通過互動直播sdk，連麥進入直播間，通過互動直播sdk發(fā)送消息給教師端native

????? 教師端native調(diào)用notifyQueueChange方法，更新教師IM中各列表

????? 教師IM，異步請求（informServer）更新服務端上下麥隊列，發(fā)送自定義消息（im-sdk），廣播通知各客戶端。

教師IM模塊

結(jié)合流程圖以及上面的流程細化說明，對前端的模塊進行設(shè)計和拆分，如圖3。

圖 3

這里的LivePcChat是Tab中的聊天組件，LiveInteractivePresenter是處理互動操作的組件，XXcache是封裝對應數(shù)據(jù)層操作的組件。具體的組件實例，調(diào)用，數(shù)據(jù)請求和處理的過程，如圖4所示的時序圖：

?

圖4

web學生端模塊

對于web/wap學生端，因為web/wap學生端本身還未開發(fā)請麥的功能。這里以web學生端為例介紹一下web/wap學生端在互動列表和聊天互動中的實現(xiàn)。本身聊天室部分與教師端的聊天室是復用聊天組件的，因而這里也先把模塊劃分一下。可以參考教師端的組件劃分，對比一下教師端和學生端復用的部分組件，如圖5是web學生端的組件拆分。

圖5

從表1的對比可以看到，除了請麥相關(guān)的處理邏輯，教師端IM和web學生端在IM的其他功能是可以復用的。

?

配置

互動直播是在原來的直播基礎(chǔ)上做的迭代，所以這里要保證互動直播在教育各產(chǎn)品線的可配置性。這里所說的配置與教育公共組件池其他的模塊和組件接入的配置類似，也是依賴于教育通用組件cache-base，通過在直播頁面或者工程單頁加載時（機構(gòu)后臺），讀取config中的配置，一鍵配置。

優(yōu)劣分析

采用這套設(shè)計的優(yōu)點是

1、所有的服務端請求都是通過web頁面發(fā)送，減少教師端維護的成本；

2、模塊的可配置性，在不同的業(yè)務線，可以通過配置來決定是否接入互動直播；

3、組件顆粒化，在不同的模塊中，教師端可以接入聊天組件和互動組件，請麥組件，學生端可以只接入互動列表組件；

4、最大程度的依賴了現(xiàn)有的云信sdk實現(xiàn)的功能，能在較短的時間實現(xiàn)需求。

存在的問題

1、請麥的流程比較復雜，因為涉及到多端，各端調(diào)試比較浪費時間，這也是整理此文的目的。在打通對各端流程的認識后，各端在調(diào)試中都能首先定位到出問題的端，然后才能有的放矢的在某一個環(huán)節(jié)中發(fā)現(xiàn)問題。

2、因為是在原來的迭代基礎(chǔ)上進行的，很多組件沒有封裝成教育規(guī)范的組件，不過邏輯清晰的前提下，可以在后面的迭代中優(yōu)化掉。

3、優(yōu)化前端實現(xiàn)的方法。

●●●

總結(jié)

通過本文整理一下互動直播中各端的邏輯，便于后期接入對互動直播流程的理解。對客戶端和教師端來說，可以了解到前端提供的接口和消息的實現(xiàn)。如果在后續(xù)另外的工程中，需要接入互動直播模塊，能夠快速的接入和調(diào)試，同時可以就以上提出來的存在的問題做進一步優(yōu)化。

?

——推薦閱讀——

全面復盤！深度剖析直播答題產(chǎn)品架構(gòu)的難點與坑>>

如何快速設(shè)計短信驗證碼>>

如何做好Android 端音視頻測試>>

總結(jié)

以上是生活随笔為你收集整理的一种基于云信sdk的互动直播的实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。