《Android 即時(shí)通訊開發(fā)小結(jié)》基于IM Andriod 開發(fā)的各種常見問題，結(jié)合網(wǎng)易云信即時(shí)通訊技術(shù)的實(shí)踐，對?IM 開發(fā)做一個(gè)全面的總結(jié)。

?

相關(guān)推薦閱讀：、

Android即時(shí)通訊開發(fā)小結(jié)（一）

移動(dòng)IM開發(fā)指南1：如何進(jìn)行技術(shù)選型

移動(dòng)IM開發(fā)指南2：心跳指令詳解

移動(dòng)IM開發(fā)指南3：如何優(yōu)化登錄模塊

?

建立安全連接

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

?

心 ?跳

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

心跳協(xié)議僅僅是用來連接保活，其內(nèi)容應(yīng)當(dāng)盡量精簡，除了包頭中必要的部分，包體的可選包頭都不存在。

對于不同的網(wǎng)絡(luò)環(huán)境，心跳可以采用不同的時(shí)間間隔。在不同網(wǎng)絡(luò)環(huán)境下，間隔的選擇可以參考微信智能心跳方案。

?

斷線重連

客戶端掉線的原因無非兩種，客戶端網(wǎng)絡(luò)掛了，服務(wù)器掛了。客戶端網(wǎng)絡(luò)掛了也分兩種，一種是本機(jī)就能感知到的網(wǎng)絡(luò)連接斷開，另一種是本機(jī)網(wǎng)絡(luò)是好的，但互聯(lián)網(wǎng)連接是不同的，對應(yīng)到 Android API上，就是 NetworkInfo 的 isAvailable 和 isConnected。當(dāng)然這個(gè)地方的 isConnected 不一定可靠，因?yàn)樗强窟B制定服務(wù)器來確定的，那個(gè)服務(wù)器誰知道有沒有問題。

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

而如果掉線是因?yàn)楸緳C(jī)網(wǎng)絡(luò)連不通互聯(lián)網(wǎng)，或者是服務(wù)器掛了，重連間隔的選擇就非常重要了。

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

其次，隨著重連次數(shù)的增加，說明服務(wù)器短時(shí)間內(nèi)恢復(fù)的可能性逐漸降低，重連間隔也應(yīng)隨之延長（倍數(shù)增長）。但應(yīng)該設(shè)置一個(gè)最大的重連間隔，當(dāng)?shù)竭_(dá)最大間隔時(shí)，不再增加。

第三，重連間隔的增加不應(yīng)當(dāng)是固定的，而應(yīng)該增加一個(gè)隨機(jī)退避策略。以免如果是服務(wù)器宕機(jī)造成掉線，所有客戶端的重連時(shí)間點(diǎn)都是一樣的，當(dāng)服務(wù)器恢復(fù)后，同一個(gè)時(shí)間點(diǎn)所有客戶端同時(shí)連接服務(wù)器，造成服務(wù)器不堪擁堵，再次宕機(jī)。活生生的例子請參考環(huán)信去年的宕機(jī)時(shí)間。

總結(jié)起來，重連間隔可表述如下：

多媒體數(shù)據(jù)管理

IM 系統(tǒng)中另一個(gè)重頭戲是多媒體數(shù)據(jù)。由于移動(dòng)網(wǎng)絡(luò)比較慢，流量又貴，在移動(dòng)端針對這些問題必須要做一些處理。在上傳時(shí)，盡量減少上傳時(shí)間，在下載時(shí)，能讓用戶盡快看到內(nèi)容。同時(shí)，盡量節(jié)省流量，減少不必要的流量消耗。

文本消息因?yàn)楸容^小，可以直接通過長連接傳輸。但對于多媒體文件，通過長連接來傳輸則不合適，長連接服務(wù)器不會(huì)對大文件傳輸做針對性優(yōu)化，大量的多媒體文件數(shù)據(jù)會(huì)直接搶占其他信令消息和文本消息的貸款資源。因此，多媒體消息會(huì)通過另外的通道，到專門的文件服務(wù)器存取。

在下載時(shí)，對于不同的網(wǎng)絡(luò)環(huán)境，可以采用不同的預(yù)取策略。在 WiFi 環(huán)境下，由于無需考慮流量問題，在收到消息后，我們就能立即把包含的多媒體文件下載下來。而在移動(dòng)網(wǎng)絡(luò)中，則應(yīng)當(dāng)?shù)鹊接脩粽嬲吹皆摱嗝襟w消息時(shí)，才去下載。

?

圖 片

上傳時(shí)，現(xiàn)在手機(jī)攝像頭的像素動(dòng)輒上千萬，一張圖片隨隨便便就好幾M，然而，通過 IM 軟件傳輸?shù)膱D片，通常對于質(zhì)量要求并不會(huì)太高，如果我們直接將好幾M的圖片直接上傳，往往費(fèi)力又不討好。在上傳之前，將圖片像素降低，并進(jìn)行壓縮，可以明顯的減少上傳轉(zhuǎn)菊花的時(shí)間，減少用戶流量消耗。如果用戶確實(shí)要求圖片質(zhì)量，則提供一個(gè)原圖選項(xiàng)。

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

使用 http 上傳的另一個(gè)優(yōu)化技術(shù)是使用 pipeline。在不使用 pipeline 時(shí)，上傳一個(gè)數(shù)據(jù)塊需要等到前一個(gè)數(shù)據(jù)塊傳輸成功才行，數(shù)據(jù)通道是單工的。使用pipeline則可以將數(shù)據(jù)通道變?yōu)殡p工的，一個(gè)數(shù)據(jù)塊傳輸完成后，不必等到回包，就能直接上傳下一個(gè)數(shù)據(jù)包，能節(jié)省一次數(shù)據(jù)回包延時(shí)。

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

?

語 ?音

對于不同的網(wǎng)絡(luò)環(huán)境，采取不同質(zhì)量的語音編碼算法，在較好網(wǎng)絡(luò)時(shí)，使用高質(zhì)量語音，而在弱網(wǎng)環(huán)境下，則使用較低質(zhì)量，優(yōu)先保證可用性。

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

語音消息沒有縮略圖，因此語音下載基本就只能實(shí)打?qū)嵉膶⒃嘉募螺d下來。

?

以上就是網(wǎng)易云信對于Android 即時(shí)通訊開發(fā)的小結(jié)，歡迎各位積極提問，共同探討。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。