IM協議和IM Server
XMPP確實很傳統，WhatsApp選用了，同時經過壓縮、精簡（比如說user字符串使用u字符替代）處理，讓XMPP輕量不少。
MQTT，如何實現羣組、好友呢，這個是業務層面上事情，大家都訂閱某一個主題Topic好了，屬於業務拓展。
SIP，接觸少。
針對XMPP協議的改進，很有參考價值。
心跳單向四個字節，在XMPP協議下，估計應該是極限了吧。在私有協議協議下，一來一往兩個字節足夠。
文件傳輸方式，這是業界通用方式。
移動互聯網環境下，用戶永遠在線，大家的共識。可是取決於手機有沒有連接到服務器端，這是無法逾越的障礙。
Muc聊天室，業務層面改進。
這個針對使用OpenFire的同學，很有參考意義。
二。移動網絡環境下的網絡、電量等客戶端優化
IM或推送，建立長連接是必須的，可以節省TCP來回創建的開銷，但斷線之後，是否需要即刻重連，尤其是處於地鐵、WIFI邊緣地帶，可能會造成重連風暴，需要添加稍加延遲連接機制。
針對發送的消息的回執，客戶端一定要發送回執反饋，否則不知道是否發送成功與否。
流量跑馬測速，心跳智能，壓縮傳輸。
Android手機端優化措施，乾貨、細節很實用，可以直接拿來用，分享很給力，呵呵！
批量、合併數據請求/發送，增量更新，這是一個大家都應該使用的常規節省流量手段，應牢記！
難得的是，分享了：
2G 文件上傳最佳buffer size 1024個字節，3G/4G下直接設置爲10K
2G 文件下載最佳buffer size 2048個字節，3G/4G下 30K
絕對經驗的總結，贊！
心很細，給出了頻繁的屬性訪問直接聲明protected/publish了，不創建新的Java對象只能static類型了。記得很久以前寫J2ME程序時，就用過這樣的方式。
實踐中走過多少彎路才總結出來的同步、繪圖、渲染頁面驚豔，尤其是支持離線方式的數據同步機制，很受用。
三。百萬級架構經驗分享
雖然很簡單，熟悉TCP/IP協議，這是毫無疑問。
無狀態協議交互，才能夠很容易水平橫向擴展，也是當今共識。
讓所有操作都要儘可能的異步
典型的按照機房進行完整部署，若不能夠在DNS層面做到按照用戶ID進行指派（HTTP DNS進行接入IP分配），那麼就必須處理用戶亂入機房的問題，必然要做到一些數據的跨機房的同步，大家都會採用增量式同步方式，跨機房一般常見30毫秒的延遲，批量形式增量同步，那都不叫事。
可以看到業務垂直切分，各個業務之間水平擴展。
貌似可以看到單元化CELL/SET架構的影子，但這只是自己的瞎猜而已。
PPT上架構圖文字細節不甚清晰，再加上自己近視，分辨不太老好的，可以看到消息存儲使用了Kafka（和數據庫集羣之間存定時拉取關係），分佈式鎖基於Zookeeper，前端LVS做負載均衡，業務非常垂直。
在PPT上只看到了兩個機房，若用戶量級上億，可能需要擴展到第三個、第三機房，可能跨機房同步的壓力就就凸顯出來了。