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

標籤：應用   第三方   心跳協議   移動網路   頻繁   最大   不同的   出錯   訊息傳遞   

《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 即時通訊開發小結（二）