高德客戶端及引擎技術架構演進與思考

2019杭州雲棲大會上，高德地圖技術團隊向與會者分享了包括視覺與機器智能、路線規劃、場景化/精細化定位、時空數據應用、億級流量架構演進等多個出行技術領域的熱門話題。現場火爆，聽衆反響強烈。咱們把其中的優秀演講內容整理成文並陸續發佈出來，本文爲其中一篇。

2019杭州雲棲大會高德技術專場講師系列：

《視覺智能在高德地圖的應用》

《高德在提高定位精度方面的探索和實踐》

《高德億級流量接入層服務的演化之路》

阿里巴巴高級無線開發專家宋照春在高德技術專場作了題爲《高德客戶端及引擎技術架構演進與思考》的演講，主要分享了高德地圖客戶端技術架構沿着「上漂下沉」、「模塊化、Bundle化」的思路演進所作的一系列架構升級中的經驗和思考。

如下爲宋照春演講內容的簡版實錄：

主要分享三個方面的內容：

• 融合
• 架構治理
• 動態化

1、三管齊下 深度融合

高德最初有兩個端，車機版的高德導航，手機版的高德地圖，兩個團隊，一個是2B，一個是2C，分別是汽車業務和手機業務。當時在引擎/技術上，分爲離線引擎和在線引擎，但兩個團隊之間交流比較少，各自有本身的研發、產品和測試，而做爲一款端上的APP，兩塊業務都須要有地圖渲染、路線規劃、導航以及定位等通用能力。從公司層面看，存在較大的重複建設，總體研發效率較低。

因而咱們作了一件事：利用技術手段，打通端上引擎，打造一套能同時支撐多端的APP能力。具體到執行層面，先從A團隊拉一部分人到B團隊一塊兒建設，建設完以後再從B團隊拉到A團隊。在同時支撐好主線業務發展的狀況下，經過一年左右時間，完成了引擎上的融合，作到同時支撐手機、車機以及開放平臺。

這樣就從引擎的維度，實現了渲染、定位、規劃和引導的統一。具體來講，咱們的各大引擎有好多套代碼，好幾個開發團隊，每一個團隊有各自的開發方式和開發環境（Linux，Windows，Mac OS）。各類開發環境，工程配置文件大量重複，修改很是繁瑣。

爲此，咱們經過兩種方法：

1.創建了一套構建系統Abtor，經過一個配置系統實現統一構建，可以同時支持多個子引擎，在構建集成效率上獲得了很大的提高；

2.對基礎庫進行了總體重構，造成了一套涵蓋了文件I/O、KV存儲、多線程框架&異步框架、歸檔、基礎容器等一系列標準能力的基礎庫，同時也作了引擎核心架構的統一。 

2、架構治理

經過引擎的融合同時支持多端，在研發效率上實現比較大的收益。而經過技術的抓手來實現團隊的融合，對公司發展而言，這實際上是更大的收益，團隊融合的意義在於人才拉通和複用，組織效率獲得了較大提高。

隨着高德業務的快速發展，業務上持續擴品類，需求量激增，高德地圖從最初的駕車導航，到後來的步行、騎行、摩托車導航等等，App所承載的業務發展很是快，而原有的架構治理模式的問題也逐漸暴露出來。

首先就是App的代碼規模變得特別大。當時一個倉庫達到了10G以上，由此致使的一個典型的問題就是編譯慢，編譯出一次安裝包須要一個小時。伴隨代碼規模的另外一個問題是團隊規模快速增加。代碼增加和大團隊並行開發，最終致使合版慢，每次迭代，客戶端合版須要2天。

代碼膨脹致使的架構腐化問題特別突出，因此測試質量以及線上的質量有段時間也比較差。此外，從產品提出需求到上線，平均須要45天，版本迭代週期很長。

爲解決以上架構問題，咱們採起了三個手段：升級Native基礎組件，搭建Native容器和頁面框架，Bundle化分拆（微應用）。

下面重點介紹下頁面框架和微應用。

頁面框架主要借鑑和融合了Android和iOS的生命期管理機制。從高德地圖App架構看，下層模塊是一套標準地圖，全部上層業務都要基於地圖模塊開發。爲確保上層業務低耦合、一致性，咱們設計了一個頁面框架。

如上圖，左邊的Activity是Android的系統頁面控制器，右邊的UIViewController是iOS的系統頁面控制器，經過虛線鏈接比較，咱們發現兩端的頁面狀態設計基本相同。

因此，咱們在設計本身的頁面框架時沿用了這些系統頁面狀態，同時從命名上也保持一致，這樣可讓Android和iOS原生開發的同窗更容易理解和上手。

咱們吸收了雙端各自的優勢。好比，Android端頁面有四種啓動模式，可是iOS 端並無這些，咱們就把Android的四種啓動模式運用到了iOS端；iOS端有Present特性，可是Android端沒有，那麼也把這種特性融合到Android端的頁面框架中；最後，還有一些小設計，好比Android的onResult設計，也能夠借鑑融合到iOS端。

此外，咱們還作了微應用，所謂微應用，首先是模塊化，就是把大模塊倉庫大模塊拆成一個個小的Bundle，除了實現模塊化，還主要實現如下幾個目標：

粒度：以業務爲單位，以業務線爲分組

編譯：二進制級別的產物，可獨立編譯、出包時連接

依賴：鬆耦合，以「服務」爲導向，不關心模塊歸屬

而Native容器層面，要實現四個核心目標：路由管理、服務管理、UI生命期管理、微應用管理。

經過一年時間的Bundle化改造，高德地圖單端App完成了300多個頁面的建設，拆分了100多個Bundle。

從收益來看，總編譯時間從原來的60分鐘下降到了8分鐘，合版週期從原來的3天降到1天，需求上線週期降到了1個月之內，線上質量和測試質量都獲得了極大的提高，崩潰率從萬分之八下降到十萬分之八。

3、動態化

隨着高德地圖業務發展沿着擴品類、在垂直品類作精作細，景區、酒店、銀行商鋪、充電樁等個性化定製需求凸顯，對前端展示提出了更高的要求，對「快速應變」要求也更高了。

實際上，在2015年，高德就開始作動態化。最先的時候業內就有React Native，團隊作了技術調研，發現不能徹底知足業務上的須要，尤爲是性能方面。最後咱們決定自研一套動態化技術。

具體來講，就是經過一個核心C++引擎，把兩端業務（Android、iOS）用一套JavaScript代碼解決，實現雙端歸一，Android實現業務動態化發佈。

架構層面，最下面是高德App核心的地圖引擎，咱們在上面搭建了一套動態化應用引擎，經過C++來實現。應用引擎的做用是爲了承上啓下，上面承載動態化業務，下層完成地圖引擎的直接打通。衆所周知，GUI的核心是DOM樹，因此應用引擎不但要實現和JavaScript引擎的整合，還要負責DOM樹的核心邏輯計算。

其次，動態化的技術和前端Web技術一致：樣式、佈局。應用引擎負責完成樣式的佈局計算、DOM樹Diff、事件生成。而GUI的繪製，經過Diff事件，交由原生的Android以及iOS去完成。這樣，全部的GUI都是原生的組件。

在之上，咱們搭建了一套前端框架，前端框架採用當前前端響應式框架作，前端框架之上又搭建了一套前端的UI卡片庫和UI組件庫，讓上層業務可以更高效的開發。

而對於一些經過動態化的技術沒法實現，或者性能上存在卡點的功能，咱們就經過Native擴展能力來支撐，這樣，完整的動態化的業務可以直接運行在Android以及iOS上。 

JS去執行代碼以後，前端框架會產生虛擬的DOM樹，最後提交到C++引擎，造成C++的DOM樹。C++引擎去完成佈局、樣式計算，Diff計算，將每一個節點的屬性和座標交給Android以及iOS，由Native來完成最終UI的渲染。

整體來講，動態化的特色：首先是它與主流前端框架融合，充分融合了大前端的生態；第二，性能、擴展性較好。由於採用C++實現整個核心邏輯，靜態和動態的語言綁定技術，可以保證地圖引擎的能力可以直接透出到上層，或者從上層可以直接call底層的C++能力；第三，多端歸一和動態化，充分利用Native優點，接近原生Native體驗。

動態化技術改造完成以後，雙端不一致的問題下降了90%，開發、測試成本下降30%，發版週期從T+30到T+0。

最後，總結下高德客戶端及引擎技術架構演進的幾個重要階段：第一個階段，經過在線&離線引擎的融合拉通，讓高德最核心的導航能力提到提高；第二階段，在客戶端發展成爲「巨型」APP，代碼量發展到超大規模的時候，經過架構治理，知足業務快速增加的訴求，解決大規模業務體量下的架構合理性問題，消除架構瓶頸；第三個階段經過動態化的技術，實現多端歸一，以及動態發版能力，爲業務發展提供更大的助力。

---

本文做者：高德技術小哥

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。