1.直播功能？？？？

答：我們這個專案裡的直播採用的是整合騰訊雲直播SDK進行的，因為在直播中可能會涉及到彈幕和刷禮物等功能所以還需要整合騰訊的IM即時通訊，並且通過騰訊雲服務，直播的流程大概由以下幾個步驟組成，採集、編碼、封裝、主播推流到伺服器、伺服器通過CDN對流進行分發、解碼、觀眾進行拉流觀看直播。

採集其實就是通過裝置的攝像頭對影象進行採集並進行處理，麥克風對音訊進行採集並處理，在這個步驟裡，我們一般採集到的影象是YUV或者是RGB格式，而音訊採集採集到的一般是PCM格式的

當採集完之後的視訊記憶體是相當大的，大概一個7s的視訊會有800M的記憶體佔用，可以想象一下，800M的視訊只有7s，先不說使用者的體驗怎麼樣，就說我們往伺服器推流的時候是十分緩慢的，所以要對視訊進行編碼，我覺得編碼就是對視訊進行壓縮，我們都知道，編碼無非就是硬編和軟編，騰訊雲直播用的就是軟編，底層有一系列的演算法，最終會將原始視訊轉化成H264格式的資料，轉換過後視訊就只有大概708k，騰訊做的挺好的，同時，音訊通過脈衝編碼機制轉換成PCM格式的。其實在做視訊編碼的時候也奉行了去除多餘影象的原則，比如說有可能影象與影象之間有較大的相關性，可以去除一些，還有人的視覺有時候對一些影象的感知並不是那麼強，所以也可以去掉。

然後就是封裝，其實封裝就是把視訊和音訊進行合併的過程，封裝之後的的音視訊在我們這個專案裡是FLV格式的，因為RTMP實時訊息傳輸協議在網路較好的情況下延遲較低，所以我們通過RTMP進行實時傳輸的，畢竟是直播嘛，肯定得實時上傳，這個協議也是基於TCP實現的，需要先將FLV進行打包，以後就成為了RTMP格式的了

視訊壓縮後，還是比較適合進行直播的，所以當我們的主播想要進行直播的時候會自己的房間名稱之，主播ID等一些資訊編寫成一個JSON串向伺服器傳送直播請求，伺服器會實時的給主播返回一個推流的URL，這個時候就可以直接把推流到伺服器。

當伺服器拿到主播推過來的流之後，會通過CDN流分發進行傳輸，這個傳輸和推流使用的也是RTMP協議進行的。這裡騰訊雲後臺有很好的實現。所以一般我們是不用考慮的。

拉流的話就比較簡單了，當觀眾想看某場球賽的時候，會向伺服器發起拉流的請求，同時伺服器會給觀眾返回一個JSON串，這個串裡面有主播的資訊，和所有在看主播直播的觀眾的資訊，以及最重要的拉流地址，拿到拉流地址之後為了視訊的安全性，所以我們內部封裝了一個防盜鏈的演算法，大概是基於當前的時間戳，以及伺服器返回的JSON串中有一個唯一的sissionId生成的，進行計算，之後會用防盜鏈和拉流地址進行拼接拿到真正的拉流地址，通過騰訊雲的TCLVoideView實現拉流觀看直播。

問：你們的專案中有沒有連麥功能？

答：沒有。但是我對於連麥也有一點了解，連麥其實就是混流，主播和連麥者是通過P2P進行互動的。我有說過在整合騰訊雲SDK的時候同時也集成了騰訊的IM 即時通訊的，連麥者向主播發起連麥請求的時候，主播彈出diglog之類的對話方塊進行提醒，如果主播同意的話會向連麥發訊息告訴連麥者接受連麥，連麥者會向伺服器發起請求，伺服器會實時給連麥者返回連麥者的推流地址，連麥者實現推流之後，CDN內部會對主播的推流地址和主播的拉流地址進行合併也就是所謂的混流，之後觀眾拉到流就是一個混流，直接就可以觀看進行連麥的房間。

問：你們的直播支援多少房間同時線上直播？穩定性怎麼樣？

答：因為我們的專案是集成了騰訊的雲直播SDK的，支援上萬人同時線上直播應該不是問題，之後如果公司發展好的話，估計會有很多比賽同時進行，穩定性的話，現在因為同時進行的直播還達不到那麼多，還沒有什麼穩定性的問題，即時多了，我覺得騰訊的 馬化騰還是可以的。

問：彈幕是怎麼實現的？

答：彈幕我們是直接用的嗶哩嗶哩開源的一個比較成熟彈幕框架DanmakuFlameMaster，據說鬥魚也是這個框架，因為專案是集成了IM的，所以在主播開播的時候其實同時建立了一個群組聊天，當然在登入我們APP的時候肯定是同時登陸了IM的，觀眾在進入直播間的時候，同時也加入了一個群組，當傳送彈幕的時候會向群組發訊息，DanmakuFlameMaster中的danmuView是可以直接新增彈幕的，接收到訊息的主播和觀眾都會向它新增一條彈幕，之後就直接更新UI了。

問：刷禮物是怎麼實現的？

答：刷禮物和彈幕的原理是一樣的，都是通過IM發訊息，接收到訊息時，會實時的更新UI，進行動畫展示，根據所刷的禮物不同，數量不同會做出判斷，展示不同的效果。

問：這麼多訊息是怎麼判斷究竟應該怎麼做操作呢？

答：其實我們在發訊息的時候是發的一個JSON串，這個串裡面有一個action，同時我們在專案中也管理了一個有關action的類，判斷action做出相應操作。