本文主要整理互動直播中各端的邏輯，重點是與前端相關的教師端IM的部分和Web/Wap學生端。希望通過這份整理，對于前端在維護時可以盡快的理解互動直播的流程，提高項目的可維護性；對于客戶端和教師端來說，可以了解到前端提供的接口和消息的實現。也能提高對整個請麥過程的理解，便于聯調和后期的定位問題。

相關閱讀推薦

《連麥互動直播方案全實踐1：什么是連麥互動直播？》

《連麥互動直播方案全實踐2：網易云信連麥互動直播方案的演變過程》

《連麥互動直播方案全實踐3：網易云信連麥互動的實現方案》

概 況

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

在設計系統之前，首先需要考慮以下幾個問題：

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

• 各端之間的協議

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

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

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

• 云信IM服務提供了一整套即時通訊基礎能力，可以將即時通訊、實時網絡能力快速集成至企業自身應用中。

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

架 構

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

1. 學生在App客戶端進入聊天室，可以發起請麥；

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

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

結合需求整理出以下的基本請麥，連麥，互動的流程， 如下圖，不同樣式的數據流向代表不同的協議。

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

1、客戶端云信IM的SDK，客戶端通過云信IM發送P2P消息到教師端

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

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

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

5、Web端云信IM的SDK，發送接收消息

6、自定義消息，各端發送信息的數據結構

設計與實現

實現這節主要介紹上一節概述中提到的教師客戶端 ，Web/Wap學生端的實現。主要包括以下幾部分：流程細化、教師IM模塊、Web學生端模塊、配置、優勢、存在的問題。

流程細化

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

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

- notifyQueueChange

- notifyVolume

- notifyCustomMsg

- checkUpdate

- notifyLiveStatus

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

1、客戶端初始化

各端通過請求服務端獲取統一的聊天室地址

2、教師端初始化

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

3、請麥的過程

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

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

• 客戶端通過互動直播SDK，連麥進入直播間，通過互動直播SDK發送消息給教師端native

• 教師端native調用notifyQueueChange方法，更新教師IM中各列表

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

教師IM模塊

結合流程圖以及上面的流程細化說明，對前端的模塊進行設計和拆分，如下圖。

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

Web學生端模塊

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

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

配置

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

優劣分析

采用這套設計的優點是

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

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

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

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

存在的問題

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

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

3、優化前端實現的方法。

總 結

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

另外，想要獲取更多產品干貨、技術干貨，記得關注網易云信博客。

總結

以上是生活随笔為你收集整理的技术详解：实现互动直播全过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。