推薦閱讀
移動im開發指南1：如何進行技術選型
移動im開發指南2：心跳指令詳解
在移動 im 模組中，最核心最複雜的模組莫過於登入模組。乙個沒有經過很好優化的登入模組往往耗時久且浪費流量：一次登入短則數十秒，長則幾分鐘，同時同步下幾百 kb 甚至幾m的資料。
乙個簡單的登入步驟可以分為如下幾步：
l 請求 lbs
l 連線 link
l 收發登入請求
l 同步 im 資料
優化 lbs 請求
在 pc 時代，我們往往將請求 lbs 和連線伺服器做乙個串聯，畢竟只有先請求完畢 lbs 才能夠拿到真正的 link 伺服器位址，從而進行連線操作。在具體操作上，一般 lbs 請求就是一次 http 請求，這裡的耗時可想而知。所以乙個樸素的優化想法就是從登入流程中移除這個環節。
然而直接粗暴去除 lbs 請求並不可取，如果我們直接內建網域名稱或 ip，帶來最大問題自然是無法做負載均衡。所以更推薦將 lbs 請求非同步化：不在登入時做 lbs 請求，而在網路空閒和發生變化時進行請求並快取，每次登入則直接從本地快取獲取 link 位址。
dns
優化使用 tcp 時不可避免會碰到 dns 解析的問題，畢竟我們不可能一直使用 ip 作為伺服器位址。在 pc 時代，dns解析幾乎不費事。但進入無線時代後，dns 相關問題越來越嚴重。一方面，在流動網路下，dns 解析速度無比龜速，一次 dns 解析的時間甚至能趕上一次 tcp 連線的時間，幾秒，十幾秒，甚至三，四十秒的請求時間都很常見。另一方面，由於運營商的不作為和作為，流動網路下 dns 也呈現了解析準確度低和經常被劫持的狀態。
針對這些情況可以考慮使用 http dns，github 也有很多開源的實現，比如httpdnslib。而最激進的方法自然是像前面優化 lbs 一樣，在個個環節中避免 dns 解析：
l lbs 返回伺服器 ip 而非網域名稱
l 本地快取 lbs ip 位址備用，請求 lbs 時優先使用 ip 而非網域名稱
這種方式不僅可以避免 dns 請求的耗時，也可以一定程度上規避 dns 被劫持的問題。而弊端是針對這種情況需要在客戶端考慮一系列的其他問題：如何從 ip list 選擇有效位址，確定重新請求時機，負載均衡，節約流量等。
登入請求
事實上，登入請求環節其實並沒有多大的優化空間。一旦你連線上了伺服器，接下去要做的事無非是加密當前連線和傳送並接收登入反饋。這兩步缺一不可。而如何優化又往往會和具體的業務相關：假如我們使用類似於 https 一般的三步協商的加密流程，安全性的確可以得到保證，但是一來一回的次數過多，整個登入耗時就會增加。取巧的方法自然是將加密和登入請求合併，而這往往會涉及到對登入請求的改造。
同步策略優化
l 好友列表
l 好友個人資訊
l 群組列表
l 群成員列表
l 群成員個人資訊
l 離線訊息
假設乙個使用者有 1000 個好友， 20 個 50 人群，平均每一項大約 200 個位元組，那麼一次全同步大約需要 0.2 * (1000 + 1000 + 20+ 1000 * 2) = 800 kb 的資料，這對於乙個移動 im 是無法接受的，更何況這還是乙個較輕度使用者的資料量。
移動IM開發指南1 如何進行技術選型
移動im開發指南2 心跳指令詳解 移動im開發指南3 如何優化登入模組 im通訊方式無非兩種選擇 裝置直連 p2p 和通過伺服器中轉 1.p2p p2p多見於區域網內聊天工具，典型的應用有 飛鴿傳書等。這類軟體在啟動後一般做兩件事情 2.伺服器中轉 幾乎所有網際網路im產品都採用伺服器中轉這種方式進...
移動IM開發指南2 心跳指令詳解
網易雲信多年ios im sdk開發的經驗，深度分析實際開發中的各種常見問題。移動im開發指南1 如何進行技術選型 移動im開發指南3 如何優化登入模組 在使用 tcp 長連線的 im 服務設計中，往往都會涉及到心跳。心跳一般是指某端 絕大多數情況下是客戶端 每隔一定時間向對端傳送自定義指令，以判斷...
移動IM開發學習 3
在ubuntu系統上 xmpp環境搭建之mysql安裝 一.安裝mysql 資料庫也是伺服器，連線需要 位址 埠號 開啟終端 二.遠端訪問mysql資料庫 mysql遠端訪問的命令 mysql h192 168 1.11 uroot p123456出現這樣的錯誤 error 2003 hy000 c...