QCon
北京2016全球軟件開發大會已于4月23日在北京國際會議中心順利閉幕。在23日進行的“移動開發與即時通訊”專場活動中，來自融云的技術副總裁楊威，分享了他多年工作當中所獲得的心得與經驗。

　　融云作為全球最大的即時通訊云服務商，截至2月份，已經累計服務包括土豆、秒拍、百姓網、優信二手車、駕考寶典、大智慧、戰旗 TV等在內的 App
逾8萬款，日活躍用戶量超過2000萬，日消息量超過12億條。在艾瑞咨詢最新發布的《2016年中國 IM
云服務行業白皮書》中，融云即時通訊云穩居市場第一。

　　當前，移動開發者無論是構建用戶生態，還是豐富業務場景，亦或是打造移動辦公，所以如何使用即時通訊云，也成為了企業或者開發者必須關注的議題，此次分享，融云楊威的演講內容涉及融云
IM SDK 架構、IM SDK 實現過程中的經驗等，為正在移動端開發的技術人員提供了大量的技術參考與實踐經驗。

　　以下是演講精彩內容：

　　大家好，首先介紹一下我自己，我是北京郵電大學通信工程本科碩士畢業，前通信圈人士，曾從事11年手機研發，現在融云擔任技術管理工作，主要負責
Android，iOS，Web 端的即時通信
SDK。融云是一家提供即時通信(IM)云服務能力的廠商。我們的核心技術團隊主要來自于前飛信的后端團隊，和來自三星的移動端團隊。我們的前端團隊以前主要負責多媒體技術和通信RCS技術，RCS
是一種電信級領域的即時通信 IM 技術。所以也都是這個領域內的資深從業人士。

　　從電信領域轉到互聯網領域做社交
IM，我們發現互聯網行業的特點是快，開發快上線快。對即時通信的需求很大。互聯網圈的朋友們，開發者，架構師，對即時通信技術一般都興趣很高。今天的主題，背后有一個核心思想，就是關于技術選擇”。對于我們每一位研發工程師，架構師，技術管理者，你的每一次技術選擇，對自己，對公司，都是價值千金，每一次選擇都影響著很多資源的投入。做出正確的選擇需要信心，需要成功的經驗用來參考。今天我分享的是基于我們眾多工程師十幾年研發經驗，幾萬開發者得來的寶貴經驗，我們愿意分享給大家，讓大家在
IM
技術研發上做出最好的選擇。最近幾天我也參與了大會的其他一些分享，其中也涉及即時通信消息，看了之后我更加確信我們融云在這件事上真的是很專業，有很多值得分享給大家的經驗，但時間有限，所以我簡單的介紹。

　　我們這次要分享的內容是，首先介紹一下融云，然后介紹一下融云 IM SDK 架構，第三部分是分享一下 IM SDK
實現過程中那些價值千金的經驗，最后分享通過 IM 社交如何實現 SaaS 級的服務。

　　首先，融云提供了一個 IM 的云服務平臺，這是一個公有云平臺。其次，融云提供了一個前端 SDK。這兩部分是這個圖里面綠色的部分。通過我們的云平臺和
SDK，App 之間可以通過收發消息進行互動。最后，我們基于這個平臺，提供了一些 SaaS
級的軟件服務。對于即時通信平臺，我們很多研發人員都是很有情懷的，都像自己做一次 IM，同時有微信這種巨頭的存在，很多
App也都有夢想去做一個微信。但總的來說，消息要做到高并發，不丟消息，實時性是非常難的。有些業務，你通過延遲來解決并發問題，或者通過丟包來解決，但對于消息，是一條也不能丟不能延遲的。

　　今天的分享我們主要是移動前端。SDK 前端架構是三個部分，協議棧，IMLib，IMKit。我們選用了 native 語言，即 C++
來實現協議棧部分，并封裝了兩個 SDK，一個通信能力 SDK，一個界面組建 SDK，通過通信能力 SDK，你可以簡單的收發消息，通過界面組件
SDK，你可以在短時間內迅速的搭建一個整套 IM 社交軟件。這三部分的劃分應該說是比較經典的，曾被很多業內伙伴的所借鑒。

　　這里額外聊一下我們對 SDK 在移動端開發的趨勢。第一，云服務+SDK 的模式在移動互聯網領域，經過一段時間的發展，已經趨于非常成熟了。App
通過嵌入
SDK，實現云服務能力，可以實現快速上線，節省大量的研發運維費用，同時云服務企業自己發展在技術和資金上也越來越強大，大家可以放心選用。第二，核心功能組件通過
SDK 進行封裝，是一種基本的技術實踐能力。各個公司也都是這么實踐的，封裝 SDK
的過程本身就是解耦合的過程，資深工程師都知道解耦合是提高軟件性能的一個必要過程。其次，封裝 SDK
可以提高項目源代碼管理的編譯消息。最后，可以提高跨部門研發的溝通消息，大家知道程序員最高效的溝通效率是什么嗎，就是不溝通。不要說話，不要解釋，不要互相說服，你寫的
API 我能看懂然后我去調用就可以了。當然這是個笑話，當然是越多溝通越好，比如來參加 QCon 大會聽聽大家的分享。

　　接下來分享我們第一個有價值的經驗，IM 協議的選擇。

　　我參與過一些活動和社群里，我們發現大家都對如果實現一個 IM 有很高的興趣。第一個面對的選擇就是如何去選擇和實現 IM
協議，有了協議才有后面的一切。很多人都在關心，我該選擇 XMPP 還是私有協議呢。我個人的看法是，移動互聯網和計算機技術發展到今天，已經可以替 XMPP
宣告死刑了，到目前為止所有的大型商業機構采用 XMPP 搭建的通信網絡要么替換了要么關閉了，運行中的也有一些不多。所以，大家不要去選擇 XMPP 構建自己的商業
App IM 功能，當做自學還是很不錯的，畢竟服務端都是開源的。XMPP 的兩個主要問題是，第一基于 XML
的協議體比較重，對其壓縮和解析又耗費內存，第二是其后端設計和開源架構有一些問題，當你的用戶體量大了之后非常耗費服務器資源，而且常見在十萬用戶數量級上頻繁的重連和丟消息。這個數據主要來自于一些我們客戶的經驗，并不是絕對準確。那么我們選擇什么呢，我們推薦使用
MQTT，或者參考其思路去設計自己的私有協議。序列化我們推薦 ProtoBuf，這也是 Google
推薦的。選擇私有化協議的優點是輕量，輕量處理起來就快，節省前后端資源，省電，這都是移動互聯網 App 和核心需求。此外私有協議也會相對更加安全。

　　商業 IM 軟件還要考慮跨平臺。要支持 Android，iOS，WP，PC，Web 端，甚至 Linux
設備。因此在設計和選擇之初就要考慮到，否則未來每一個平臺和語言都要重新開發一次。我們的協議棧使用 C++開發，基于
Linux，因此可以無縫的兼容幾乎所有平臺。注意這個圖里我們把業務和數據庫放到了 native
協議棧部分，這個核心優點是跨平臺統一，可以保證每一個細節甚至是響應時間，都可以在多平臺一致。業務和數據是否放在 native
對于架構師是比較重要的一個選擇。數據庫和業務層跟 natvie
協議棧在一起還有一個重要的原因，就是更快的響應和處理消息，當接收到消息的時候，我們會首先給服務端發響應包，這樣服務器更快的釋放資源。然后移動端在繼續進行后續的處理。業務數據和協議都通過
native 實現，可以更好的處理這部分邏輯。凡事有利就有弊，這個缺點也是有的，在 Android 上由于 NDK 編譯會導致庫文件比較大，而國內
Android App 一般對體積要求比加大。解決辦法是不斷的優化更新減少尺寸。這部分稍后還會介紹。

　　第二個有價值的經驗是 SDK 的實現。我們封裝了兩個 SDK。IMLib 和 IMKit，其中 IMLib
主要負責能力，建立連接和發送消息等功能。IMLib 實現的是一個跟微信風格類似的界面。相比之下很多產品一般只會選擇一個類似 IMLib 這樣的能力
SDK。做出這個選擇的根源是我們希望節省開發者的時間，共同的部門實現一次就可以了，不需要第二次第三次反復開發，既然80%的 IM
社交界面都是類似的，那么融云實現了提供一個標準的模式就可以了。開發者的創意是無限的，還有20%的需求我們滿足不了，那么使用我們的通信組件 IMLib
就可以了。我們做這個界面 SDK 基于一個價值觀：所見即所得。客戶看到我們宣傳的界面是這樣的，集成了 SDK
之后得到的也是這樣的。不會像有的產品宣傳的無所不能，其實只是方便面包裝上的效果圖，都要等著客戶自己去實現。

　　介紹一下IMkit組件的架構，大家看圖即可。主要是封裝了兩個界面：會話列表和會話。Android 和
iOS上設計架構略有區別。有很多工程師也糾結這個問題，是否應該讓 Android 工程師和 iOS
工程師使用同樣的設計模式，我們的經驗是讓各種的工程師使用各自的架構，在業務上劃分好就可以了。MVC，MVVM，MVP，本質上就是顯示層、控制層和數據層的劃分。重要的是劃分好層次即可。讓一類工程師去學習另外一類工程師的開發習慣效果不好。這個經驗來自我們融云幾萬開發者。第二條經驗是融云自己內部的經驗，我們不適用第三方組件，比如說HTTP
和數據庫的第三方組件。第三條是持續的優化結耦，這也跟今天所有類似經驗一樣，選擇之后一定是有利有弊，針對弊端，要不斷的去優化。

　　我們為什么選擇做一個界面SDK 呢，因為實際上在移動端，UI 的開發量是極大的，一般占
80%以上。輸入區，表情，圖片選擇器，會話界面，消息展現等等，一般需要一個工程師1個月的時間開發，1個月的時間調試。兩個端就是4~6個月。而且老板和產品經理還覺得很容易，雖然確實是不難，但是其實細節上做出來性能效果差別都很大的。我們的一個價值觀就是：我們每多做一些，開發者就少做一些，所以我們選擇把界面封裝起來替客戶做完。當然也有缺點，IMKit
是一個非常重的封裝模式，接口很多，使用方式復雜，我們選擇不斷的去優化，未來我們會進一步解耦合把核心的部分再次封裝。另外我們融云的客戶支持服務工作做的很好，可以提工單像我們咨詢。我們每天有很多研發工程師回復200個左右的客戶工單問題，在此也感謝我們融云這些工程師。

　　再介紹一下IMLib的架構，同樣大家看圖理解吧。我們封裝了兩個核心象，Conversation，Message，這個對象是跨平臺一致的。lib提供了像
connect、sendMesage這樣的接口，同時我們做了很多工作，讓網絡連接更加穩定性。不需要客戶去做重連。很多朋友關心長連接和穩定和優化，其實長連接就是通過發送心跳包維持，并沒有什么秘密。最差的結果就是多重試幾次，但我們不能這樣，我們必須確保客戶得到的版本性能是最優的，所以關鍵是持之以恒的優化，發現問題并解決問題。我們每個版本都監控電量、流量、內存。確保性能最優。

　　第三個有價值的經驗是正確的版本迭代姿勢。也是今天的點睛之筆。前面介紹的技術選擇，不能說絕對正確，但也都是基于我們融云資深團隊這么多年的經驗，幾萬開發者的集成經驗。有優點也有缺點，那么通過什么方式彌補優點就很重要。比如使用
native 語言實現協議棧，優點很多，但缺點是 Android 上的包比較大。那么解決的辦法就是不斷優化每一行代碼去優化包的大小。提供 IMKit
的優點是節省了用戶的時間，但是缺點就是支持使用復雜，那么我們就進一步去拆解和封裝。技術選擇只是第一步，之后的不斷持續優化才是一切。

　　這張圖是融云至今為止發布的 220
多個版本道路中的一部分，橫軸是從2015年1月到2016年4月也就是現在，縱軸是我們衡量的一個性能參數，基于尺寸，電量，性能綜合評價。在這里我們分享一下我們成功經驗，也分享一下不那么成功的經驗，融云于創業之初發布了1.0版本，最初版本的要求一定是快速上線，快速支持客戶。但是在業務量體量到一定規模的時候，你的架構可能是支撐不住的，所以一定要做一次架構的重構，這個情況在很多人身上都出現過。當時我們采用了一次大的架構更新。導致了
1.0 和 2.0
兩個版本在幾個月內并行，架構升級一定是性能的提高功能的增加。但這次升級并不能成為成功，因為長時間版本并行，給客戶帶來了一定的煩惱。這個現象融云遇到了，很多人也遇到了，即使現在我們的圈內伙伴內還在進行類似的升級。那么正確的姿勢是什么呢，我們可以看到從2015年8月開始到現在，我們的整體功能增加了
32%，協議棧包降低了 75.7%，Android/iOS 源代碼量減少了 36.8，電量優化了 36% ~ 77%
不等。而用戶完全無感知。我們的版本號沒有變化，但其實代碼已經大變樣。我認為身為一個架構師，不應該讓用戶通過版本號增加去感知你架構的改變。這是我們很驕傲的一件事，我們在一年的時間內通過不斷迭代、追求卓越的的互聯網精神，持續的提高著軟件質量，給客戶帶來更好的性能，更小的尺寸，更加省電。這才是我們正確的開發者服務精神。

　　所以結合起來說就是，做出正確的選擇，通過不斷的迭代努力去優化自己的產品，永不停止。

　　第三部分，我們講一些融云如何實現 SaaS 級的體驗和服務。SaaS = Software as a
Service，軟件即服務，在互聯網時代，SaaS 的核心是“一經要求，即可使用”，最佳實踐是通過瀏覽器，打開一個網頁就可以使用。在移動互聯網時代，實現
SaaS 服務的難度相對大了一些。我認為移動互聯網時代的 App 就是互聯網時代的瀏覽器，同樣是入口，區別是移動互聯網上的入口多了一些。用戶進入一個
App，進行他的核心體驗的同時，也會發消息，也會打電話，購物，發紅包，這些體驗可以在 App 內閉環完成。這對 App
廠家們來說是一種核心需求，對用戶來說也是一種最佳體驗。要實現這些功能和能力，僅靠 App
廠家自己是不行的，這意味要重復建設很大的研發團隊。因此需要集成第三方服務，需要集成 SDK
發布版本，這一步是無法跳過的，但在集成之后，服務是可以反復體驗的。所以我們融云的目標是提供一種 SaaS 級的體驗，一經集成，即可使用。

　　融云在這方面有比較好的實踐經驗，融云提供的是即時通信 IM，是一種通信能力，我們并不做具體的 SaaS
業務，比如客服。但我們的很多客戶都需要客服，需要一個完整功能強大的客服工作臺，于是我們選擇了跟市面上最優秀的一些廠商合作，通過融云
SDK，讓客戶可以在移動端使用 IM，在 PC
端使用客服工作臺。這個技術方案大概如圖，首先要在客戶端實現功能抽象化，把標準的客服功能抽象化為具體的消息，然后通過在服務端實現一個消息轉 API
的適配層，直接訪問客服合作伙伴的服務器。這個實踐模式看起來簡單，其實這并不是唯一選擇，但他是最優的，效率高性能好，合作伙伴不需要改變自己的設計架構。我們可以同時支持多家客服后臺，而移動端抽象化之后，對后臺使用的是誰完全無感知，只是基于標準的信令去做處理。而對客戶來說，服務端可以動態的控制和調整使用哪個后臺，增加了更多的選擇。

　　客服是我們的第一類實踐，我們的第二類實踐是對音視頻產品能力的整合，對于有些客戶需要的視頻電話，視頻直播聊天室等能力，融云也選擇了市場上最好的產品，替客戶封裝好。區別于客服的實踐場景，移動端必須使用兩個
SDK，在移動端增加適配層。這類產品融云現在支持比較好的直播聊天室，因為融云的 IM
聊天室能力非常強大，今年視頻直播業務火爆之后，非常多的客戶找融云提供可以支持超大量并發的聊天室，因此我們把聊天室跟視頻直播進行了一個比較好的封裝和整合，方便客戶更加容易的使用。介紹這兩種優秀的實踐模式，除了適合企業開發領域，其實更加適合各個
App 廠商去根據自己的需求集成第三方服務，可以更加靈活的把第三方 SDK 和云服務集成到自己的 App 里。

　　最后謝謝主辦方，謝謝大家。