《Android 即時通訊開發小結》基于IM Andriod 開發的各種常見問題，結合網易云信即時通訊技術的實踐，對?IM 開發做一個全面的總結。

?

相關推薦閱讀：、

Android即時通訊開發小結（一）

移動IM開發指南1：如何進行技術選型

移動IM開發指南2：心跳指令詳解

移動IM開發指南3：如何優化登錄模塊

?

建立安全連接

安全性是 IM 軟件的另一個硬需求。消息傳遞時如果通信數據如果被第三方截取，要能保證別人不能獲取到真實內容。安全連接的過程可以參考 HTTPS 的方式，由服務器將證書下發給客戶端，客戶端產生一個對稱的密鑰，并通過服務器證書加密后交給服務器，之后的通信就全部使用這個對稱的密鑰來加密。當然，這里有兩點需要和 HTTPS 有所區別，第一是證書的獲取方式，HTTPS 中是由專門機構去驗證證書合法性的，IM 的客戶端肯定不會這么去做，為了防止獲取證書的過程被人截獲，然后篡改證書，可行的方式是直接在客戶端安裝包中直接把證書打進去，該證書可以隨著客戶端軟件升級一起升級，也可以在加密連接之后通過協議升級。第二個問題是對稱加密算法的選擇，因為密鑰的生命周期是跟隨一次連接的，時間并不長，而移動 App 對于電量消耗非常敏感，因此加密算法應盡量選擇較為簡單的類型，例如 RC4。

?

心 ?跳

心跳可以分為 TCP 的協議層心跳和 App 的應用層心跳。一般我們都使用應用層心跳，一來便于服務器擴展（比如哪天我們可以換成 UDP 來傳），二則是可以更靈活控制心跳間隔。

心跳協議僅僅是用來連接保活，其內容應當盡量精簡，除了包頭中必要的部分，包體的可選包頭都不存在。

對于不同的網絡環境，心跳可以采用不同的時間間隔。在不同網絡環境下，間隔的選擇可以參考微信智能心跳方案。

?

斷線重連

客戶端掉線的原因無非兩種，客戶端網絡掛了，服務器掛了。客戶端網絡掛了也分兩種，一種是本機就能感知到的網絡連接斷開，另一種是本機網絡是好的，但互聯網連接是不同的，對應到 Android API上，就是 NetworkInfo 的 isAvailable 和 isConnected。當然這個地方的 isConnected 不一定可靠，因為它是靠連制定服務器來確定的，那個服務器誰知道有沒有問題。

掉線后，根據不同的狀態需要選擇不同的重連間隔。如果是本地網絡出錯，并不需要定時去重連，這時只需要監聽網絡狀態，等到網絡恢復后重連即可。如果網絡變化非常頻繁，特別是 App 處在后臺運行時，對于重連也可以加上一定的頻率控制，在保證一定消息實時性的同時，避免造成過多的電量消耗。

而如果掉線是因為本機網絡連不通互聯網，或者是服務器掛了，重連間隔的選擇就非常重要了。

首先，如果程序是在前臺，用戶正在使用我們的 App，重連間隔應更加頻繁，使得用戶反饋更加及時，如果程序處于后臺運行，則為了省電，可以適當延長重連間隔。

其次，隨著重連次數的增加，說明服務器短時間內恢復的可能性逐漸降低，重連間隔也應隨之延長（倍數增長）。但應該設置一個最大的重連間隔，當到達最大間隔時，不再增加。

第三，重連間隔的增加不應當是固定的，而應該增加一個隨機退避策略。以免如果是服務器宕機造成掉線，所有客戶端的重連時間點都是一樣的，當服務器恢復后，同一個時間點所有客戶端同時連接服務器，造成服務器不堪擁堵，再次宕機。活生生的例子請參考環信去年的宕機時間。

總結起來，重連間隔可表述如下：

多媒體數據管理

IM 系統中另一個重頭戲是多媒體數據。由于移動網絡比較慢，流量又貴，在移動端針對這些問題必須要做一些處理。在上傳時，盡量減少上傳時間，在下載時，能讓用戶盡快看到內容。同時，盡量節省流量，減少不必要的流量消耗。

文本消息因為比較小，可以直接通過長連接傳輸。但對于多媒體文件，通過長連接來傳輸則不合適，長連接服務器不會對大文件傳輸做針對性優化，大量的多媒體文件數據會直接搶占其他信令消息和文本消息的貸款資源。因此，多媒體消息會通過另外的通道，到專門的文件服務器存取。

在下載時，對于不同的網絡環境，可以采用不同的預取策略。在 WiFi 環境下，由于無需考慮流量問題，在收到消息后，我們就能立即把包含的多媒體文件下載下來。而在移動網絡中，則應當等到用戶真正看到該多媒體消息時，才去下載。

?

圖 片

上傳時，現在手機攝像頭的像素動輒上千萬，一張圖片隨隨便便就好幾M，然而，通過 IM 軟件傳輸的圖片，通常對于質量要求并不會太高，如果我們直接將好幾M的圖片直接上傳，往往費力又不討好。在上傳之前，將圖片像素降低，并進行壓縮，可以明顯的減少上傳轉菊花的時間，減少用戶流量消耗。如果用戶確實要求圖片質量，則提供一個原圖選項。

如果是使用 http 上傳，大文件會被分成多個數據塊上傳，前一個數據塊傳輸成功后，再傳輸下一個。斷線重傳時，也是以數據塊作為最小重傳單元。針對不同的網絡類型，數據塊大小不同。在較好網絡下(wifi/4g/3g)，數據塊可以比較大，這樣可以減少交互時間，加快傳輸熟讀，而在弱網環境，數據塊應當設置的比較小，以降低傳輸失敗概率，減少重傳流量消耗。

使用 http 上傳的另一個優化技術是使用 pipeline。在不使用 pipeline 時，上傳一個數據塊需要等到前一個數據塊傳輸成功才行，數據通道是單工的。使用pipeline則可以將數據通道變為雙工的，一個數據塊傳輸完成后，不必等到回包，就能直接上傳下一個數據包，能節省一次數據回包延時。

下載時，在消息展示區顯示的通常只是一個很小的圖片，這時候只需要下載對應大小的縮略圖即可，無需下載原圖。甚至，這里可以將比縮略圖更小的圖片二進制數據直接放到消息體中下發，并展示給用戶一個高斯模糊后的效果圖，在保證最低可用的情況下，減少用戶等待時間，提高用戶體驗。

?

語 ?音

對于不同的網絡環境，采取不同質量的語音編碼算法，在較好網絡時，使用高質量語音，而在弱網環境下，則使用較低質量，優先保證可用性。

為了減少用戶等待時間，還可以采取邊錄邊傳的策略。由于錄音時間比較長，在錄制的過程中，我們就可以將錄好的部分先傳到服務器，等到錄音完成，只需要上傳最后一個數據包，并告知服務器錄音完成即可，基本上可以做到錄完即傳完，無需等待。

語音消息沒有縮略圖，因此語音下載基本就只能實打實的將原始文件下載下來。

?

以上就是網易云信對于Android 即時通訊開發的小結，歡迎各位積極提問，共同探討。

總結

以上是生活随笔為你收集整理的Android 即时通讯开发小结（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

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