HaaS RTC背景介紹
HaaS RTC是阿裡雲IoT聯合視訊雲開發的IoT裝置端上的實時通訊服務，主要面向直播，音視訊通話等各種場景。HaaS700是我們HaaS家族新推出的多媒體開發闆，它運作AliOS Things作業系統（RTOS），內建了Camera，音視訊等多媒體能力，目前HaaS700中內建了HaaS RTC音視訊對講方案。
在RTC技術方案中，目前最具代表性的就是WebRTC，WebRTC是 Google 的一個專門針對網頁實時通信的标準及開源項目，隻提供了基礎的前端功能實作，包括編碼解碼和抖動緩沖等，開發者若要基于 WebRTC 開發商用項目，那麼需要自行做服務端實作和部署，信令前後端選型實作部署，以及手機适配等一系列具體工作；在此之外還要在可用性和高品質方面，進行大量的改進和打磨，對自身開發能力的門檻要求非常高。一個專業的 RTC 技術服務系統，需要除了涵蓋上述的通信環節外，實際上還需要有解決網際網路不穩定性的專用通信網絡，以及針對網際網路信道的高容忍度的音視訊信号處理算法。
從技術角度出發，兩個裝置之間的通信可以是裝置對裝置（P2P），也可以是裝置-服務端-裝置，裝置對裝置方案看起來是一個很直覺的想法，并且還可以節約流量（不需要通過伺服器轉一道），但是這種模式是有一定局限性的，它更多的是服務一對一的音視訊對講，并且這種裝置還不能太低端，在沒有服務端介入的情況下，特别是IOT領域，低端裝置要做到适應各種場景（抗網絡丢包，NetEQ，音頻3A等各種算法）的能力是不現實的。而裝置-服務端-裝置這種模式，可以把一些耗CPU，耗記憶體的工作放到服務端，能夠做到滿足各種不同能力的IoT裝置使用者體驗，同時整體技術方案也可以平滑适配目前新興的直播等領域。在HaaS RTC中，我們采用的是裝置-服務端-裝置的整體解決方案。
HaaS RTC技術方案是在視訊雲基礎上搭建的，它主要關注的是如何在低端的IoT裝置上打造跨裝置，跨系統的音視訊方案，在高可靠，低成本的基礎上，為千萬級别的IoT多媒體裝置帶來實時通訊能力。目前在HaaS700的開發闆上，支援裝置和裝置對講，裝置和手機對講以及裝置和PC對講。
裝置對裝置
這裡裝置的概念指的是除了手機，平闆以及PC類的其他IoT裝置, 在現實生活中，我們常見的音視訊通話裝置有可穿戴手表（兒童手表），公網對講機以及智能門禁對講等，音視訊通話能力在這些裝置中是具備主導屬性的，不同的裝置場景在産品化過程中的技術要求有很大的不同。比如在兒童手表中，我們需要考慮功耗問題，通過對音視訊的編碼格式，幀率，軟硬體的編解碼還有參數的調整，盡可能的降低裝置功耗，確定通話時長，同時，還需要保證視訊通話的高清晰度和高保真，在視訊通話的場景中，由于孩子始終處于移動的狀态，4G信号極其容易不穩定，但是家長和小孩需要能夠在視訊通話的過程中流暢且清晰的進行溝通，這是尤為重要的；而在門禁對講中，由于裝置本身是得到持續供電的，是以功耗問題不需要特别關注，同時國内的可視對講系統通常應用于大型的住宅小區，很多是上千戶，甚至上萬戶的小區，對聯網戶數容量及穩定性要求更高，可視對講系統的主流仍然是采用RS-485總線信号傳輸，有向數字化發展的趨勢，國内采用TCP/IP的戶數容量更大的可視對講系統正在逐漸走向成熟，是以在門禁對講領域，我們更需要關注高容量，穩定性等問題。HaaS700考慮到了這些場景的需求，在功耗以及穩定性方面都做了大量的優化，可以應用在各種音視訊對講或直播等場景中。
裝置對手機
随着網際網路以及裝置智能化程序加速，裝置和手機之間的通信已經越來越常見。比如手表和手機視訊通話，直播裝置和手機之間的視訊直播，智能音箱和手機之間的視訊通話等。在這些場景中，裝置和手機之間存在比較大的差異，包括螢幕分辨率差異，視訊編解碼能力差異，CPU運算能力差異，網絡帶寬差異等等，這些差異決定了在音視訊通話整體方案中，需要從技術角度做到各種差異性的屏蔽，比如常見的音視訊編解碼格式适配，螢幕分辨率适配，網絡擁塞控制算法調整發送碼率解決網絡帶寬變化帶來的資料傳輸問題，NetEQ算法解決網絡抖動導緻的音頻播放不平滑問題等等。同時，在不同的場景中，對音視訊延遲的要求也不盡相同，比如音視訊通話場景延遲要求要高于直播場景，在音視訊通話場景中，需要盡可能確定音視訊發送端到接收端的時延在1S以内，這對使用者體驗尤為重要。
裝置對PC
在移動網際網路時代，使用者的通信方式更多的轉向移動裝置，裝置和PC之間的通信越來越偏向行業化的趨勢發展，特别是近兩年直播的興起以及疫情的影響，加速了各種電商直播，線上教學以及線上會議的普及化，不同于裝置對裝置以及裝置對手機之間的一對一音視訊通話場景，電商直播主要是一對N，而線上教學，線上會議更是N對N的關系，這意味這要滿足線上會議等場景，我們需要實作N路推流，N路拉流，從技術角度來說，目前已經有比較成熟的技術方案，但對于裝置端，主要的挑戰是裝置性能（CPU，記憶體帶寬等），特别是一些低端的裝置，在這種情況下，我們可以把一些性能和記憶體要求比較高的操作放在服務端，比如N路推流在服務端建立映射，裝置端隻推一路，N路拉流在服務端進行，合成一路後，再下發到裝置端。把這些性能要求比較高的操作轉嫁到服務端後，裝置端實際上還是一路拉流和一路推流，性能要求和一對一的音視訊通話并無差別。在HaaS RTC中，我們打通了裝置和PC之間的音視訊通話，進一步推進了HaaS裝置通信跨系統跨硬體平台的能力，實作真正的三端互通。
此處為語雀視訊卡片，點選連結檢視：
HaaS音視訊對講-靜音.mp4HaaS RTC技術方案
HaaS RTC支援在RTOS級别的系統上搭建音視訊通話能力，為此，我們做了整體的架構調整和性能優化。差別于Android和Linux系統，RTOS作業系統一般CPU能力弱，記憶體小，比如HaaS700的CPU是ARM A7單核800Hz, 剩餘可用記憶體24MB左右，這要求我們需要盡可能的減少記憶體消耗，重構線程模型，比如一些串行或者不是很耗時操作的線程合并，降低簡單線程的線程棧空間等，同時，由于RTOS系統是單程序，它的線程排程和Android和Linux有很大的差別，對于需要及時響應的收發資料線程，我們需要顯式的提高線程排程優先級，避免出現需要及時響應的線程長時間沒有被排程到。除了一些線程排程和線程模型的調整，我們還需要進行業務邏輯上的優化，比如縮減高CPU消耗，低回報的業務子產品，降低CPU消耗，限制業務邏輯隊列記憶體配置設定增長空間，避免某些業務場景中記憶體持續增長導緻系統奔潰。
在架構層面，為了快速适配不同的系統平台，HaaS RTC打造了系統和驅動統一适配層，包括Camera，Display，渲染，編解碼以及系統線程，時鐘等，這樣的好處是在不同的系統平台上，HaaS RTC核心代碼不需要做修改，隻需要在适配層做一些簡單的底層适配。在适配層之上，包括音視訊推流，音視訊拉流，視訊雲SDK以及信令系統子產品，其中音視訊推流子產品主要負責推流通道建立，編碼後的音視訊資料推送，音視訊拉流子產品負責拉流通道建立，接收服務端發送的音視訊碼流，視訊雲SDK主要負責音視訊資料傳輸，以及适應傳輸過程中的網絡抖動算法實作，包括帶寬估計，NetEQ等等，信令系統負責信令的呼叫控制，包括呼叫響應，呼叫接聽，呼叫挂斷等流程中涉及到的各種資訊控制管理，在音視訊對講場景下，它需要和服務端配合，比如雙方建立會話過程中，服務端需要查詢驗證呼叫方和被呼叫方賬号資訊和裝置資訊，經過驗證後，通知被呼叫方，被呼叫方可以接聽或者挂斷呼叫，服務端根據被呼叫方的回報建立會話通道或中止會話流程。RTC Manager是基于音視訊推流，音視訊拉流以及信令和系統能力之上的RTC管理子產品，在推流場景中，它負責音頻和視訊資料采集，并進行音視訊編碼，編碼器輸出的碼流傳到推流子產品并上傳到服務端，在拉流場景中，它負責接收音視訊推流子產品下發的音視訊資料，并通過音視訊解碼器進行解碼操作，最終通過播控子產品播放音頻和視訊畫面。除此之外，RTC Manager負責向應用層暴露RTC場景的所有能力，應用層通過RTC Manager暴露的接口實作視訊通話能力。
HaaS RTC裝置端技術方案隻是滿足了RTOS和Linux裝置端上的技術能力支撐，對于一套完整的RTC解決方案，還需要移動端以及強大的服務端能力支撐，移動端需要解決各種手機平台的能力适配，讓使用者獲得一緻的使用者體驗，服務端需要提供大規模實時的音視訊推流，拉流能力，能夠配合裝置端應對網絡波動影響帶來的丢包，延遲等各種問題。
性能優化
我們常見的RTC場景大部分是基于成熟的系統上，比如IOS，Android以及Windows等等，這些系統一般都具備性能比較高的處理器以及比較大的記憶體容量，而RTC場景本身對CPU和記憶體要求也是比較高的（曾經微信視訊通話一段時間後，手機燙成暖寶寶的體驗還記憶猶新）。對于低端裝置，如果要內建RTC能力，需要我們針對RTC場景做大量的性能，記憶體調優工作。相比于動辄4核CPU，記憶體2G的Android裝置，HaaS700CPU是arm A7單核，頻率隻有800MHz，并且剩餘可用記憶體不到24MB。
| 性能名額 | 資料值 |
| CPU占用率 | 100% |
| 記憶體 | 24MB |
| 幀率 | 10fps |
| 分辨率 | 320x240 |
| 碼率 | 100K |
| 視訊延遲 | >6S |
| 音頻延遲 | >3S |
| 音頻3A | Enable |
HaaS700 RTC性能（優化前）
在HaaS700上剛bring up RTC時，CPU占用率100%，音視訊延遲大于6S，系統正常運作時間不超過1分鐘，因為記憶體快速增加很快就超過24MB，導緻系統crash。特别是在弱網情況下，由于資料包發送速率降低，帶寬估計子產品需要持續運轉，這不僅提高了CPU占用率，同時還導緻發送隊列碼流大量堆積，使得記憶體申請持續增長，整體系統基本處于不可用的狀态。是以單純把Android或Linux這種面向偏高端的裝置端系統運作經驗照搬到RTOS級别的低端系統上，是不可行的，我們需要線程級别的代碼重構，功能子產品裁減以及整體的性能和記憶體優化。
| 85% | |
| 12.5MB | |
| 20fps | |
| 640x360 | |
| 400K | |
| <500 MS | |
| <250 MS | |
HaaS700 RTC性能（優化後）
為此，在HaaS700上，我們針對視訊通話場景做了線程級别的代碼重構，并做了大量的性能和記憶體優化，整體性能和記憶體要求達到了可産品化水準，同時，在使用者體驗上，我們對音視訊延遲做了進一步的優化，在裝置對裝置，裝置對手機上都可以達到音視訊通話場景的産品化水準。
小結和展望
自從智能手機出現以來，音視訊通話在現實生活中已經随處可見，目前運用最廣泛的莫過于微信，而近兩年來新興業務的蓬勃發展，讓RTC技術方案得以滲透到各個領域，比如直播，遠端教育，線上會議等等。我們可以預見在不久的将來，RTC技術會有更多的業務形态，特别是需要一些線上線下相結合的領域，值得我們不斷挖掘和探索。比如現在很多餐廳提倡透明衛生廚房，顧客可以通過透明玻璃看到廚師炒菜，讓顧客更放心。這種方式是否可以有更好的表達？如果我們在餐廳廚房按照一個直播攝像頭，顧客在座位上直接掃碼就可以觀看廚房情況，是否可以達到更好的效果？同時，這種模式是不是可以降低餐廳打造安心廚房的改造成本，更容易複制和推廣。