視頻直播之優化移動端WebRTC通訊

序言

本文探討範圍僅限於移動端優化，android和iOS都適用。

慣例，先上介紹

官網介紹

WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

中文翻譯大體意思：WebRTC是開源且免費的，能夠用於瀏覽器和移動端的實時視頻通信，是谷歌2010年以6820萬美圓收購Global IP Solutions公司而得到的一項技術。

參數配置

WebRTC通訊最主要的配置，其實都在PeerConnection.java下的RTCConfiguration這個類裏面，咱們着重來看下這個類有什麼。

public static class RTCConfiguration {

 public IceTransportsType iceTransportsType;

 public List<IceServer> iceServers;

 public BundlePolicy bundlePolicy;

 public RtcpMuxPolicy rtcpMuxPolicy;

 public TcpCandidatePolicy tcpCandidatePolicy;

 public CandidateNetworkPolicy candidateNetworkPolicy;

 public int audioJitterBufferMaxPackets;

 public boolean audioJitterBufferFastAccelerate;

 public int iceConnectionReceivingTimeout;

 public int iceBackupCandidatePairPingInterval;

 public KeyType keyType;

 public ContinualGatheringPolicy continualGatheringPolicy;

 public int iceCandidatePoolSize;

 public boolean pruneTurnPorts;

 public boolean presumeWritableWhenFullyRelayed;

 public RTCConfiguration(List<IceServer> iceServers) {

 iceTransportsType = IceTransportsType.ALL;

 bundlePolicy = BundlePolicy.BALANCED;

 rtcpMuxPolicy = RtcpMuxPolicy.NEGOTIATE;

 tcpCandidatePolicy = TcpCandidatePolicy.ENABLED;

 candidateNetworkPolicy = candidateNetworkPolicy.ALL;

 this.iceServers = iceServers;

 audioJitterBufferMaxPackets = 50;

 audioJitterBufferFastAccelerate = false;

 iceConnectionReceivingTimeout = -1;

 iceBackupCandidatePairPingInterval = -1;

 keyType = KeyType.ECDSA;

 continualGatheringPolicy = ContinualGatheringPolicy.GATHER_ONCE;

 iceCandidatePoolSize = 0;

 pruneTurnPorts = false;

 presumeWritableWhenFullyRelayed = false;

 }

 };
複製代碼

1. IceTransportsType：收集的策略類型，目前可供選擇的有ALL(所有收集),NOHOST(不收集host類的策略信息),RELAY(只使用服務器的策略信息，簡言之就是不經過P2P，只走服務端流量),NONE(不收集策略信息，目前做用未知)。通常來講，若是你想減小流量，那麼就用ALL，WebRTC會在能打通P2P狀況下使用P2P；若是你想要保證客戶端的聯通率，那麼RELAY是你最好的選擇。
2. bundlePolicy：協商策略，balanced, max-compat, max-bundle,基本上是選擇max-bundle，主要是防止另外一個客戶端屬於策略不可協商型。
3. rtcpMuxPolicy：實時傳輸控制協議多路策略，negotiate, require，第一個是獲取實時傳輸控制協議策略和實時傳輸協議策略，第二個只獲取實時傳輸協議策略，若是另外一個客戶端不支持實時傳輸控制協議，那麼協商就會失敗。Tiki客戶端測試發現Require比較適合移動客戶端。
4. tcpCandidatePolicy：TCP候選策略控制開關，只有Enable和Disable，TCP策略雖然有握手來保證傳輸到達率，但這也是效率上最致命的，會極大拉低視頻傳輸效率，因此建議不開啓，除非有特別的需求。
5. candidateNetworkPolicy：候選網絡策略，屬於新出的策略，有ALL和LowCost兩個值，暫時未知做用，若是有童鞋瞭解的話，能夠交流下。
6. iceServers：服務端的候選地址，主要是用於客戶端之間創建鏈接前的通訊。
7. continualGatheringPolicy：收集策略時間段，有GATHER_ONCE和 GATHER_CONTINUALLY兩種值，默認值爲GATHER_ONCE，能夠不用改。
8. keyType：加密類型，若是沒有特殊需求，不建議更改。
9. 其餘參數，有些屬於M52以後新加的類型，尚未測試過，不敢妄下定論，還有一些屬於測試後以爲不須要修改默認值的。

結語

以上就是本人對WebRTC通訊上的一些優化，若是你們以爲哪裏有疑問或者錯誤，能夠提出交流下。

遷移自個人簡書