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