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

相關閱讀推薦

概    況

互動直播涉及到服務端，教師客戶端，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、優化前端實現的方法。

總    結

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

另外，想要獲取更多產品乾貨、技術乾貨，記得關注。