IM 推送保障及網絡優化詳解（三）：如何在弱網環境下優化大數據傳輸？

對於移動 App 來講，IM 功能正變得愈來愈重要，它可以建立起人與人之間的鏈接。社交類產品中，用戶與用戶之間的溝通能夠產生出更好的用戶粘性。
在複雜的 Android 生態環境下，多種因素都會形成消息推送不能及時達到客戶端。另外，不穩定的移動網絡也給數據傳輸的速率和可靠性增長了障礙。
本文詳解了網易雲信 IM SDK 在應對弱網環境、移動端硬件限制以及 Android 複雜的生態現狀時的探索與心得.如何實現不影響用戶體驗的後臺保活，改善的長鏈接加推送組合方案，以及在弱網環境大數據傳輸的優化實踐。

相關閱讀推薦：

• 網易雲信 IM 推送保障及網絡優化詳解（一）如何作長鏈接加推送組合方案
• 網易雲信 IM 推送保障及網絡優化詳解（二）如何實現不影響用戶體驗的後臺保活


在即時通信研發當中，音視頻通話對實時性要求很高，但能夠容忍必定的丟包，因此選擇 UDP 私有協議來作爲底層的傳輸協議。若是隻是普通的 IM 消息，對網絡狀況其實不是太敏感，最多也就是慢一點，菊花轉的久一點。但對於這種視頻電話，若是網絡差了，發生了常常性卡頓，或者是延遲很高，圖像出現花屏，音視頻不一樣步了，這個功能其實也就至關於廢棄了。並且，音視頻數據量自己也比較大，在弱網環境下發生問題的機率就更大了。
爲了提升弱網下的實時音視頻的通話效果，須要使用相關方案來作 QoS 保障：主要包括了基於 UDP 協議的擁塞控制、前向糾錯 FEC 技術及相關的重傳技術。同時網絡層須要可以實時的探測到網絡狀態，做爲底層調整 QoS 策略的依據，同時須要回調上層，來動態調整音視頻的碼率，作到音視頻碼率自適應。經過上面的 QoS 保障，實際測試在 60% 的隨機丟包弱網環境下，音視頻通話還可以正常進行。
下面再來看看對於 HTTP 的優化。圖片語音是 IM 的必需元素，並且自己數據比較大。在弱網環境下，快速的上傳下載，更少的等待時間能夠帶來更好的用戶體驗。

斷點續傳能夠減小因網絡緣由致使的重複傳輸，減小傳輸時間，節省流量。
圖片預加載技術能夠根據不用網絡狀況，在收到消息後，就加載不一樣素質的預覽圖片，甚至直接將原圖預加載，作到用戶點開即看。
圖片和語音文件並無經過長鏈接收發，而是經過 HTTP 去作上傳下載。傳統上經過 HTTP 上傳時，文件會分爲一片一片，傳完一片，收到回包，纔會穿下一個分片，一直到最終傳輸完成。能夠看到，服務器返回 ack 這段時間，上傳通道實際上是空閒的，若是把這段時間利用起來，能夠節約很多上傳時間。Pipeline 就是爲此而來。經過重疊利用 http 請求的響應等待時間，加快傳輸速度。使用 Pipeline，須要修改 HttpClient，同時還須要服務器提供支持。視網絡具體狀況，使用 Pipeline 後，一次上傳能夠減小 20% 至 30% 的時間。
常規發送語音消息須要這幾步，先錄音，而後計算 hash 值，而後上傳，上傳完畢後，服務器計算一下校驗和，經過後語音消息發送成功。在前面錄製語音時，網絡其實也是空閒的。把這段時間利用起來，則能夠減小後面上傳步驟的時間。優化後，流程就變成這樣。在錄製的過程當中，每錄完一段，就做爲一個分片直接上傳。直到最後錄完，計算好 hash，再把最後一個分片帶上 hash 信息上傳。這裏除了客戶端的改動，也是須要服務器支持。服務器在開始接收時，不少信息都不明確，須要開闢緩存來記錄整次上傳過程。對於比較差的網絡，邊錄邊傳的效果會更好，畢竟純語音的比特率並不高，基本都能作到錄完就傳完。

---

隨着即時通信以及音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易雲信官方博客和 GitHub：

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網