项望烽：移动 IM 开发之登录优化
作者：項望烽
網易杭州研究院·網易云信 iOS端負責人
【往期回顧】項望烽：移動 IM 開發之心跳
源起
在移動 IM 模塊中，最核心最復雜的模塊莫過于登錄模塊。一個沒有經過很好優化的登錄模塊往往耗時久且浪費流量：一次登錄短則數十秒，長則幾分鐘，同時同步下幾百 KB 甚至幾M的數據。
一個簡單的登錄步驟可以分為如下幾步：
請求 lbs
連接 link
收發登錄請求
同步 IM 數據
而這里的每一步都是有優化的可能性。(事實上下面的很多思路都是普適的，不是只有 IM APP 才用得到)
優化 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 解析：
lbs 返回服務器 ip 而非域名
本地緩存 lbs ip 地址備用，請求 lbs 時優先使用 ip 而非域名
這種方式不僅可以避免 DNS 請求的耗時，也可以一定程度上規避 DNS 被劫持的問題。而弊端是針對這種情況需要在客戶端考慮一系列的其他問題：如何從 ip list 選擇有效地址，確定重新請求時機，負載均衡，節約流量等。
登錄請求
事實上，登錄請求環節其實并沒有多大的優化空間。一旦你連接上了服務器，接下去要做的事無非是加密當前連接和發送并接收登錄反饋。這兩步缺一不可。而如何優化又往往會和具體的業務相關：假如我們使用類似于 HTTPS 一般的三步協商的加密流程，安全性的確可以得到保證，但是一來一回的次數過多，整個登錄耗時就會增加。取巧的方法自然是將加密和登錄請求合并，而這往往會涉及到對登錄請求的改造。
同步策略優化
登錄完畢后，客戶端需要從服務器同步，一個常規的 IM APP 需要同步如下數據：
好友列表
好友個人信息
群組列表
群成員列表
群成員個人信息
離線消息
假設一個用戶有 1000 個好友， 20 個 50 人群，平均每一項大約 200 個字節，那么一次全同步大約需要 0.2 * (1000 + 1000 + 20 + 1000 * 2) = 800 KB 的數據，這對于一個移動 IM 是無法接受的，更何況這還是一個較輕度用戶的數據量。
顯然全同步是無法接受的，改進的方法自然是按時間戳同步。客戶端永遠只更新比本地緩存數據新的數據。這是一個常規的優化方向，還有一些根據業務需求可以實施的優化：延遲更新和按需更新。以群成員個人信息為例，其實用戶并不關心其實時性，畢竟這些群成員并不一定是用戶好友，他們的信息變動完全可以在用戶進行查看時再更新（微信的策略）。而好友個人信息也是同理，對于大部分界面而言，他們只關心用戶 Id，頭像和昵稱這三個基礎信息，而一些錦上添花的 Profile 信息完全可以在用戶查看相應界面時進行一次按時間戳的更新。
·?END?·
【精彩回顧】
項望烽：移動 IM 開發之心跳
項望烽：移動IM開發那些事兒
項望烽：iOS App開發那些事兒
網易云信|真正穩定的IM云服務
http://netease.im ?長按關注，干貨不斷
總結
以上是生活随笔為你收集整理的项望烽：移动 IM 开发之登录优化的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 项望烽：移动 IM 开发之心跳
- 下一篇： 氧气中国·创业创新大赛企业服务专场