、前言

2017 年 12 月，微信小程序向開發者開放了實時音視頻能力，給業內帶來廣闊的想象空間。連麥互動視頻直播技術在 2016 年直播風口中成為視頻直播的標配，然而只有在原生的 APP 上才能保障良好的用戶體驗。
那時候，在微信小程序中無法進行實時音視頻互動。微信小程序在去年 12 月宣布開放實時音視頻能力，再加上去年 6 月蘋果宣布即將支持 WebRTC，業內一下子千樹萬樹梨花開，前途一片光明。
連麥互動直播技術和微信小程序以及 WebRTC 能產生怎么樣的化學作用？開發者在微信小程序或者瀏覽器 WebRTC 上實現連麥互動直播技術的時候，需要知道什么和考慮什么？
連麥視頻直播的客戶端主要包括：原生 APP、瀏覽器 H5、瀏覽器 WebRTC、微信小程序。瀏覽器上的應用包括 H5 和 WebRTC，前者可以拉流觀看，后者可以實現推流和拉流。

2、視頻直播客戶端技術之Native APP

原生 APP 終端音視頻引擎的結構框圖如下，基本包括了音頻引擎、視頻引擎和網絡傳輸，合稱實時語音視頻終端引擎。這里還包含底層的音視頻采集和渲染，還有網絡的輸入輸出能力，這是操作系統開放的能力。

原生 APP 有個天然的好處，它是直接和操作系統打交道的，操作系統開放的資源和能力它都可以直接用，比如說音視頻的采集渲染，還有網絡的輸入輸出。套用一句時髦的廣告語：“沒有中間商賺差價”，直接和操作系統對接，可以獲得比較好的用戶體驗。
在原生 APP 上實現連麥直播的優勢是，對上面所說的七個環節有較好的把控，可以獲得比較低的延遲，能自研實現語音前處理 3A 算法，包括回聲消除，還有對抖動緩沖策略和碼率自適應的策略都有比較好的把控。另外，可以自主選擇使用 RTMP 協議還是基于 UDP 的私有協議，對抗弱網環境更加有保障。
市面上比較流行的前處理技術，比如美顏、掛件、變聲等，原生 APP 都可以通過開放前處理接口讓開發者實現或者對接這些技術。為什么要強調這個呢？因為瀏覽器 WebRTC 和微信小程序都沒有開放前處理接口，開發者沒有辦法自行實現或者對接第三方的美顏或者掛件等技術模塊。
在原生 APP 上，開發者可以得到全面的把控能力，讓用戶可以獲得更好的體驗。主流的視頻直播平臺都有自己的原生 APP 平臺，而瀏覽器和微信小程序相對來說是輔助的。原生 APP 的用戶體驗是最好的，而且對開發者來說也是最可控的。
在原生 APP 上實現連麥直播的劣勢是什么呢？開發門檻高，開發周期長、人力成本高。另外，從獲取用戶和傳播的角度來講，也沒有瀏覽器和微信小程序那么便利。

3、視頻直播客戶端技術之瀏覽器（HTML5）

瀏覽器 H5 就像一個硬幣有兩面，有好處也有劣勢，好處是開發成本低，容易傳播，劣勢是只能拉流，不能推流，不能做到多個用戶連麥直播。另外，在瀏覽器 H5 上延遲也是比較大。如果使用 RTMP 或者 HTTP-FLV，延遲會在 1 秒到 3 秒之間，如果用 HLS 延遲會大于 8 秒甚至 10 秒，這么大的延遲就根本就不允許實現連麥直播。
使用這三種協議都是通過瀏覽器 H5 中的播放器來播放的。在多主播連麥互動的場景中，一個播放器里面只能播一路視頻流，三個主播就得三個播放器，因此看不到多個主播同框連麥互動的情形。如果要看到多個主播同框互動的畫面，就必須把多路流混合成一路流，在單個播放器里面播放。
另外，瀏覽器 H5 的源代碼是開放的。如果在瀏覽器上把音視頻終端引擎實現了，相當于對外公開了所有核心的源代碼。因此，還沒有見過哪個廠商在瀏覽器 H5 上完整地把音視頻引擎真正做出來。即使你愿意做出來，瀏覽器也不會允許你這樣做，開發者和操作系統之間隔著瀏覽器，如果瀏覽器不把操作系統的核心能力開放給開發者，開發者就不能自主采集和渲染，不能掌控網絡輸入輸出，類似流控碼控等功能無法實現。
在瀏覽器 H5 中也可以通過 websocket 來傳輸，用 jsmpeg 來播放，視頻編解碼的格式用 mpeg1。
mpeg1 是一個比較老的媒體格式，所有瀏覽器都支持。在瀏覽器中使用 jsmpeg 播放器播放 mpeg1，所有瀏覽器也可以支持。這么做可以獲得比較低的延遲，但是還是無法推流，沒辦法實現連麥直播。

4、視頻直播客戶端技術之瀏覽器（WebRTC）

大家可能會覺得很遺憾，瀏覽器 H5 雖然很容易傳播，開發簡單但是體驗欠佳，不能連麥直播。那么在瀏覽器上能不能推流，能不能實現連麥直播呢？答案是可以的，那就要用到 WebRTC。
這里說的 WebRTC 是指已經被內嵌到瀏覽器里面，被瀏覽器支持的 WebRTC，而不是 WebRTC 的源代碼。部分主流瀏覽器內嵌了 WebRTC，對開發者開放了瀏覽器的實時音視頻能力。
上圖是 WebRTC 的結構圖。我們可以看到 WebRTC 包括了音頻引擎，視頻引擎、傳輸引擎等，最底層的虛線框表示可以重載，也就是說瀏覽器把最底層的音視頻渲染和網絡傳輸的底層能力開放給開發者，開發者可以根據自己的需求選擇是否進行重載。音頻引擎中，包括了兩個編解碼器：iSAC 和 iLBC，前者針對寬帶和超寬帶的音頻編解碼，后者針對窄帶音頻編解碼。
音頻引擎還包括了音頻抖動緩沖，回聲消除和噪音抑制模塊等。抖動緩沖中的 NetEQ 算法可以說是 WebRTC 里面的精華之一。
視頻引擎中，包括了 VP8 和 VP9 的視頻編解碼器，甚至是即將到來的 AV1。視頻引擎還包括視頻抖動緩沖和圖像質量增強等模塊。傳輸引擎，WebRTC 使用的是 SRTP（Secured Realtime Transport Protocol）安全實時傳輸協議。
最后，WebRTC 采取 P2P 的通信方式，沒有媒體服務器等后端的實現。以上是 WebRTC 的簡單介紹。
瀏覽器 WebRTC 一般的優勢和劣勢這里就不再重復，請大家自行百度，這里只說重點。瀏覽器 WebRTC 的好處就是實現了相對完整的音視頻終端引擎，允許在瀏覽器上推流，可以實現連麥直播。
然而，瀏覽器 WebRTC 也有不足：

• 沒有開放前處理接口，美顏和掛件這些模塊沒辦法接入第三方的或者自研方案；
• 媒體服務器后端沒有實現，開發者要實現媒體服務器，然后通過開源 WebRTC 網關（比如說 janus）接入；
• 編解碼器、抖動緩沖和語音前處理 3A 等能力只能依靠 WebRTC，不能自行定制化；
• 部分主流瀏覽器是不支持 WebRTC 的，特別是蘋果的瀏覽器。雖然說去年蘋果宣布支持 WebRTC, 但是目前 iOS Safari 最新版本對 WebRTC 的支持并不好，iOS Safari 的主流版本并不支持 WebRTC，在 iOS 上面微信瀏覽器也是不支持 WebRTC 的。

由于 WebRTC 不提供媒體服務器的實現，因此需要把瀏覽器 WebRTC 接入到媒體服務器后端，這個可以是自研的，也可以是第三方的服務。瀏覽器 WebRTC 和媒體服務器后端之間的協議和媒體格式是不一樣的，因此要做協議和格式的轉換。WebRTC 用的基于 UDP 的 SRTP，需要把它轉換成媒體服務器的基于 UDP 的私有協議。另外，媒體格式也需要轉換，因為 WebRTC 中語音視頻格式默認用的是 VP8 或者 VP9。同時實時傳輸網絡中有關信令調度也需要做一些調整。瀏覽器 WebRTC 和媒體服務器后端之間的接入層也可以采用開源的 WebRTC Gateway（比如說 janus）來實現。
瀏覽器是類似操作系統的一種超級應用，它坐擁重要的流量入口，然而它也是開發者和操作系統之間的“中間商”。開發者通過 WebRTC 獲得瀏覽器開放的實時音視頻能力，然而也必須要承受 WebRTC 帶來的痛苦。

5、視頻直播客戶端技術之微信小程序

微信小程序是什么？是跑在微信上面的輕型應用。微信是什么？是類操作系統的超級應用。這些特征和瀏覽器以及 H5 是不是很接近？H5 是瀏覽器支持的輕型應用，而瀏覽器是類操作系統的超級應用。瀏覽器背后是各大國際科技巨頭，不像微信這樣背后只有騰訊一個互聯網巨頭。因此，從這個角度來看，微信小程序、瀏覽器 WebRTC 和 H5 是有相通之處的。
微信小程序可以類比為瀏覽器 H5 那樣的客戶端和服務器的結構。其中 HTML 對應微信小程序的 WXML，CSS 對應小程序的 WXSS，小程序的腳本語言和 JS 是一樣的，只是框架不一樣。微信小程序提供了兩個標簽，一個是<live-pusher>，一個是<live-player>。<live-pusher>就是推流，<live-player>就是拉流，可以實現單向直播或者連麥直播。小程序提供兩種模式：LIVE 和 RTC，LIVE 支持單向直播，RTC 支持低延遲的連麥直播。目前微信小程序推流采用 RTMP 協議，如果要和私有協議互通，需要進行協議轉換。

微信小程序開放了實時音視頻能力，對業界來說是重大利好。然而，根據上面的信息和邏輯，我們也看到采用微信小程序實現連麥互動直播的好處和不足。
好處有三點：

• 1）開發成本低，開發周期短，基本和 H5 的開發難度差不多；
• 2）很容易傳播和獲客，充分利用好微信的優質流量；
• 3）可以推流和拉流，允許實現連麥直播和實時語音視頻通話。

不足有四點：

• 1）你會受制于微信小程序的實時音視頻能力，比如說，如果它的回聲消除有某些問題，你只能等微信團隊按照自己的節奏來優化，而自己沒有任何辦法去優化；
• 2）小程序沒有開放前處理接口，只能使用小程序自帶的美顏或者變聲功能（如果有），不能對接自行研發或者第三方的美顏或者變聲模塊；
• 3）通過 RTMP 協議推流和拉流，不能和基于 UDP 的私有協議互通連麥。如果要實現和基于 UDP 的私有協議互通連麥，就必須要增加接入層來轉換協議格式甚至媒體格式；
• 4）沒有實現后端媒體服務器，開發者必須要自行實現媒體服務器，或者把微信小程序接入到第三方的實時通信網絡。

瀏覽器通過 WebRTC 開放了瀏覽器的實時音視頻能力，而微信通過小程序開放了微信的實時音視頻能力，在兩個類操作系統的平臺上允許開發者去實現連麥直播和實時音視頻通話。然而，無論 WebRTC 還是小程序只是在終端上帶你入門，對開發者來說，要真正實現整套系統，還有很多工作需要做的。
如果要將微信小程序接入實時音視頻傳輸網絡，中間得有接入服務器，我們叫接入層。在接入層我們需要做協議的轉換，比如說，如果實時音視頻傳輸網絡是使用基于 UDP 的私有協議，那么要把 RTMP 協議轉為基于 UDP 的私有協議。還有媒體格式的轉換，如果和實時傳輸網絡的媒體格式不一樣，還需要進行轉換。

6、視頻直播客戶端技術之WebRTC 通過WebView接入小程序

還有別的方法在小程序上做連麥直播互動嗎？必須要使用微信小程序開放的語音視頻能力嗎？也不一定。下圖展示了我在市面上看過的一個技術方案，它繞過了微信小程序實時語音視頻能力，通過微信小程序 WebView 組件實現了連麥直播的方案。這里和大家分享一下。

這個方案的基本思路是利用 WebView 的瀏覽器特點，在 WebView 內使用 WebRTC 的 Web API，從而在小程序上獲得實時音視頻能力。上圖是這個方案的架構圖。最底層是微信小程序的基礎能力。上一層是 WebView，微信小程序的 WebView 類似瀏覽器，那么就可能會支持 WebRTC。然而必須要注意到，微信小程序的 WebView 在安卓平臺上支持 WebRTC，但在 iOS 平臺上面不支持 WebRTC。
雖然這個方案理論上也能在微信小程序上實現連麥直播，但是它有以下的局限性：

• 1）在 iOS 平臺上，微信小程序不支持這個方案，上面已經說過；
• 2）小程序 WebView 不是完整的瀏覽器，要比普通瀏覽器表現差而且有很多的限制；
• 3）開發者和操作系統之間隔了好幾層：微信底層，小程序，WebView，WebRTC，然后才是開發者的小程序應用。每一層的抽象都會帶來性能上的消耗，都會影響到最終的體驗。

這個方案本質上還是一個基于 WebRTC 的解決方案，沒有用到微信小程序開放的實時音視頻能力，而是快速地借助 WebView 組件，劍走偏鋒，十分討巧地在微信小程序里使用了 WebRTC。

7、本文小結

連麥直播技術逐步在原生 APP, 瀏覽器 H5，瀏覽器 WebRTC，微信小程序上延伸，衍生出更加豐富的生態，提供更加便捷和良好的用戶體驗，對視頻直播平臺和用戶來說是好消息。然而，欲帶皇冠，必承其重。特別是在瀏覽器 WebRTC 和微信小程序上，開發者要充分理解這些類型終端的特點和局限，才能更好地在上面利用連麥直播技術進行創新，服務用戶。

喜歡的朋友可以后臺私信【1】獲取學習視頻

附上一份音視頻學習課程大綱給大家

然Flash播放器為互聯網互動立下汗馬功勞，但不得不承認其插件在性能和安全性上都已經遠遠落后時代，跨設備體驗糟糕透頂。在Youtube于今年初將默認網頁視頻轉換成HTML5后，亞馬遜旗下的知名游戲直播平臺Twitch也開始從Flash向HTML5邁步。據稱，雖然視頻仍然為Flash格式播放，但目前Twitch的默認播放控件已經全面轉換成HTML5播放器，“這是實現全面轉換的重要一步。”

相信有不少熱衷于游戲的玩家經常在Twitch上收看玩家的游戲直播，相信轉換至HTML5播放器后Twitch的流暢度和安全性會提升不少，播放界面也已經經過全新設計，簡潔便利不少，自適應比特率功能也能夠讓玩家更流暢地根據自身網速收看直播。

(來源：cnbeta）

鋒網按：本文作者蔣海兵，趣拍產品總監，直播行業老兵。

移動直播行業的火熱會在很長一段時間內持續，通過和各行業的整合，從而成為具有無限可能性的行業。主要有以下三個原因：

第一，移動直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，完全順應了互聯網時代的開放性原則，能刺激更多人去創造和傳播優質內容。

第二，網絡帶寬和速度在逐漸提高，網絡成本在逐漸下降，為移動直播提供一個極佳的發展環境。文字、聲音、視頻、游戲等都會在移動直播中呈現，創造出更加豐富的用戶體驗。直播可以以SDK的形式接入到自己的應用中，比如，教育領域中的課后輔導完全可以以直播的形式開展業務、電商也可借助直播讓用戶挑選商品，促進銷售。

第三，一個與VR/AR技術相結合的移動直播為整個行業的未來提供了新的發展空間。VR/AR直播能夠讓用戶身臨其境，帶動主播與觀眾更貼近真實的互動，大大提高平臺的用戶參與度。

當下，有技術實力和流量優勢的互聯網從業者都不愿錯過直播這個風口，如何快速搭建一個直播系統成了大家關心的問題，我想和大家分享下我的經驗。我從事于一家直播產品開發商，我們的產品為了快速趕上市場，使用了云服務提供商的直播SDK。

從業者都知道，一個完整直播產品應該包含以下環節：推流端（采集、前處理、編碼、推流）、服務端處理（轉碼、錄制、截圖、鑒黃）、播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）。 下面我就一一講述下直播SDK在各個環節所做的工作。

一、移動直播推流端需要做哪些工作？

直播推流端即主播端，主要通過手機攝像頭采集視頻數據和麥克風采集音頻數據，經過一系列前處理、編碼、封裝，然后推流到CDN進行分發。

1、采集

移動直播SDK通過手機攝像頭和麥克風直接采集音視頻數據。其中，視頻采樣數據一般采用RGB或YUV格式、音頻采樣數據一般采用PCM格式。采集到的原始音視頻的體積是非常大的，需要經過壓縮技術處理來提高傳輸效率。

2、前處理

在這個環節主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標配功能。我們調研中發現太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印并回放留存15天以上。

美顏實際上是通過算法去識別圖像中的皮膚部分，對皮膚區域進行色值調整。通過顏色對比找到皮膚區域，可以進行色值調整、添加白色圖層或調整透明度等來達到美白效果。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持iOS和Android，支持自己寫算法實現自己最理想的效果。GPUImage內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了。

3、編碼

為了便于手機視頻的推流、拉流以及存儲，通常采用視頻編碼壓縮技術來減少視頻的體積，現在比較常用的視頻編碼是H.264。在音頻方面，比較常用的是AAC編碼格式，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮后的視頻在播放時必須進行解碼。

相較于之前的H.264，2012年誕生的H.265編解碼標準有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低于1.5Mbps的網絡也能傳輸1080p的高清視頻。像阿里云、金山云都在推自己的H.265編解碼技術，隨著直播的快速發展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。

H264和H265個模塊技術差異：

另外，硬件編碼已經成為移動直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在iOS平臺上硬件編碼的兼容性比較好，可以直接采用，但在Android平臺上，Media Codec編碼器針對不同的芯片平臺表現差異還是非常大的，要完全實現全平臺兼容的成本還是非常高的。

4、推流

要想用于推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。常用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時通常在1–3秒，對于移動直播這種實時性要求非常高的場景，RTMP也成為移動直播中最常用的流傳輸協議。最后通過一定的Qos算法將音視頻流數據推送到網絡斷，通過CDN進行分發。在直播場景中，網絡不穩定是非常常見的，這時就需要Qos來保證網絡不穩情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網絡狀況，動態碼率和幀率也是最常用的策略。

當然，在網絡傳輸方面全部自己來做基本不現實，找提供推流服務的CDN服務商提供解決方案是最好的選擇。據了解，阿里云是國內唯一能自研CDN緩存服務器的廠商，性能非常有保障。當然，大多數直播平臺都會同時接入多個視頻云服務提供商，這樣可以做拉流線路互備，對推流后視頻集群再進行優化也可提高直播的流暢性和穩定性。

二、服務端處理需要做哪些工作？

要想適配各終端和平臺，服務端還需要對流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不同網絡和分辨率的終端設備。

1、截圖、錄制、水印

像阿里云等云服務商都提供了實時轉碼技術，將用戶推流碼率較高（比如720P）實時轉化成較低清晰度（比如360P）的流以適應播放端的需求。如果要自己搭建實時轉碼系統，這個成本是極高的，一臺8核設備只能實時轉10路流，如果一個正常的直播平臺有1000路流，就需要100臺設備，加上后期的運維成本，一般公司就吃不消了。

2、鑒黃

2016年4月14日，文化部查出了斗魚、虎牙、YY、熊貓TV、六間房、9158等涉嫌提供含宣揚淫穢、暴力、教唆犯罪的網絡直播平臺，被列入查處名單。政府介入管制有利于直播行業打造健康的生態，進入良性發展。這也意味著為了安全直播產品鑒黃成了必需環節，使用技術手段去鑒黃是移動直播平臺必然采用的方案。

市面上提供鑒黃服務的方案主要有兩種：

第一種是對視頻進行截圖，然后對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，經過服務端分析返回結果。通常由業務系統接入鑒黃服務，根據鑒黃結果對直播流進行控制，如切斷直播流、封禁賬號等。

第二種是和CDN結合，直接對直播流進行分析，識別結果分為色情、疑似色情、性感和正常，業務系統根據識別結果直接控制直播流。典型的企業是Viscovery，這套方案的優點是實時性保證比較好，缺點是必須部署到CDN或自己的機房，使用成本相對高一些。

還有一種一站式直播解決方案提供商，他們的做法是，用戶只需在控制臺對鑒黃服務進行配置就可以針對每個應用、每一路直播流進行實時審核。在控制臺中，云服務商實時將鑒黃結果返回，用戶可以直接查看色情直播和違規界面的截圖，同時可以對直播流進行控制，切斷問題直播流。該服務商還提供了短信、郵件和站內信功能，避免漏掉任何一個非法視頻，給平臺造成損失，我們就使用了這種方式。

三、播放器端需要做哪些工作？

在播放器端如何做到秒開，直播過程中保證畫面和聲音清晰度的同時，穩定、流程、無卡頓的直播流量，這些工作都需要播放器端配合服務端來做優化，做到精確調度。

1、拉流

拉流實際是推流的逆過程。首先通過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協議，開源軟件和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播，直播延遲一般在1–3秒。

HLS是蘋果提出的基于HTTP的流媒體傳輸協議，HTML5可以直接打開播放，通過微信、QQ等軟件分享出去，用戶也可以直接觀看直播，可以說移動直播app，HLS拉流協議是必須支持的，缺點是延遲通常大于10秒。FLV（HTTP-FLV）協議是使用HTTP協議傳輸流媒體內容的一個協議，也不用擔心被Adobe的專利綁架，直播延遲同樣可以做到1–3秒。

各拉流協議的差異：

我們使用的云服務的直播拉流技術提供了以上三種格式，滿足不同業務場景的需求，如對即時性要求較高或有互動需求的可以采用RTMP或FLV格式進行直播拉流播放；對于有回放或跨平臺需求的，推薦使用HLS。當然，三種協議是可以同時使用的，分別用到自己的場景就可以了。

2、解碼和渲染

拉流獲取封裝的視頻數據后，必須通過解碼器解碼、渲染后才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數據中提取原始數據。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取后的原始數據，并非原始采樣數據，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數保留最好的原始畫面，成為了各視頻公司的核心機密。

考慮對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，iOS系統由于硬件比較單一、比較封閉，支持的比較好，Android系統由于平臺差異非常大，編解碼要完全兼容各平臺還需要很多工作要做。

四、移動直播中的交互系統

移動直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，交互系統涉及消息的實時性和互動性，在技術實現上大多是使用IM的功能來實現的。對于在線人數比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解服務器壓力，在產品策略需要做一些必要的優化。

1、聊天室

移動直播中的彈幕交互是用戶和主播互動的主要方式，實際上就是IM中的聊天室功能。聊天室和群聊功能類似，但聊天室的消息是不需要分發給不在線的用戶的，歷史消息也不需要查看，用戶只有進入聊天室后才能查看聊天消息和群成員信息。面對復雜多變的網絡狀況，還需要根據用戶位置就近選擇近對應運營商的單線機房接入彈幕消息服務，讓彈幕更及時。

2、禮物系統

禮物系統更是絕大多數移動直播平臺的標配了，它是這些平臺主要的收入來源。送禮物的形式也增強了用戶和主播之間的互動交流，也是主播依賴平臺的最主要原因。

禮物的收發在技術實現上也是用聊天室接口做的，通常采用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。

以上就是我們在使用了第三方SDK服務后總結出來的直播產品經驗，希望能幫助到創業者和從業者們。