細(xì)想，團隊進行跨平臺開發(fā)已有三年有余，也是集團里面C++方向里比較早涉及該領(lǐng)域的部門之一，伴隨業(yè)界跨平臺技術(shù)發(fā)展與演進，我們也沉淀了一整套基于C++的跨平臺技術(shù)體系。

關(guān)于為什么要選擇跨平臺的實現(xiàn)方式

Write Once， Run AnyWhere.

越來越多的業(yè)務(wù)需求都有統(tǒng)一的業(yè)務(wù)訴求，按照傳統(tǒng)的方式，在開發(fā)、測試、維護上的成本都是乘以N的，體驗也很難做到一致性，特別是復(fù)雜的業(yè)務(wù)，實現(xiàn)成本高，導(dǎo)致功能不能很快的上線，各端側(cè)對齊存在成本，綜合來看，這樣或者類似的業(yè)務(wù)基于研發(fā)效率等考慮，選擇用跨平臺的實現(xiàn)方式是非常有必要的。

這里以電商的消息為例，

多角色的運營，多場景的觸發(fā)，多重能力的支持，導(dǎo)致我們的消息系統(tǒng)十分的復(fù)雜，歷史發(fā)展下的多通道消息系統(tǒng)底層由于歷史發(fā)展衍生出3個子系統(tǒng)分別是：

1. BC消息 - 最早的阿里旺旺就是基于此
2. AMP消息 - 淘寶天貓的各類運營基于此，衍生出來的主要業(yè)務(wù)包括商家群、淘友、達(dá)人業(yè)務(wù)等，
3. IMBA消息 - 主要是號方面相關(guān)的消息，包括BC通知類的消息、達(dá)人運營，品牌號運營等

分別在不同的BU維護，而這些在多平臺運營下都是需要的，比如多角色的融合，多載體運行的訴求，每個載體又有多種平臺。基于以上背景，研發(fā)一個高可用、高復(fù)用、可定制的跨終端消息模塊是非常有必要的。

關(guān)于語言的選擇

選擇編譯型語言還是解釋型語言，我覺得是沒有絕對而言的，具體選擇哪個要根據(jù)面對業(yè)務(wù)形態(tài)，適配的終端類型等多方面抉擇而言，這里說下我們選擇C++作為跨平臺開?發(fā)的首選語言一些背景。

1. 我們團隊本身是客戶端的業(yè)務(wù)型團隊，當(dāng)前需要跨平臺的業(yè)務(wù)主要是消息以及消息衍生業(yè)務(wù)的開發(fā)、維護和創(chuàng)新。
2. 主要的終端包括移動IOS、移動安卓、MAC、WINDOWS。
3. 主要載體包括淘寶app、天貓app、千牛app、淘特app、1688app、ICBU app等等。

C++作為天然的跨平臺語言，可以高效無縫的調(diào)用系統(tǒng)能力，有豐富的技術(shù)生態(tài)，綜合組內(nèi)的技術(shù)棧，是比較契合我們的。

其實也跟集團里其他幾個有類似需求的團隊聊過，目前選擇比較多的也是C++技術(shù)棧，本文也將以C++作為跨平臺選型語言為主要來講述。

即使是對于客戶端而言，可選擇跨平臺語言也是眾多的，通常跟隨著跨平臺技術(shù)方案一起來看會比較好一些，沒有絕對的對和錯，只有是否適合你。

關(guān)于基礎(chǔ)庫的選擇

既然選擇了C++作為我們跨平臺開發(fā)的基礎(chǔ)語言，那么面臨的第一個問題是需要有一個功能較為完備，且符合當(dāng)前訴求的基礎(chǔ)庫。我們調(diào)研了市面上幾個主流的基礎(chǔ)庫

再結(jié)合集團內(nèi)當(dāng)時的現(xiàn)狀，特別考慮移動端的現(xiàn)狀：

1. 包大小問題
2. 集團中多種中間件（mtop、db、accs等）要不然已然跨終端，要不然在各端上都有較為優(yōu)秀的獨立sdk提供，基于第一點考慮，這一部分不需要在基礎(chǔ)庫里二次建設(shè)。

綜合以上因素，集團內(nèi)沒有合適的足夠小的且滿足需求的c++基礎(chǔ)庫，因此我們當(dāng)時決定自研一個基于C++ STD的符合移動端現(xiàn)狀的輕量級跨終端基礎(chǔ)庫。

這里是跨終端輕量級基礎(chǔ)庫(LITE)的一個功能集合圖，在對這部分進行設(shè)計的時候，主要考慮的幾個設(shè)計原則：

1. 基礎(chǔ)能力要圈覆蓋，
2. 綜合考慮包大小，性能 以及耗電量等
3. 除了提供默認(rèn)實現(xiàn)外，當(dāng)系統(tǒng)層面有比較好的能力、或更優(yōu)解時時，復(fù)用端上的能力，通過統(tǒng)一的方式嫁接。舉個例子，集團中間件mtop，accs等，亦或者諸如Crypt模塊，我們期望用比較簡單的方式去實現(xiàn)，調(diào)用了Openssl的加解密接口，熟悉Openssl的同學(xué)都知道他的庫大小在1M左右，同時IOS系統(tǒng)直接就提供Openssl能力，所以在做這一部分的時候我們提供了默認(rèn)實現(xiàn)，同時開放統(tǒng)一接口接入系統(tǒng)能力，從而實現(xiàn)包大小最優(yōu)。

總結(jié)一下設(shè)計原則9個字：最小夠用可擴展原則。

平臺	包大小(kb, 基礎(chǔ)功能)	說明
ANDROID	43kb	動態(tài)庫，v8a
IOS	116	靜態(tài)庫，實際占app大小
Windows	47kb	x86

包大小情況如圖（未包含淘寶天貓基礎(chǔ)客戶端能力，包含后略增加60k左右）。

目前Lite庫已經(jīng)作為淘系C++基礎(chǔ)庫集成在集團的近100個App里，除了包大小優(yōu)勢外，穩(wěn)定性也極佳，百萬分之1左右的崩潰率（淘寶雙端統(tǒng)計），同時與淘寶天貓架構(gòu)組合作，無縫提供淘寶天貓客戶端基礎(chǔ)能力（log、埋點、鍵值存儲等）。

關(guān)于跨平臺的架構(gòu)選擇

通常技術(shù)還是為業(yè)務(wù)服務(wù)，還是貼近業(yè)務(wù)來講述，能更有體感一些，這樣也更直觀的把我們遇到的問題和背后思考透漏給大家，作為參考，還是以消息為例：

我們面臨的問題和訴求：

1. 屏蔽通道，以統(tǒng)一的數(shù)據(jù)模型方式對外提供：底層需要對接3個服務(wù)端（多通道），同時每個server端提供的能力、功能又高度相似，需要抽象后統(tǒng)一屏蔽提供給上層，此外相關(guān)數(shù)據(jù)需要跨通道或者屏蔽通道存儲。
2. 調(diào)用方線程不統(tǒng)一：業(yè)務(wù)部分需要處理來自不同線程的高并發(fā)（于客戶端而言）請求。
3. 多語言：接入層需要適配不同平臺，ANDROID-JAVA，IOS、MACOS-Object C，WIN-C++。
4. 多維度支持定制：

1. 業(yè)務(wù)定制：業(yè)務(wù)上需要面對不同的APP可以有不同的功能定制，這里還包括支持通道的可配置，業(yè)務(wù)能力的可定制等，舉個例子：在淘特里無群聊服務(wù)，但是在淘寶里這一部分又是需要的，在千牛里需要有商家群，但不需要有淘友關(guān)系群，等等基于業(yè)務(wù)、以及包大小考慮的定制。
2. 線程調(diào)度定制：基于耗電量、系統(tǒng)資源、平臺特性等考慮，需要線程調(diào)度方案的可定制。在移動端對耗電量比較敏感且系統(tǒng)資源有限，但是PC端上對性能要求會更高一些，如何在統(tǒng)一的方案里支持線程調(diào)度的平臺級、甚至是業(yè)務(wù)級別定制。
3. 網(wǎng)絡(luò)流量管理定制：對網(wǎng)絡(luò)能力一方面要有統(tǒng)一的監(jiān)控，方便判斷MTOP的各種API調(diào)用情況分析，另一方面需要有統(tǒng)一的切面能力，在MTOP的調(diào)用上做二次業(yè)務(wù)級別的網(wǎng)絡(luò)流量接口優(yōu)化定制。
4. DB管理定制：基于FD、平臺特定等考慮，需要DB管理可以根據(jù)不同的平臺有不同的定制策略，在移動端采用單用戶一庫多表的形式，在pc端性能最大化采用多庫多表甚至需要支持不同app的不同db管理方案可定制。

1. 基礎(chǔ)能力復(fù)用：對于集團通用的基礎(chǔ)組件，需要有統(tǒng)一的能力從外部獲取從而方便c++層使用。
2. 穩(wěn)定性保障：是否方便做單元測試，設(shè)計上如何避免單元測試對內(nèi)部代碼的入侵。

基于以上，我們設(shè)計了MessageSDK的架構(gòu)大致如下：

來整體看下上面的設(shè)計是如何解決這些問題的。

總體分5部分，Service層，業(yè)務(wù)層，數(shù)據(jù)層，數(shù)據(jù)通道層以及基礎(chǔ)服務(wù)層。從上到下看整個架構(gòu)設(shè)計

1. Service層：也就是我們通常說的Wrapper層，其目的是為了翻譯業(yè)務(wù)層C++的接口，提供三種方式的直接接入，Java，Oc，C++，需要說明的是這一層不要做除語言轉(zhuǎn)換外的任何代碼，一來方便問題排查，wrapper不做額外的處理和問題排查，二來業(yè)界也有不少自動化實現(xiàn)語言翻譯的工具，有關(guān)這部分我們后面部分詳細(xì)聊。
2. 業(yè)務(wù)層：業(yè)務(wù)邏輯的一個組合，以消息為例，按模塊分為三個子模塊第一個消息模塊，第二個profile模塊，第三個群模塊，模塊與模塊之間相對獨立，做強制隔離，代碼無耦合，功能可定制化
3. 數(shù)據(jù)層：分為兩部分本地存儲以及網(wǎng)絡(luò)存儲，其目的是屏蔽數(shù)據(jù)來源以統(tǒng)一的方式提供給業(yè)務(wù)層，讓業(yè)務(wù)不感知通道來源，同時在這一層還吃掉所有的耗時操作，IO以及網(wǎng)絡(luò)請求，其中Adpter主要是屏蔽通道之間的差異，這一部分支持整體可替換，目的提高擴展性，可定制接入三方通道
4. 數(shù)據(jù)通道層：這一部分就是數(shù)據(jù)來源的通道，主要有SYNC，WXNet，DB等
5. 基礎(chǔ)服務(wù)層：是一個跨平臺的c++基礎(chǔ)庫。

其實客戶端按層分割的設(shè)計理念，無論是在PC時代還是現(xiàn)在的移動互聯(lián)，都不是什么顯而易見的事兒，主要關(guān)注下這里面的差異點也可以說是這種框架設(shè)計的優(yōu)點。

1. 便捷：service我們只做語言層面的膠水，縮短后期排查問題的整個鏈路，方便后期排查和定位問題。同時自動化的實現(xiàn)也再次降低了維護成本。
2. 開放：上圖右側(cè)是Openpoint能力，主要是通過一些標(biāo)準(zhǔn)化的開放點去開放一些能力，讓接入方做更多的業(yè)務(wù)屬性，簡單來說【每個業(yè)務(wù)有特定的開放點，用統(tǒng)一的形式開放出去】
3. 定制：

1. 業(yè)務(wù)定制：模塊與模塊之間相互完全獨立，代碼無耦合，強制隔離，實現(xiàn)功能的可定制化，讓業(yè)務(wù)方可以自由的進行業(yè)務(wù)形態(tài)組合的同時做到包大小最優(yōu)，
2. 線程調(diào)度定制：統(tǒng)一線程調(diào)度處理方案，抽象線程配置策略，多app可自由配置，上層可選擇平臺級線程調(diào)度最優(yōu)方案。
3. 網(wǎng)絡(luò)流量管理定制：網(wǎng)絡(luò)調(diào)用處統(tǒng)一切面處理，一方面對瞬時相同請求做攔截合并，大幅度降低服務(wù)端壓力，另一方面針對業(yè)務(wù)級別做原子調(diào)用的合并定制，減少服務(wù)端查詢量，此外切面處進行統(tǒng)一打點處理，方便客戶端做調(diào)用流量監(jiān)控。
4. DB管理定制：同線程調(diào)度定制，統(tǒng)一DB管理分配方案，抽象庫分配策略，多app可自由配置，上層可選擇平臺級線程調(diào)度的最優(yōu)方案。

1. 擴展：對外提供整體能力，又可以動態(tài)替換，目的是提供一種能力讓接入方可以放入自己的數(shù)據(jù)通道，從而實現(xiàn)一個業(yè)務(wù)的擴展，此方法也極大的方便了后期做統(tǒng)一的單元測試。

于CPP程序員而言，線程模型是非常重要的，好的設(shè)計可以從架構(gòu)上就避免掉后期一系列隱秘的bug，這里包括一系列問題，比如：

1. 在移動端上，通常調(diào)用者不關(guān)心調(diào)用線程，但是在數(shù)據(jù)層又需要做統(tǒng)一的數(shù)據(jù)修改和聚合能力
2. 業(yè)務(wù)層頻繁調(diào)用，過多的鎖除了可能會出現(xiàn)死鎖外，也不利于性能最大化。
3. 部分接口如果IO、NET時間過長可能導(dǎo)致整個流程中斷，或異常。

來看下跨終端SDK架構(gòu)設(shè)計的線程模型：

1. 接入層：不限制調(diào)用線程，降低接入成本
2. 業(yè)務(wù)層 : 按模塊做隔離，單獨運行在自己的業(yè)務(wù)線程里，在biz層做業(yè)務(wù)無鎖話的同時，做到單業(yè)務(wù)無鎖化，多業(yè)務(wù)并行化
3. Model層 : 主要是做IO、網(wǎng)絡(luò)操作，目的是為了業(yè)務(wù)線程IO、網(wǎng)絡(luò)無阻塞

整個線程模型的特點：純異步，可定制，單業(yè)務(wù)無鎖化，多業(yè)務(wù)并行化，IO網(wǎng)絡(luò)無阻塞。

C++工程腳手架及C++工程標(biāo)準(zhǔn)化

C++作為天然的跨平臺語言，可以高效無縫的調(diào)用系統(tǒng)能力，有豐富的技術(shù)生態(tài)。但是實際面向Android、iOS、Windows、Mac等多平臺的開發(fā)過程并不順滑，主要存在以下問題：

1. 平臺特性差異、開發(fā)語言、開發(fā)工具鏈、編譯打包等
2. 多平臺下項目配置維護成本高
3. 膠水(語言轉(zhuǎn)換層)代碼人工接入成本高、重復(fù)性工作大、門檻高(主要是對于C++開發(fā)者)
4. 業(yè)務(wù)及技術(shù)框架選型困難
5. 構(gòu)建發(fā)布方案規(guī)范化較差、集團研發(fā)平臺對跨平臺構(gòu)建發(fā)布的設(shè)計不足

我們在想，SDK開發(fā)流程是否可以是一個可被SOP的過程？如果有統(tǒng)一的跨平臺SDK開發(fā)SOP流程，特別是對于新入此行的同學(xué)，當(dāng)然是非常友好的。想想coder如果可以上來就可以寫業(yè)務(wù)代碼，不用關(guān)心框架，工程模型，打包方案等等，是不是美滋滋。

為了解決上述共性問題，結(jié)合之前我們在消息SDK上的相關(guān)經(jīng)驗，我們啟動了Eyas(雛鷹)項目。

Eyas旨在進一步結(jié)合集團技術(shù)能力，降低跨終端開發(fā)成本，為其提供標(biāo)準(zhǔn)化的作業(yè)流程，包括跨平臺基礎(chǔ)庫組件化、業(yè)務(wù)框架通用化、配置一體化、語言轉(zhuǎn)換層代碼工具化，以及發(fā)布能力統(tǒng)一化等一整套解決方案，讓開發(fā)者們可以在輕量級認(rèn)識跨終端的同時，更專注于業(yè)務(wù)本身。

Eyas的中文是雛鷹，我們希望通過Eyas，可以一起在跨終端的藍(lán)海中探索無限可能，同時可以孵化出更多跨平臺的模塊，讓開發(fā)者低成本開發(fā)跨平臺SDK，保證多平臺業(yè)務(wù)一致性，提升業(yè)務(wù)開發(fā)效率的同時降低測試成本。

為了讓開發(fā)者可以更快的上手跨平臺的開發(fā)，我們擬定了一套跨平臺SDK開發(fā)的作業(yè)流程，同時在每一步都提供了對應(yīng)的解決方案，所有的解決方案均提供工具化的方式來高效、低成本的輔助開發(fā)者們進行跨平臺SDK的開發(fā)。下圖是MTL4上C++跨平臺研發(fā)工作流：

其中 IDL(接口描述)的編寫 以及 功能代碼編寫，需要開發(fā)者根據(jù)實際業(yè)務(wù)進行開發(fā)。我們從項目創(chuàng)建、代碼生成、編譯選項和構(gòu)建四個維度分析。

?  創(chuàng)建項目

跨終端團隊在以往的桌面端開發(fā)中積累了很多SDK開發(fā)經(jīng)驗，也有一套成熟的SDK框架代碼，但是我們在孵化新SDK時候，還是要花一定時間在SDK的通用代碼的拷貝上，無法快速的復(fù)制出一個新的SDK項目。

開發(fā)者都是懶惰的，為了盡可能的復(fù)用代碼，提升開發(fā)效率，開發(fā)者發(fā)明了宏，也發(fā)明了模板編程。為了支持復(fù)用SDK框架通用代碼和項目配置，我們提供了基于項目模板創(chuàng)建項目的工具，快速實現(xiàn)項目工程從0到1的過程。

其實對于剛涉足到跨終端開發(fā)的開發(fā)者，創(chuàng)建了可以編譯不同平臺產(chǎn)物的項目就已經(jīng)開啟了跨平臺的大門。

?  代碼生成

代碼生成即語言膠水層代碼工具化，由于平臺開發(fā)的語言差異，需要有一層膠水代碼來進行語言的翻譯，膠水代碼本身是沒有業(yè)務(wù)邏輯的，并且耗費開發(fā)成本，人工編寫代碼也會帶來出錯的風(fēng)險。我們使用膠水代碼自動化來解決該問題。

膠水代碼自動化的原理:

根據(jù)接口的idl描述生成接口文件和膠水代碼

JNI: C++ <-> Java交互的膠水代碼ObjCPP: C++ <-> ObjC交互的膠水代碼

我們基于djinni（地址：https://github.com/dropbox/djinni）進行了二次開發(fā)，提升安全性的同時增加了多項feature，更容易對復(fù)雜項目做模塊定制化能力。

?  編譯配置+依賴管理

項目結(jié)構(gòu):

支持以下能力：

1. 使用GN管理工程和源碼文件，確保多端的C++項目配置一致。
2. 統(tǒng)一多平臺業(yè)務(wù)模塊定制化能力。
3. 支持多平臺下不同IDE編碼和調(diào)試。
4. 結(jié)合集團技術(shù)能力，統(tǒng)一依賴管理解決方案，支持通過一份配置文件管理多平臺下的依賴。

團隊介紹

我們是大淘寶技術(shù)部行業(yè)與商家技術(shù)跨終端技術(shù)團隊，業(yè)務(wù)上負(fù)責(zé)為千萬級商家打造最高效的一站式工作臺千牛，為淘寶上億商家和消費者提供穩(wěn)定高效的端到端消息IM服務(wù)；技術(shù)上深耕C++跨終端及PC桌面端技術(shù)（Window?s&Mac），為商家，消費者提供穩(wěn)定，可靠，高效的客戶端產(chǎn)品。

文章名稱：跨全端SDK技術(shù)演進
網(wǎng)站網(wǎng)址：http://uogjgqi.cn/article/cdppjjp.html