3倍+提高，高德地圖極致性能優化之路

1.導讀

隨着移動互聯網的成熟發展，移動應用技術上呈現出多樣化的趨勢，業務上傾向打造平臺及超級入口，超級應用應運而生。但業務快速擴張與有限的系統資源必然是衝突的，如何實現多（能力服務的高增加）、快（體驗流暢）、好（兼容穩定）、省（資源成本低），讓大象也能跳舞，成爲擺在超級應用面前必須解決的問題。

 

伴隨着高德地圖APP近幾年的高速發展，也面臨到這些問題，從2019年開始，咱們開啓了一系列性能優化專項，對高德地圖APP進行了深刻性能分析和極致優化，取得比較顯著的效果。在這個過程當中總結了一系列優化思路和技術方案，但願對一樣面臨超級應用性能問題的你有所幫助。

 

通過一系列優化動做，咱們在保證業務需求正常迭代新增的基礎上，啓動、核心鏈路交互、行中內存、包大小等多方面均實現了性能的成倍提高，尤爲是低端機上達到了3倍+的提高，從多個維度改善了用戶性能體驗。

• 啓動攻堅：啓動耗時下降70%+，實現2s地圖元素完成展現，並管控保持在穩定低水位，呈降低趨勢。
• 核心鏈路交互優化：在搜索、路線等鏈路上實現中高端機型秒開、低端機型2s內打開，總體提高用戶流暢交互體驗 。
• 行中內存優化：全機型優化了30%左右，提升穩定性。
• 包大小攻堅：雙端體積下降20%，提升安裝轉換率。

2.性能優化業務背景

某段時間，高德地圖APP面臨着性能惡化、管控困難的問題。以啓動耗時爲例，雙端啓動等待體感明顯，而且歷史上治理後出現反覆，總體呈上升趨勢，咱們思考問題背後的問題，主要有如下幾個方面：

 

業務龐大

超級應用通常都經歷這樣的發展過程。首先，應用提供服務給用戶，用戶開始增加，增加的用戶會產生更多的需求。應用爲知足新增需求不斷迭代，提供新的服務。新的服務推進用戶進一步增加，進入下一個循環。正是在這個正循環發展中，應用像滾雪球同樣越滾越大，終於成爲超級應用。

 

然而，隨着業務需求的不斷增加，業務量和複雜度也隨着上升，系統資源會越佔越多。但機器資源是有限的，資源的爭奪不可避免地會致使性能問題，從而影響用戶體驗和業務擴展，成爲超級應用正循環發展的攔路虎。

高德地圖也一樣經歷了這樣的過程，隨着這幾年的快速發展，應用從手機擴展到了車機，平臺從iOS、Android擴展了Windows和Liunx，覆蓋10多種出行方式的同時，還在不斷提供組隊、視頻、語音、AR等新服務。與此相應的是單端代碼行超百萬行，線程上百，任務上千，形成了持續的性能壓力。

 

環境複雜

性能問題面臨的另外一個主要挑戰是超級應用的環境複雜。一方面，隨着移動設備的長線發展，系統碎片化狀況愈來愈嚴重，Android系統橫跨11個主版本，iOS橫跨14個主版本，加之設備廠商對系統進行各類各樣的改造，進一步增長了系統的碎片化；另外一方面，用戶移動設備的環境是很是不穩定的，電量、溫度的變化以及其餘應用的搶佔都會形成內存、CPU、GPU等資源波動。複雜不可控的環境爲一致的性能體驗的保持增長了很大的難度。

 

但做爲大用戶體量的超級應用，任何環境的體驗都要保證。特別是地圖領域，用戶習慣對不一樣產品直接對比，任何環境下性能體驗問題，都會直接影響產品的總體口碑，致使用戶流失。因此須要兼顧全部環境，不僅是主流機型系統和場景，在長尾場景與機型系統上也必須流暢運行，這就要求超級應用這頭大象不但要在舞臺上跳舞，在凳子上、甚至在水裏也能跳舞。

 

技術鏈路長

爲了知足研發效率提高、產品動態化等多樣需求，移動應用技術上除支持原生開發外，也要支持小程序、Web H五、C基礎庫等跨平臺、容器化、動態化開發。從高德APP來看，最頂層業務除了OC、Java外，還支持JS開發。支撐層提供了AJX、小程序、原生、C等多種容器框架，同時還涉及JS、JNI等橋接層。最下面則用C++提供地圖各個引擎能力，這裏包括OpenGL、定位傳感器融合等多種底層能力。技術鏈路自上而下開始變得長且複雜，鏈路上任何一環均可能致使性能問題，原有的單技術語言的排查工具已經沒法定位明確性能卡點模塊，爲性能排查和管控帶來挑戰。

 

3.解法：低成本優化遷移，長線管控

基於上面的問題，原有傳統的一招鮮的優化方案，顯然解決不了需求日益增加和複雜環境下的性能一致體驗。因此，咱們在專項實踐過程當中，沉澱了一套自適應資源調度框架，解決歷史性能問題的同時，可以在不影響現有的研發效率的狀況下，低成本優化遷移，實現新業務高性能的開發。此外，從系統底層進行全維度資源監控，自動定位分發問題，來實現長線管控，避免先治理後反彈的狀況。

 

自適應資源調度框架

自適應資源調度框架在應用運行過程當中，感知採集運行環境。而後對不一樣環境狀態進行不一樣的調度決策，生成相應的性能優化策略，最終根據優化策略執行對應優化功能。與此同時，監測調度上下文以及調度策略執行效果，並將其反饋給調度決策系統，從而爲進一步的決策調優提供信息輸入。這樣，能夠作到在不一樣的運行環境下都能達到可預期的極致性能體驗。而且，整個過程，對業務無需額外開發，作到無感接入，避免影響業務開發效率。

• 環境感知

感知環境分爲硬件設備、業務場景、用戶行爲和系統狀態四個維度：

• 硬件設備上，一方面經過集團實驗室對已知設備進行評測跑分肯定高中低端機型，另外一方面在用戶設備上本地對硬件進行實時算力評估。
• 業務場景上，將業務分爲前臺展現、後臺運行、交互操做等幾類，通常狀況下前臺正在進行交互操做的業務場景優先級最高，後臺數據預處理業務場景優先級最低。對於同類別業務場景，根據業務UV、交易量、資源消耗等維度進行PK，肯定細分優先級。
• 用戶行爲上，結合服務用戶畫像和本地實時推算，肯定用戶功能偏好和操做習慣，爲下一步針對用戶的精準優化決策作準備。
• 系統狀態上，一方面經過系統提供接口獲取諸如內存警告、溫度警告及省電模式等來獲取系統極端狀態，另外一方面經過對內存、線程、CPU和電量進行監控，來實時肯定系統性能資源狀況。

• 調度決策

感知到環境狀態以後，調度系統將結合各類狀態與調度規則，進行業務以及資源調配決策：

• 降級規則：在低端設備上或者系統資源緊張告警（如內存、溫度告警）時，關閉高耗能功能或者低優先級功能。
• 避讓規則：高優先級功能運行時，低優先級功能進行避讓，如用戶點擊搜索框時到搜索結果徹底展現到時間段內，後臺低優任務進行暫停避讓，保證用戶交互體驗。
• 預處理規則：依據用戶操做及習慣進行預處理，如某用戶一般在啓動3s後，點擊搜索，則在3s以前對該用戶搜索結果進行預加載，從而在用戶點擊時呈現極致的交互體驗效果。
• 擁塞控制規則：在設備資源緊張時，主動下降資源申請量，如CPU繁忙時，主動下降線程併發量；這樣在高優任務到來時，避免出現資源緊缺申請不到資源性能體驗問題。

• 策略執行

策略執行分爲任務執行和硬件調優：其中任務執行，主要是經過內存緩存、數據庫、線程池和網絡庫對相應任務的進行運行控制，來間接實現對各種資源的調度控制。而硬件調優，則是經過與系統廠商合做，直接對硬件資源進行控制，如CPU密集的高優業務開始運行時，將提升CPU頻率，並將其運行線程綁定到大核上，避免線程來回切換損耗性能，最大化地調度系統資源來提高性能。

 

• 效果監測

在資源調度過程當中對各個模塊進行監測，並將環境狀態、調度策略、執行記錄、業務效果、資源消耗等狀況反饋給調度系統，調度系則統以此來評判本次調度策略的優劣，以作進一步的調優。

 

全維度資源監控

因爲技術鏈路長、關聯模塊複雜，原來出現性能問題時，須要全部相關方集中排查，check全部的改動代碼，依賴我的經驗判斷代碼的成原本定位問題，協做和排查成本都很高，致使性能管控有效落地阻力很大。因此咱們就思考，性能問題的根本是硬件資源的競爭，那能不能逆向解題，反過來對資源成本進行監控，若是發現異常再回溯產生成本的代碼，以及分發給相應owner.

那基於這個思路，在構建的時候，首先經過代碼掃描創建代碼模塊關聯庫。而後，進行成本和調用棧採集。採集完成後，對基線版本和當前版本的成本進行對比，若是發現異常，則經過符號反解異常成本的調用棧直接定位到問題代碼。另外，基於問題代碼查找代碼模塊關聯庫，來定位問題模塊，最後將問題準確分發給模塊相應的owner，最終實現問題的自動定位和分發，支持團隊並行解題。

 

管控流程體系

性能的有效長線管控，除了上面的資源監控平臺，還須要配套的流程體系及組織保障。因此在APP的生命週期每一個階段都創建了從測試分析到修復驗證的閉環管控。前置監控在迭代開發階段，早發現早解決。在集成階段監控每個改動，保證及時處理。線上經過實時監控和動態下發，實現快速修復。

 

4.總結與思考

 

決心大於方案

超級應用的性能問題每每關聯多方業務，須要多方團隊協做，因此自上而下對性能的重視程度和優化決心是決定成敗的關鍵，打通任督二脈，才能事半功倍，把優化方案順利落地。

 

攻城難，守城更難

業務與技術都在快速迭代，要想保證優化成果防止反彈，管控是必須的，而管控就會有束縛和效率影響，管控過程當中就不免會遇到各類各樣的阻力。因此一方面技術上，創建標準規則，配合提效工具和優化流程，儘可能避免影響業務開發。另外一方面，團隊須要具備共同認知，性能體驗與功能體驗同等重要，用戶對比心智很強，性能體驗每每與產品口碑直接掛鉤。

 

性能優化永遠在路上

目前，咱們不少優化策略以及數據參數仍是從實驗室調校而來。將來，咱們會進一步探索雲端一體、端智能等技術，作到更懂用戶，貼合業務和用戶特色，實現性能體驗的個性化提高。