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

相關推薦閱讀：、

客戶端架構

作為一個 IM 軟體，最重要的一個特性就是保證訊息的達到率和實時性。達到率受伺服器效能和設計協議影響，後面再談。而實時性則主要取決於客戶端程序是否長期存活，連線是否一致保持。

程序切分

在 Android 系統中，App 對於自己應用的生命週期是基本沒有控制力，系統能在任意時候將你的程序殺死，且不會發出任何通知，也會在它認為合適的時候把你叫起來。程序前後臺切換也同樣不會給出任何通知。不過程序的生死控制也還是有一些規矩的，大體上來說就是程序佔的資源越多（記憶體，CPU 時間等等），對於使用者越不重要（前臺程序->可視程序->服務程序->後臺程序->空程序），越容易被幹掉。因此，程序應當儘量小巧，且具有高的優先順序。

如果一個應用本身就很小巧的話，一個程序就完全足夠了，主執行緒負責 UI，另起一個後臺執行緒跑一個服務。而如果應用比較龐大的話，將推送服務獨立出來則是一個更好的選擇。主程序負責使用者互動和主要的業務邏輯，佔用龐大的資源，當退到後臺後，隨時被殺死都無所謂。推送程序則僅僅負責與伺服器互動，保持最小限度的業務邏輯處理。

網路連線和登入狀態是綁在一起的，登入之後，同步資料也是必須的操作。因此，登入和同步資料都需要在推送程序中完成，除此之外，其他的業務都交給 UI 程序處理。推送程序收到自己不屬於自己的協議時，就將資料扔給 UI 程序處理。

兩個程序之間通訊方式沒有別的選擇，只有 AIDL，難點在於介面的設計。IM 業務邏輯複雜，我們不可能為每一個呼叫實現一個 AIDL 介面，因此肯定會把介面呼叫打包成控制命令傳遞。而標識控制命令比較容易想到的方式，是採用類似於 Message 的 what，由我們為每一個控制命令分配一個命令號（或者再加一個子命令號），並指定對應的命令資料格式，接收端根據命令號再將資料反解出來處理。這種方式比較麻煩，且可維護性很差。更優雅的方式是使用遠端過程呼叫，傳送端申明業務的呼叫介面，並在遠端實現這些介面，當傳送端呼叫這些介面時，遠端直接呼叫對應介面的實現。除了使用各種第三方框架外，Java 自身的 Proxy 也能實現這個功能。而從推送程序到 UI 程序還有一點不同，UI 程序隨時可能會被幹掉，AIDL 呼叫可能會返回失敗，此種情況可選擇 Intent 方式傳遞資料，併兼具喚起 UI 程序的功能。

保  活

保活分為三個方面，一是系統API提供了介面，應用自己就能做的，這是”合法“的，二是利用系統的缺陷，躲開系統的審查，這算是”非法“的，或者是”灰色“的，三就是多個 App 結盟，互相喚醒，這是耍流氓，誰的陣營龐大誰就贏。

第一種主要有系統鬧鐘，各種事件的 BroadcastReceiver，任務被移除的回撥通知等。

第二種已知的就是在 4.4 及以前版本上，使用 native 程序，並將該程序從 davilk 父程序中脫離，掛接到 init 程序上，以此避開系統的查殺。然後在這個 native 程序中，定時喚起應用。為了讓這個 native 程序更輕巧，可以使用 exec 的方式啟動一個可執行檔案，以除掉直接 fork 帶入的 Zygote 程序環境。另外，這種方式也被用在監聽自己應用被解除安裝時彈出調查視窗。

第三種方式現在各大網際網路公司都在使用，方式很簡單，互相呼叫指定的 Service，或髮指定得廣播即可。只要你起一個阿里系的 App，其他阿里系的 App 都會被跟著喚起。你啟動一個裝了友盟 SDK 的 App， 其他裝了友盟 SDK 的App，以及阿里系的 App 都會被跟著喚醒。

通常，第一種是必備，第二種和第三種則會結伴出現，流氓到底。

通訊協議選擇

訊息的實時性的另一個保證是長連線。當然，你也可以用短連線輪詢，但這個一般只在網頁端短時聊天使用，在 Android 後臺無限時輪詢沒有人能受的了。長連線型別可以選傳統的 TCP，也可以使用比較新的 WebSocket。 使用後一種的好處主要是伺服器的，他們一套連線就可以服務好 App 端和 Web 端。

IM 的通訊協議選擇性很多，開源的有 XMPP，MQTT等，使用開源協議的優勢在於上手快，資料多。而大部分主流 IM 則一般會設計私有的通訊協議。使用私有協議，可以針對自己的業務邏輯，設計出更省流量，效率更高的協議，同時，還能有效保護自己的生態圈，就像 Android 手機裝不了蘋果系統，易信使用者不能給微信使用者發訊息一樣。

私有協議的協議內容和開源協議差不多，可以包含通用的協議頭，然後加上負載包體。打包時，為了追求可讀性，可以使用文字協議，為了追求省流量，則一般使用二進位制協議。

在設計私有協議時，訊息必達是一個需要側重考量的地方。由於行動網路的複雜性，訊息在客戶端和伺服器之間傳遞是有很大可能被傳丟的。當客戶端傳送訊息給伺服器時，客戶端並不能確保訊息一定就會被伺服器收到，需要伺服器在收到訊息後給客戶端一個回饋，如果客戶端沒有收到回饋，就需要在一定超時後重新發送。這裡存在一個問題就是有可能伺服器已經收到了，但回饋的包被丟掉了，這時就會造成訊息重複，為了去重，我們需要為相同的訊息分配相同的 uuid，供接收方去重。同樣，當伺服器將訊息轉發給接收端時，伺服器也不能保證接收端就一定能收到，需要接收端給伺服器一個回執，告訴伺服器這條訊息我已經收到了，你就不要再給我發了。