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

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

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

　　以下是演講精彩內(nèi)容：

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

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

　　我們這次要分享的內(nèi)容是，首先介紹一下融云，然后介紹一下融云 IM SDK 架構(gòu)，第三部分是分享一下 IM SDK
實現(xiàn)過程中那些價值千金的經(jīng)驗，最后分享通過 IM 社交如何實現(xiàn) SaaS 級的服務(wù)。

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

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

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

　　接下來分享我們第一個有價值的經(jīng)驗，IM 協(xié)議的選擇。

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

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

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

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

　　我們?yōu)槭裁催x擇做一個界面SDK 呢，因為實際上在移動端，UI 的開發(fā)量是極大的，一般占
80%以上。輸入?yún)^(qū)，表情，圖片選擇器，會話界面，消息展現(xiàn)等等，一般需要一個工程師1個月的時間開發(fā)，1個月的時間調(diào)試。兩個端就是4~6個月。而且老板和產(chǎn)品經(jīng)理還覺得很容易，雖然確實是不難，但是其實細(xì)節(jié)上做出來性能效果差別都很大的。我們的一個價值觀就是：我們每多做一些，開發(fā)者就少做一些，所以我們選擇把界面封裝起來替客戶做完。當(dāng)然也有缺點，IMKit
是一個非常重的封裝模式，接口很多，使用方式復(fù)雜，我們選擇不斷的去優(yōu)化，未來我們會進(jìn)一步解耦合把核心的部分再次封裝。另外我們?nèi)谠频目蛻糁С址?wù)工作做的很好，可以提工單像我們咨詢。我們每天有很多研發(fā)工程師回復(fù)200個左右的客戶工單問題，在此也感謝我們?nèi)谠七@些工程師。

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

　　第三個有價值的經(jīng)驗是正確的版本迭代姿勢。也是今天的點睛之筆。前面介紹的技術(shù)選擇，不能說絕對正確，但也都是基于我們?nèi)谠瀑Y深團(tuán)隊這么多年的經(jīng)驗，幾萬開發(fā)者的集成經(jīng)驗。有優(yōu)點也有缺點，那么通過什么方式彌補(bǔ)優(yōu)點就很重要。比如使用
native 語言實現(xiàn)協(xié)議棧，優(yōu)點很多，但缺點是 Android 上的包比較大。那么解決的辦法就是不斷優(yōu)化每一行代碼去優(yōu)化包的大小。提供 IMKit
的優(yōu)點是節(jié)省了用戶的時間，但是缺點就是支持使用復(fù)雜，那么我們就進(jìn)一步去拆解和封裝。技術(shù)選擇只是第一步，之后的不斷持續(xù)優(yōu)化才是一切。

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

　　所以結(jié)合起來說就是，做出正確的選擇，通過不斷的迭代努力去優(yōu)化自己的產(chǎn)品，永不停止。

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

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

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

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