滴滴國(guó)際化項(xiàng)目 Android 端演進(jìn)
目前大家用滴滴 App 在美國(guó)是可以打車的，對(duì)的，不用下載新的 App，現(xiàn)在的滴滴 App 在美國(guó)打開(kāi)就會(huì)自動(dòng)顯示海外打車頁(yè)面。
國(guó)際化在技術(shù)上有一定的特殊性，主要包括：
(1) 地圖
地圖作為滴滴客戶端重要的支持及基礎(chǔ)，而目前我們的友商都沒(méi)有海外的路網(wǎng)數(shù)據(jù)，國(guó)際化我們需要接入新的國(guó)外地圖提供商。
(2) 對(duì)接不同的運(yùn)力
目前滴滴國(guó)際化是與海外投資的伙伴進(jìn)行合作，比如美國(guó)打車跟 Lyft 合作。
(3) 漫游網(wǎng)絡(luò)
目前國(guó)際化的主要用戶場(chǎng)景還是國(guó)內(nèi)用戶出國(guó)打車，這時(shí)用戶是用國(guó)內(nèi)手機(jī)和運(yùn)營(yíng)商海外漫游接入網(wǎng)絡(luò)。
以上的三個(gè)特殊性決定著我們需要在技術(shù)上的差異，下面的分享也圍繞地圖模塊、漫游網(wǎng)絡(luò)、多業(yè)務(wù)接入項(xiàng)目演進(jìn)進(jìn)行分享。
1. 地圖
這塊主要包括兩大問(wèn)題：(1) 地圖選型，(2) 地圖切換
1.1 地圖選型
滴滴是個(gè)重度依賴地圖的 App，而目前我們的友商及大部分國(guó)內(nèi)地圖提供商都沒(méi)有海外的路網(wǎng)數(shù)據(jù)。
我們前期針對(duì)的場(chǎng)景是國(guó)內(nèi)用戶海外打車，Google Map 依賴 Google Play Service，國(guó)內(nèi)手機(jī)幾乎都沒(méi)有這個(gè) Service，即便安裝了 Google Play Service 部分手機(jī)也無(wú)法運(yùn)行，另外即便都有了，漫游網(wǎng)絡(luò)也不能訪問(wèn) Google Map，所以最靠譜的 Google Map 一開(kāi)始便被排除。
另外國(guó)內(nèi)有些 App 在海外用了 Google Map，不過(guò)是通過(guò)中轉(zhuǎn)下發(fā)地圖切片的方式完成的，我們對(duì)地圖各方面的要求都很高，所以也不合適。
這些都要求我們?nèi)フ乙粋€(gè)合適的國(guó)外地圖。
(1) 海外地圖選型考察點(diǎn)
我們對(duì)地圖強(qiáng)依賴，有些定制需求，如：很多 Marker 并且添加后需要修改、畫圓并可以動(dòng)態(tài)調(diào)整半徑等等
國(guó)外可用地圖數(shù)據(jù)源主要有 OpenStreetMap、Here、Tomtom，OpenStreetMap 是個(gè)開(kāi)源的地圖數(shù)據(jù)源，類似維基百科的模式，所以數(shù)據(jù)很全很新，甚至超過(guò) Google Map，但不可避免會(huì)有些臟數(shù)據(jù)，前期的話我們主要是針對(duì)大城市，OpenStreetMap 的數(shù)據(jù)可以滿足我們的需求。
因?yàn)樯婕暗疆惖乜鐣r(shí)區(qū)溝通，所以我們希望技術(shù)支持力度夠大。
性能包括地圖啟動(dòng)時(shí)間、渲染速度、前端響應(yīng)速度、后端響應(yīng)速度。
在開(kāi)始國(guó)際化前，當(dāng)時(shí)滴滴的安裝包就已經(jīng)很大了，基本是國(guó)內(nèi)主流 App 之首(當(dāng)然現(xiàn)在滴滴 App 已經(jīng)挺小了)，所以我們希望新的地圖夠小。
(2) 海外地圖全面對(duì)比
這次我們調(diào)研了 Mapbox、Nutiteq、Here、Tomtom、Bing 共五款海外地圖。其中
Bing 沒(méi)有 Android 版;
Tomtom 有很古老的 Android 版，但功能過(guò)于簡(jiǎn)單，文檔又幾乎沒(méi)有;
Here SDK 高達(dá) 40M，與他們溝通后，精簡(jiǎn)也只能到 25M，這個(gè)大小對(duì)我們是絕對(duì)接受不了的;
所以我們重點(diǎn)集成和測(cè)試的是 Mapbox 和 Nutiteq 這兩家地圖供應(yīng)商。
Mapbox 和 Nutiteq 的功能和性能都滿足我們需求，地圖數(shù)據(jù)源也都是以 OSM(OpenStreetMap) 為主。
Mapbox 的 API 設(shè)計(jì)和國(guó)內(nèi)地圖類似，都是向 Google Map 靠攏，所以上手簡(jiǎn)單，并且整個(gè) SDK 都是開(kāi)源的，地圖的樣式也更美觀些，而 Nutiteq 的地圖底層設(shè)計(jì)比較獨(dú)特，API 用法很不尋常，這也給我們接入帶來(lái)了很大的麻煩。
Mapbox 有眾多的 Web 用戶，包括訪問(wèn)量都不低的 Foursquare、Pinterest 等，但 Android 端用戶并不多;Nutiteq 的 Android 用戶多些，但整體量也不是很大，不過(guò)我們并沒(méi)有更好的選擇，而且前期我們的量也不會(huì)很大，所以他們都在可接受范圍內(nèi)。
綜合下來(lái)看的話，我們是更傾向于 Mapbox，不過(guò) Mapbox 只能通過(guò) GitHub Issues 和郵件反饋問(wèn)題，反應(yīng)很慢;Nutiteq 可以 Skype 溝通，效率很高。為了保險(xiǎn)起見(jiàn)，Mapbox 和 Nutiteq 都做了全面接入和測(cè)試，最終證明這樣是有用的。
跟多數(shù) App 一樣，為了使得包更小，我們的主工程配置了 abiFilter “armeabi”，僅打 armabi 的 so，而 Mapbox 的 armeabi so 無(wú)法跑在 armv7 機(jī)器上，前期集成測(cè)試我們通過(guò)修改 Gradle 腳本在編譯時(shí) copy so 的方式讓測(cè)試通過(guò)，而 Mapbox 一直不愿意改，國(guó)內(nèi)市場(chǎng)又不支持 Google 的 Apk Splits 機(jī)制，所以最終放棄 Mapbox 而選擇 Nutiteq。
后話：Mapbox ***版已經(jīng)解決了這個(gè)問(wèn)題，而且國(guó)內(nèi)有相關(guān)的市場(chǎng)人員，溝通起來(lái)也順暢多了。
1.2 地圖切換
用不了 Google Map 帶來(lái)一個(gè)要求，我們選擇的地圖必須支持多國(guó)家，并且在設(shè)計(jì)時(shí)要支持以后不同地圖任意切換。是的，即地圖和 App 弱依賴。針對(duì)這個(gè)問(wèn)題我們?cè)O(shè)計(jì)了地圖隔離層。
總體設(shè)計(jì)如下：
上圖第二層 MapSDK 是地圖的標(biāo)準(zhǔn) API 層，App 只與此層打交道，標(biāo)準(zhǔn)層的 API 設(shè)計(jì)以 Google Map API 為標(biāo)準(zhǔn)。
第三層 Adapter 層是具體地圖到標(biāo)準(zhǔn) API 的適配實(shí)現(xiàn)層。每個(gè)地圖都有個(gè) Adapter，負(fù)責(zé)將地圖 API 轉(zhuǎn)換成標(biāo)準(zhǔn) API。
將原來(lái)的 App 與三方地圖直接依賴改為 App 依賴表示標(biāo)準(zhǔn) API 的 MapSDK 層，由 MapSDK 通過(guò)具體的 Adapter 調(diào)用三方 SDK，這樣地圖切換只需要替換依賴的 Adapter 即可，其他地方無(wú)需改動(dòng)。
新的設(shè)計(jì)后編譯依賴關(guān)系如下：
App 依賴 Map Adapter，Map Adapter 依賴我們的 MapSDK 和三方的 Map SDK。
當(dāng)我們需要更換三方地圖 SDK 時(shí)，僅需更換對(duì)應(yīng)的 Map Adapter 即可。對(duì)于 Android，build.gradle 中更換依賴即可。
1.3 新的地圖模塊設(shè)計(jì)的好處
(1) 解耦，切換成本低
這個(gè)上面已經(jīng)介紹，再也不會(huì)因?yàn)閾Q了地圖牽一發(fā)而動(dòng)全身。
(2) 學(xué)習(xí)成本低
業(yè)務(wù)開(kāi)發(fā)人員只需要熟悉標(biāo)準(zhǔn) MapSDK API 即可，不用了解其他地圖的具體使用，時(shí)間成本降低。
(3) 通用
適用于所有 App，以后新增 App，可直接使用之前成型的 Adapter。
1.4 地圖切換實(shí)現(xiàn)的注意事項(xiàng)
(1) 所有 API 適配
理論上 MapSDK 應(yīng)為地圖所有 API ***集，實(shí)際可以根據(jù)情況先去做所需功能的定義和適配。
(2) 標(biāo)尺
需要統(tǒng)一標(biāo)尺，如縮放尺度、相同坐標(biāo)系等。
(3) 未支持 API 處理
因?yàn)闃?biāo)準(zhǔn)層的 MapSDK 是地圖功能***集，所以不可避免某些三方地圖不支持 MapSDK 定義的功能。比如根據(jù)一組點(diǎn)縮放這個(gè)功能，其對(duì)應(yīng)的 Adapter 在實(shí)現(xiàn)這個(gè)功能時(shí)如果是 Debug 模式則拋異常，Release 模式則空實(shí)現(xiàn)。
還有如 MapSDK 的 API 規(guī)范前面已經(jīng)介紹過(guò)以 Google Map API 為標(biāo)準(zhǔn)。另 Adapter 有具體的開(kāi)發(fā)規(guī)范要求。
2. 漫游網(wǎng)絡(luò)
前面介紹過(guò)我們初期針對(duì)的是國(guó)內(nèi)用戶海外打車場(chǎng)景，這時(shí)用戶是用國(guó)內(nèi)手機(jī)和運(yùn)營(yíng)商海外漫游接入網(wǎng)絡(luò)，所以需要針對(duì)網(wǎng)絡(luò)訪問(wèn)進(jìn)行優(yōu)化。
一般漫游網(wǎng)絡(luò)流程如下圖：
用戶由海外運(yùn)營(yíng)商接入國(guó)內(nèi)運(yùn)營(yíng)商，再通過(guò)公網(wǎng)(有墻)訪問(wèn) Web。我們的服務(wù)器部署在 AWS 上，用戶海外漫游打車網(wǎng)絡(luò)流程如下圖：
由于公網(wǎng)訪問(wèn) AWS 非常慢，我們添加了海外專線，優(yōu)化后用戶海外漫游打車網(wǎng)絡(luò)流程如下圖：
用戶先訪問(wèn)到國(guó)內(nèi)的中轉(zhuǎn)服務(wù)器，中轉(zhuǎn)服務(wù)器再通過(guò)海外專線訪問(wèn) AWS。
這個(gè)過(guò)程中客戶端要做的工作包括：
(1) 拉取中轉(zhuǎn)服務(wù)器域名列表
(2) 使用中轉(zhuǎn)服務(wù)器域名列表中域名訪問(wèn)，出錯(cuò)則用原始域名降級(jí)重試
(3) 定時(shí)及推送更新域名列表
這里域名順序由服務(wù)端自己負(fù)載均衡，返回的中轉(zhuǎn)服務(wù)器域名列表是中轉(zhuǎn)服務(wù)器域名還是直接海外域名也由服務(wù)器決定。
3. Android 項(xiàng)目演進(jìn)
3.1 原有模式
之前國(guó)際化業(yè)務(wù)的工程是很簡(jiǎn)單的方式，所有業(yè)務(wù)、組件、工具放在一起，根據(jù)具體包名劃分：
這個(gè)在早期問(wèn)題不大，并且開(kāi)發(fā)起來(lái)快速方便，但隨著更多業(yè)務(wù)接入，如我們前面說(shuō)過(guò)的新的國(guó)家運(yùn)力接入，問(wèn)題就日益明顯，包括：
(1) 組件之間耦合
雖然已經(jīng)劃分包名，但依然可以互相調(diào)用，組件間依賴關(guān)系不清，甚至有循環(huán)依賴。
(2) 添加新業(yè)務(wù)不便
(3) 開(kāi)發(fā)問(wèn)題
規(guī)模越來(lái)越大致提交沖突可能性變大。
3.2 SDK 工程提取
將原工程整體拆分為業(yè)務(wù)工程和 SDK 工程，單業(yè)務(wù)工程直接依賴 SDK，可獨(dú)立開(kāi)發(fā)、獨(dú)立運(yùn)行、獨(dú)立打包。如下：
這樣在接入新的業(yè)務(wù)后，總體項(xiàng)目結(jié)構(gòu)如下圖：
每個(gè)業(yè)務(wù)作為單獨(dú)工程，共用組件、工具、業(yè)務(wù)統(tǒng)一到 SDK 層中。
集成工程負(fù)責(zé)集成 Lyft、Ola、GrabTaxi 項(xiàng)目，所有業(yè)務(wù)項(xiàng)目提供 AAR，由集成工程整體打包對(duì)外發(fā)布。
3.3 SDK 工程組件化拆分
為了解決組件之間耦合，防止后續(xù)問(wèn)題加劇，同時(shí)方便協(xié)同開(kāi)發(fā)和更好的復(fù)用，將 SDK 工程組件化拆分如下：
SDK 整體拆分為 Business Library 和 Util Library 兩大部分，主要依據(jù)是是否可以獨(dú)立于我們業(yè)務(wù)，他們間不允許反向依賴。每個(gè)部分包含若干組件，每個(gè)組件都以 Module 形式存在。
Business Library 為通用業(yè)務(wù)層，包含通用業(yè)務(wù)組件，如平滑移動(dòng)、上車點(diǎn)、定位、地理信息、打點(diǎn)、網(wǎng)絡(luò)封裝。
其中 CommonBusiness 存放暫時(shí)通用、但尚不足以作為一個(gè)單獨(dú)組件的公共業(yè)務(wù)，以后可能獨(dú)立出來(lái)，注意包名規(guī)范方便未來(lái)獨(dú)立。
Util Library 為工具庫(kù)，大致分為 View 和 Util，DidiSDK 為滴滴 App 整體通用組件包，包含通用的圖片緩存、網(wǎng)絡(luò)請(qǐng)求、基礎(chǔ)登陸組件等等。
3.4 SDK 組件化拆分后依賴關(guān)系圖
通過(guò)上圖我們可以發(fā)現(xiàn)即便只是 Business Library 層，組件也根據(jù)依賴關(guān)系劃分為明顯的上下層。
3.5 SDK 組件化劃分事項(xiàng)
(1) 單一及開(kāi)閉原則
每個(gè)模塊只代表一個(gè)功能模塊或一個(gè)公共業(yè)務(wù)，對(duì)于個(gè)性化或定制功能以接口形式對(duì)外開(kāi)放。
PS：目前 CommonBusiness 模塊暫時(shí)作為國(guó)際化 SDK 整體集成打包的模塊，即國(guó)際化 SDK 項(xiàng)目中的 sdk Module，后續(xù)當(dāng)其中某個(gè)公共業(yè)務(wù)足夠成為一個(gè)模塊時(shí)可繼續(xù)拆分出來(lái)。
(2) 拆分粒度
項(xiàng)目的演進(jìn)是不斷進(jìn)行的，沒(méi)必要將每個(gè)細(xì)小組件都拆分出來(lái)，這樣不僅增加了項(xiàng)目的復(fù)雜度，同時(shí)也會(huì)影響編譯時(shí)間。
先根據(jù)實(shí)際需要拆分必要的組件，太小暫不足以獨(dú)立的組件可以在以后不斷進(jìn)行的重構(gòu)中根據(jù)需要拆分。如上面的 CommonBusiness 模塊，當(dāng)然需要保持一定的規(guī)范方便以后拆分。
(3) 依賴關(guān)系
通過(guò)依賴圖整理依賴關(guān)系，防止重復(fù)依賴，同時(shí)看出沉淀關(guān)系。
1. Util Library 不能反向依賴 Business Library;
2. Business Library 除了基礎(chǔ)部分，如 Net、Geo、EventTrack 外，其他部分盡量不要相互依賴;
3. Business Library 中 Net、Geo、EventTrack 不允許反向依賴其他模塊。
(4) 開(kāi)發(fā)規(guī)范
為了保證擴(kuò)展性及方便以后繼續(xù)拆分：
- 所有業(yè)務(wù)包名以 com.didi.{xx}.sdk.{businessName} 開(kāi)頭;
- CommonUtil 模塊中所有工具包名以 com.didi.{xx}.sdk.util.{utilName} 開(kāi)頭;
- CommonView 模塊中所有 View 包名以 com.didi.{xx}.sdk.view.{viewName} 開(kāi)頭;
(5) 組件間通信
放棄原來(lái)造成耦合嚴(yán)重的EventBus，改用原生的通信方式，包括原生 (startActivityForResult) 、內(nèi)部廣播、回調(diào)等。
3.6 SDK 組件化項(xiàng)目整體設(shè)計(jì)圖
其中虛線部分為 SDK 層。
3.7 組件化拆分后的好處
(1) 組件間解耦
(2) 業(yè)務(wù)并行開(kāi)發(fā)、測(cè)試
(3) 組件單獨(dú)測(cè)試
【本文是51CTO專欄作者Trinea的原創(chuàng)文章，轉(zhuǎn)載聯(lián)系作者本人獲取授權(quán)】
