對于移動APP來說，IM功能正變得越來越重要，它能夠創(chuàng)建起人與人之間的連接。社交類產品中，用戶與用戶之間的溝通可以產生出更好的用戶粘性。

在復雜的 Android 生態(tài)環(huán)境下，多種因素都會造成消息推送不能及時達到客戶端。另外，不穩(wěn)定的移動網絡也給數據傳輸的速率和可靠性增加了障礙。

本文詳解了網易云信IM SDK在應對弱網環(huán)境、移動端硬件限制以及Android復雜的生態(tài)現狀時的探索與心得.如何實現不影響用戶體驗的后臺保活，改善的長連接加推送組合方案，以及在弱網環(huán)境大數據傳輸的優(yōu)化實踐。

相關閱讀推薦：
網易云信即時通訊推送保障及網絡優(yōu)化詳解（一）如何做長連接加推送組合方案

網易云信即時通訊推送保障及網絡優(yōu)化詳解（三）如何在弱網環(huán)境下優(yōu)化大數據傳輸

如何做長連接

對于?IM?來說，及時的消息推送和較低的電量消耗也并非不可兼得。在傳統(tǒng)上，每個IM客戶端都會各自維護一條與服務器的長連接，自己的消息和信令都在這條長連接上傳遞，每個APP也獨自去心跳，斷線重連等事情。

這種模式比較簡單，不同的APP也是完全隔離的，不會互相影響。但他的缺點也非常明顯，首先是做了很多重復的事情，造成了流量和電量的無謂消耗；第二是要保證所有的進程都能在后臺運行很難。優(yōu)化的方向也就非常明顯了，那就是共享連接，現在絕大部分推送SDK也是這么做的。從這些APP里面選出一個當前正在運行的，或者是被殺概率最低的APP作為總代理，只由這個代理和服務器建立連接，一個手機上的所有其他APP都通過這個代理中轉與服務器通信。但是，IM有一個很基本的要求在這種模式下無法得到滿足：安全。所有APP的消息都經過代理中轉，代理到服務器的連接是加密的，安全的，但到了代理這里，消息都被解開了，因此代理理論上可以看到其他所有APP的來往消息。因此，這種共享長連接的方式并不適用于IM。

雖然共享長連接方式不合適，但仍然提供了一個優(yōu)化的思路。在此基礎上，有另一個可以脫敏共享連接的方式：安全長連接加推送連接模式。

每個APP在使用和真正傳遞數據時，仍然獨立使用自己的安全長連接。而當APP退到后臺一段時間之后，則斷開長連接，然后每個APP開啟一個推送代理，并選擇其中一個和網易云信的推送服務器建立連接，之后當APP有新消息時，就通過這個推送連接傳遞。APP可以自己控制發(fā)出的推送消息的安全級別，可以是包含說話人和消息內容，可以只包含說話人，或者只是一條簡單的有新消息到達的提醒文案。推送到達后，如果是代理APP自己的消息，直接傳遞給代理APP即可。如果是其他APP消息，前面說到過，直接喚醒可能會失敗，而且會導致無謂的電量消耗，所以這里并不直接將提醒傳遞給目標APP，而是由帶來發(fā)出一條通知欄提醒。等用戶去點擊通知欄提醒后，才會把目標APP喚醒。

現在國內的ROM中，華為和小米的系統(tǒng)本來是帶有推送系統(tǒng)，且開放給了第三方APP的。在這兩個系統(tǒng)上，使用系統(tǒng)的推送通道明顯會更加穩(wěn)定，也更加節(jié)省資源。因此在MIUI上，從長連接到推送通道的切換流程仍然和前面的一樣，只是不再使用自己的推送連接，而是將消息轉發(fā)到MIUI的推送服務器，然后轉給MIUI系統(tǒng)的推送代理，然后傳遞給網易云信的APP。華為的推送系統(tǒng)流程也是一樣。不過現在華為和MIUI在推送實現上有一些區(qū)別，例如MIUI的通知欄提醒是在自己的推送代理里完成的，而華為卻是將提醒通知交給APP自己去完成的，另外，他們的通知欄提醒的管理接口也有很多區(qū)別。在APP沒有被禁用的情況下，兩者都可以收到推送，而如果APP已經被禁用了，MIUI的通知欄提醒方式還可以將推送送達，而其他的推送方式則不能送達了。

以上就是在保障消息推送方面所能夠做的所有事情了。如果以后有更多的系統(tǒng)開放自己的推送系統(tǒng)也可以選擇逐步接入，以提高推送到達即時性，減少資源消耗。不過相應的，也要承受不斷加入各種系統(tǒng)的推送SDK，增大發(fā)布包體積的缺點。?

移動通信網絡的三個特點

第一個是慢，尤其是2G，3G網絡，慢的令人發(fā)指。

第二個是斷，手機跟著人不停的移動，網絡也不停的在切換，從wifi到移動網絡，從一個基站到另一個基站，從有信號到沒信號，都可能導致網絡中斷。有些制式的網絡，接打電話也會導致數據網絡斷開。另外，移動基站還有NAT超時，到一個連接上長時間空閑后，基站就會默默的將連接斷開，沒有任何通知。

第三個是貴，這個就不用多說。

三種長連接類型

在網易云信整個通信系統(tǒng)中有3種類型的連接：TCP，UDP，HTTP。雖說這三個并不是同一層的協(xié)議，不過畢竟都在應用的更下層，因此這么劃分也無妨。3種類型的協(xié)議對應了不同的業(yè)務應用。TCP主要是用戶長連接，也就是普通IM消息和信令的傳輸，UDP用于傳輸實時音視頻數據流，而HTTP則主要用在音頻，圖片等文件的上傳下載上。對于不同的業(yè)務，SDK優(yōu)化的關注點會有一些不相同。

IM長連接優(yōu)化怎么做？

第一個是協(xié)議的選擇。前面說，長連接的使用量是最大，選擇一個合適的協(xié)議至關重要。如果是剛開始接觸IM開發(fā)，一般會選擇一些開源的協(xié)議，比如XMPP，SIP等。這是XMPP協(xié)議的一個請求樣例，可以看到是一段XML格式的文本數據。

這是基于SIP的SIMPLE協(xié)議的一個請求樣例，可以看到是一段類似HTTP協(xié)議的文本數據。這些協(xié)議的優(yōu)勢在于開源，有成熟的解決方案可以使用，擴展性好，甚至還可以和其他系統(tǒng)互聯(lián)互通，協(xié)議的可讀性也非常好。但是在普遍比較臃腫，冗余字段很多，在昂貴的移動網絡里面用起來會比較浪費。網易云信采用的是私有的二進制協(xié)議，這是一個請求的數據樣例，這里是把二進制數據轉為了16進制顯示出來，每個字節(jié)這里顯示為兩個字符。可以看到二進制協(xié)議的特點在于完全失去了可讀性，但是，卻帶來極高的表達效率，相對于文本協(xié)議，可以節(jié)省非常多的數據流量。

另一個例子是登錄的優(yōu)化。由于移動網絡經常斷開，所以登錄常常是心跳之外交互最多的協(xié)議了。使用量越大，優(yōu)化就越有意義。一般而言，登錄會經過這么幾步。

第一步是LBS。這里的LBS不是經常說的基于地址位置的服務，在不同的廠商可能也有不同的叫法，反正作用都是獲取服務器的IP地址。像云信這種需要提供全球服務的系統(tǒng)，在世界各地都要部署服務器，用戶登錄時，肯定要選擇一臺最優(yōu)的服務器接入服務。通過lbs，客戶端可以獲取離自己最近，連通性最好的服務器連接機IP地址，服務器也可以據此做負載均衡。

拿到服務器連接機IP后，客戶端就去連接該服務器。

連接成功，需要有一次握手。這個握手不是TCP的三次握手，而是為了建立安全連接，同服務器協(xié)商加密算法和加密密鑰。

然后就發(fā)送登錄請求，這里會帶上用戶認證信息，本機設備信息等數據。

登錄成功之后，就是同步數據，包括離線消息，用戶信息，群組信息等。一般而言，這里不會去做全量同步，而是采用基于時間戳的增量同步。

在移動網絡上，每一次交互都需要比較長的時間，同時，每一次網絡請求電量消耗也是很大的。所以，優(yōu)化的方向就是盡量減少交互次數，而方法則是合并請求，并行操作以及省略請求。

LBS和連接這兩個步驟是可以并行完成的。如果前面已經獲取過LBS，這里可以有之前的緩存地址，如果沒有，可以先連一個默認地址。

其次是握手和登錄也可以并行操作。在握手包中，就可以把加密后的登錄包直接帶上去了。如果是斷線重連，網易還可以簡化登錄，直接帶上上一次登錄的會話ID，一來減少服務器鑒權壓力，二則可以直接帶回在斷線期間是否有未讀消息等數據，如果沒有，則能直接將同步這一步省略掉。如果有，同步也可以只做部分同步，只去拉去離線消息即可。等到APP切換到前臺，才去同步其他的信息。

通過這些優(yōu)化，登錄時間可以降為原來的1/2到1/3，登錄的流量消耗也可以節(jié)省30%左右。

總結

以上是生活随笔為你收集整理的IM推送保障及网络优化详解（二）：如何做长连接加推送组合方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。