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