第三方平台
比如環信，融雲，leancloud，容聯雲、網易雲信等等。直接使用sdk就可以實現了，最簡單最直接，而且穩定性已經不錯了，連ui介面都帶有了，可以自行修改，缺點是要收費。
spark+smack+openfire
安卓使用asmack，測試使用spark，伺服器使用openfire。
asmack可以說是smack的android平台的支援版提供xmpp協議的實現，就是一些api。
spark就是乙個可以用來在pc相互同信的客戶端。
openfire部署也比較簡單，next，next就差不多了。
使用第三方推送的sdk
利用推送的及時性來做im也是可以的
socket長連線
因為網路優化和穩定性原因，達不到商用級別
基於xmpp自己實現
通常im採取的協議有xmpp、mqtt、protobuf等資料通訊私有協議。
xmpp是一種基於標準通用標記語言的子集xml的協議，它繼承了在xml環境中靈活的發展性。
xmpp中定義了三個角色，客戶端，伺服器，閘道器。通訊能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了客戶端資訊記錄，連線管理和資訊的路由功能。閘道器承擔著與異構即時通訊系統的互聯互通，異構系統可以包括sms（簡訊），msn，icq等。基本的網路形式是單客戶端通過tcp/ip連線到單伺服器，然後在之上傳輸xml。
命令要麼用2進製的形式傳送（比如qq），要麼用純文字指令加空格加引數加換行符的方式傳送（比如msn）。而xmpp傳輸的即時通訊指令的邏輯與以往相仿，只是協議的形式變成了xml格式的純文字。
流量耗電
(1)流量越小，耗電越低。
(2)心跳策略，減少心跳次數，耗電量就會降低。
心跳時長：
wifi，2g，3g，4g，移動、電信、聯通,不同網路，不同執行商，nat失效時間不一樣，因此心跳的時間也就不一樣。
網路連線：
cmnet和cmwap下連線處理機制。
網路不穩定：
移動端最大的特點就是網路不穩定，在不穩定的網路狀態下，如何保證訊息以最快的速度到達？如何避免重聯風暴？這些既需要從整體架構考慮，也需要在移動端採取巧妙的策略加以避免。
聯結器的設計
聯結器主要用來管理客戶端的長連線。目前最好的聯結器單台8g8核的伺服器可以做到70萬—100萬的連線，而某些開發者只能做到4000左右的連線，相差好幾個數量級。這裡的奧妙在**呢？
中介軟體的設計
是否採用通訊中介軟體？通訊中介軟體的好處有哪些？如果不採用中介軟體，聯結器和邏輯伺服器的連線關係如何管理呢？
邏輯伺服器
邏輯伺服器通常簡單一點，主要是根據業務邏輯進行最小粒度的劃分即可。但是即便如此，還是有很多的開發者把看似相關實則不相關的邏輯放在一起，如把鑑權和message伺服器放在一起。
狀態伺服器
資料庫的設計
資料庫的設計是最難的，也是做大的瓶頸。因為無論對於sql（關係型）資料庫還是nosql（非關係型）資料庫，都有讀寫處理的極限，那就需要考慮資料庫如何分割槽（根據什麼原則、什麼操作、哪些使用者訪問哪個節點上的資料庫）。同時又需要考慮每個原子操作（如登陸）需要讀哪些庫，寫哪些庫。只有這些指標明確了，你才能在假設有100萬併發使用者，100萬條併發訊息的情況下，準確評估服務端需要多少臺伺服器，如何部署。
其他還有裝置推送的處理，何種機制能夠保證不丟訊息，離線訊息如何處理，等等。這些都是必備而又非常複雜的功能點和技術要求，都需要採取正確的架構和策略才能實現。
語音即時通訊總結
一 為什麼需要兩個連線相互輔助進行命令識別並傳輸音訊。首先從a客戶端傳送資料到b客戶端是乙個音訊資料流，而音訊資料流在伺服器上傳輸的時候使用的是橋接模式。這也就說明了在伺服器端，其實不是將乙個packet資料傳輸到另乙個packet。如果需要用packet進行傳輸，這意味著我們需要對客戶端的資料進行...
mysql 即時通訊 即時通訊IM模板
更新記錄 1.0.3 2020 10 22 完成點對點通訊功能，修復若 ug。1.0.2 2020 06 02 1 增加登入 註冊 個人資訊頁面 speedy im 注意介紹 正在持續開發中，目前僅部分ui開發完成。demo im.apk 已有基礎ui以及登陸 點到點聊天等功能。開發客戶端測試賬號密...
即時通訊開發資料分享
1 網路程式設計基礎資料 2 有關im 推送的通訊格式 協議的選擇 為什麼qq用的是udp協議而不是tcp協議？移動端即時通訊協議選擇 udp還是tcp？如何選擇即時通訊應用的資料傳輸格式 強列建議將protobuf作為你的即時通訊應用資料傳輸格式 移動端im開發需要面對的技術問題 含通訊協議選擇 ...