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 H5、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.總結與思考
決心大於方案
超級應用的性能問題往往關聯多方業務，需要多方團隊協作，所以自上而下對性能的重視程度和優化決心是決定成敗的關鍵，打通任督二脈，才能事半功倍，把優化方案順利落地。
攻城難，守城更難
業務與技術都在快速迭代，要想保證優化成果防止反彈，管控是必須的，而管控就會有束縛和效率影響，管控過程中就難免會遇到各種各樣的阻力。所以一方面技術上，建立標準規則，配合提效工具和優化流程，儘量避免影響業務開發。另一方面，團隊需要具有共同認知，性能體驗與功能體驗同等重要，用戶對比心智很強，性能體驗往往與產品口碑直接掛鉤。
性能優化永遠在路上
目前，我們很多優化策略以及數據參數還是從實驗室調校而來。未來，我們會進一步探索雲端一體、端智能等技術，做到更懂用戶，貼合業務和用戶特點，實現性能體驗的個性化提升。
