作者：楊夕凱、吳文揚
高德地圖從19年開始對全鏈路效能體驗進行了持續三年的最佳化，最終整體核心鏈路上實現了打對摺最佳化，使用者體驗上大幅提升。過程中，對效能最佳化的一些思考和實踐經驗，本文進行了總結，希望對大家有些助益。
最佳化前後效果對比（以最佳化前的耗時為基線100%）
思路
整體思路分為明確性能卡點，倒序專項解題和正序長線管控三個部分：
- 明確性能卡點：找到最佳化點才能有的放矢，科學的評測標準和明確的最佳化點對於最佳化至關重要，科學的評測標準需要能夠合理評估效能體驗的好壞，並更貼近使用者的真實感受，而目標則需要可量化，這樣才能夠保住在專項過程中快速對焦高效執行，避免走彎路；
- 倒序專項解題：效能問題不是單一業務問題，往往涉及多個產研測團隊協作，我們從問題出發快速倒序以專項形式凝聚多團隊資源，確定目標，快速攻堅拿結果，增強團隊信心；
- 正序長線管控：最佳化是從“果”倒退“因”的過程，已經發生問題了再去解決，是一種倒序解題的思路。那麼如何讓問題從“因”的源頭上截住，或者說讓已經最佳化的效果不發生倒退，那麼我們的思路三是：長線持續的正序管控，避免原有業務的持續惡化，同時鞏固專項的最佳化成果。
接下來，本位將針對這三個部分，逐一解析。
明確性能卡點
制定標準
首屏載入速度的快慢極大影響著使用者體驗，所以首屏耗時作為我們頁面耗時的統計標準。隨著手機硬體的不斷升級，很多高階裝置硬體效能好掩蓋了程式效能問題，因此我們會對不同機型等級裝置進行最佳化，最大程度的覆蓋到線上使用者。
1 統計標準
確定了首屏顯示耗時是統計標準，下面是如何確定首屏顯示耗時的幾個維度：
- 業務角度：業務形態各異，不同頁面的首屏定義一定不同；
- 產品角度：定義首屏圍繞著功能使用量進行，高頻功能優先；
- 研發角度：透過業務流程上的日誌埋點來錨定首屏的起終點；
- 產研測拉通標準：建立統一的產研測溝通語言，那就是量化資料。
2 機型標準
- 機型等級：根據裝置評分將裝置分為高中低三種等級；
- 選定機型：選定不同等級代表機型的準則，我們採取的是依據線上使用者裝置的佔比，儘可能的覆蓋比較多的使用者，儘可能選取有代表性的廠商裝置，當然也需要綜合考慮現有測試實驗室可用裝置情況，畢竟採購不一定很及時和避免不必要的浪費。
確定最佳化項
高德地圖長期以來的歷史累計，導致每個場景的最佳化，都面臨著複雜的業務程式碼，甚至還存在業務盲區。這就對快速分析歷史大量業務，精確定位耗時點帶來極大的挑戰。如果靠人工梳理分析，人力投入和時長都不現實。這就需要從工具和方法論上找到加速方案。
1 自上而下明確最佳化點
- 手機裝置維度分析：
無限的業務場景透過移動裝置執行在有限的效能資源上，資源分配勢必捉襟見肘。所以我們需要根據裝置的不同來分析耗時問題。比如在比較差的手機上出現的耗時問題，可能在高階的手機上並不是問題。最佳化點也不同，需要個性化策略來進行針對性最佳化。例如：低端機的複雜互動動畫就是一個耗時點，比如搜尋頁面關閉一些動畫，效能上帶來不小的收益，同時也不損害使用者體驗，在高階機上這個耗時點就可以不考慮。
- 業務平行維度分析：
業務點特別多，那麼為什麼我們要選擇出行場景、搜尋場景等去分析耗時呢？這就需要拉通產品和BI，用資料說話。透過分析線上使用者行為，大部分使用者選擇了點選搜尋框進入搜尋首頁，而線上使用者反饋也是進入搜尋卡頓耗時等，相比其他功能，搜尋首頁的及時性和重要性不言而喻，於是根據線上資料進行業務分級，該場景排在首位，效能資源應該向這裡傾斜，需要首先分析這裡的耗時點。
- 業務內部維度分析：
首先對業務場景本身進行全鏈路梳理，找出其中的關鍵時間點，然後透過場景日誌工具進行埋點並上傳至服務，收集線上使用者真正的首屏時間資料，為量化目標提供有效依據。其中兩兩關鍵點之間的時間戳差值即為階段耗時，能輔助分析業務耗時問題。圍繞著業務分析的過程我們還沉澱了很多分析工具來輔助分析。
2 最小集，加法，減法
最小集是一個探底的過程，在保證首屏產品形態不變形的情況下做出最小可執行，去掉其他所有跟首屏無關項，這就是減法。我們可以理解這個最小集是在不改變現有架構的情況下，我們最優的最佳化效果。如果最小集的極限資料達標，接下來就要在此基礎上把必要的相關依賴項逐個加回來，保障產品功能完善，其他沒必要的依賴性可以最佳化、或者去掉、或者延後等，這就是加法。當然如果這個最小集的極限資料都不能達標，那我們就需要從其他維度去尋找最佳化點了，一般能夠從網路耗時和架構合理性兩個方面找到突破點。
倒序專項解題
效能問題不是單一業務問題，往往涉及多個產研測團隊協作。所以我們的思路是：
從問題出發快速倒序以專項形式凝聚多團隊資源，確定目標，快速攻堅拿結果，增強團隊信心
專項攻堅
專項攻堅，也是個邊打邊建，邊打邊沉澱的過程。排查效能問題的手段最初是比較離散的。往往是遇到一個解決一個，下次不同的場景需要重複工作再來一遍，那麼我們的思路是：
沉澱可複用方案，解題思想、通用框架和工具平臺，針對“最佳化手段”本身的效率進行最佳化，讓成本逐漸降低
啟動專項是第一個效能專題專案，完成了一個場景最佳化，耗費30人，3個版本迭代。之所以人力比較多，是因為“第一次”面臨的問題非常多，指標要分析定義標準、埋點工具要新建、最佳化過程沒經驗、管控手段要新建。
搜尋專項完成了一個場景最佳化，耗費8人，人力情況就好了很多，版本變成2版。當時已經有啟動期間已經建設好的埋點工具，有了一定的最佳化經驗，少走了很多彎路。
核心鏈路專項完成了六個場景，耗費24人，一版搞定。最佳化的過程有條不紊，人力少、場景多、時間短。這得益於最佳化效率的提升，成本逐漸降低。在不斷最佳化的過程中積累了相對成熟的分析工具、最佳化工具、管控工具。
最佳化方案
效能最佳化是一個體系化問題，我們在最佳化方案上分為三層，業務、引擎和基礎能力，分別自上而下明確最佳化點。上層業務進行自適應資源排程，中間引擎提供加速能力，底層能力提供高效能元件。
1 業務自適應資源排程
業務層最佳化主要透過業務編排排程來實現效能最優狀態，但業務各自排程最佳化工作重複且繁瑣。為了降低這部分成本，我們開發了一套資源排程框架，業務接入後，排程工作由框架完成。排程框架在應用執行過程中，感知採集執行環境，然後對不同環境狀態進行不同的排程決策，生成相應的效能最佳化策略，最終根據最佳化策略執行對應最佳化功能。與此同時，監測排程上下文以及排程策略執行效果，並將其反饋給排程決策系統，從而為進一步的決策調優提供資訊輸入。這樣，可以做到在不同的執行環境下都能達到可預期的極致效能體驗。
一、環境感知
感知環境分為硬體裝置、業務場景、使用者行為和系統狀態四個維度：
- 硬體裝置上，一方面透過集團實驗室對已知裝置進行評測跑分，以此確定高中低端機型，另一方面在使用者裝置上本地對硬體進行實時算力評估；
- 業務場景上，將業務分為前臺展示、後臺執行、互動操作等幾類，一般情況下前臺正在進行互動操作的業務場景優先順序最高，後臺資料預處理業務場景優先順序最低；對於同類別業務場景，根據業務UV、交易量、資源消耗等維度進行PK，確定細分優先順序；
- 使用者行為上，結合服務使用者畫像和本地實時推算，確定使用者功能偏好和操作習慣，為下一步針對使用者的精準最佳化決策做準備；
- 系統狀態上，一方面透過系統提供介面，獲取諸如記憶體警告、溫度警告及省電模式等來獲取系統極端狀態，另一方面透過對記憶體、執行緒、CPU和電量進行監控，來實時確定系統性能資源情況。
二、排程決策
感知到環境狀態之後，排程系統將結合各種狀態與排程規則，進行業務以及資源調配決策。
- 降級規則：在低端裝置上或者系統資源緊張告警（如記憶體、溫度告警）時，關閉高耗能功能或者低優先順序功能
- 避讓規則：高優先順序功能執行時，低優先順序功能進行避讓，如使用者點選搜尋框時到搜尋結果完全展示的時間段內，後臺低優任務進行暫停避讓，保證使用者互動體驗；
- 預處理規則：依據使用者操作及習慣進行預處理，如某使用者通常在啟動3s後，點選搜尋，則在3s之前對該使用者搜尋結果進行預載入，從而在使用者點選時呈現極致的互動體驗效果
- 擁塞控制規則：在裝置資源緊張時，主動降低資源申請量，如CPU繁忙時，主動降低執行緒併發量。這樣在高優任務到來時，避免出現資源緊缺申請不到資源效能體驗問題
三、策略執行
策略執行分為任務執行和硬體調優：其中任務執行，主要是透過記憶體快取、資料庫、執行緒池和網路庫對相應任務的進行執行控制，來間接實現對各類資源的排程控制；而硬體調優，則是透過與系統廠商合作，直接對硬體資源進行控制；如CPU密集的高優業務開始執行時，將提高CPU頻率，並將其執行執行緒繫結到大核上，避免執行緒來回切換損耗效能，最大化地排程系統資源來提升效能
四、效果監測
在資源排程過程中對各個模組進行監測，並將環境狀態、排程策略、執行記錄、業務效果、資源消耗等情況反饋給排程系統，排程系統則以此來評判本次排程策略的優劣，以做進一步的調優
2 引擎加速能力
一、地圖引擎
地圖引擎是地圖應用獨特的部分。這塊主要從繪製最佳化策略入手，主要包括分批分塊渲染、幀率排程、訊息排程等。
二、跨端引擎
跨端引擎則需要給業務提供支撐，它也是全場景通用的方案，比客戶端最佳化更有施展空間，與業務直接接觸離業務夠近。所以跨端引擎的最佳化策略就是降低業務程式碼的效能成本。主要方案有：
- 執行緒提優先順序
- 上下文預載入
- 業務框架複用
- require引用複用
這裡簡單介紹下上下文預載入，為了不影響現有業務的執行狀態，我們設計了一種閒時分段預載入的方案，能夠在頁面未進入之前，將頁面需要計算的耗時、匯入檔案的耗時等提前執行。
- 閒時：當業務執行緒空閒時再做預載入，避免影響其他頁面
- 分段：每次預載入的內容粒度小於16ms，避免預載入任務阻塞當前執行緒
- 預載入：將目標頁面的計算量提前，加速進入目標頁面
三、H5容器
1、離線包加速
離線包加速，主要解決複雜 H5 頁面的載入速度問題：資原始檔數量較多，下載耗時較長，導致頁面載入緩慢，通常透過增加loading來減少介面載入等待問題，從而導致使用者等待耗時長，最終帶來的是轉換率流失。在此大背景下，結合高德已有的一些平臺能力，搭建了離線包加速能力。整個鏈路包含：
- 離線包構建：透過前端腳手架，提速業務開發效率，動態指定離線包資源配置；
- 離線包釋出：對接已有的服務釋出能力，搭建前端視覺化釋出平臺，提供灰度控制、包更新、資料統計等能力；
- 端管理：包下載、管理、生效，控制下載及更新時機——對於高頻頁面進行預下載請求，開啟頁面時實現“秒開”；
- 資源生效：容器內資源載入攔截，對接離線資源管理模組，命中快取則直接生效，未命中走正常網路請求進行下載。
2、容器預建立
容器的預建立和預熱，對於H5頁面的載入速度將會有很大的提升，WebView的例項建立成本本身是相對較高的，在APP啟動後合適的時機進行預建立並快取複用，可以解決首次開啟和二次載入的速度。AMap本身有啟動任務編排及閒時任務排程，在此基礎上可在對應WebView模組內進行預建立操作。對於預建立WebView Context切換問題，由於AMap的頁面棧實際為自定義實現，僅有一個獨立的Activity，因此具有天然的良好相容性。對於預建立，本身是空間換時間的一種做法，對於不同效能裝置的差異化配置，需要重點打磨——此外，也可以結合端智慧的特徵行為，類似使用者頁面跳轉的行為習慣及頻次等，來動態決策是否需要進行預建立。
3 架構高效能元件
一、執行緒池
執行緒池支援業務進行任務優先順序編排、執行緒總數控制、執行緒避讓等排程策略，使裝置資源得到充分合理的利用。
執行緒佇列管理模組，其提供5個優先順序佇列：
- 高優佇列：用於處理 UI 相關的任務，能夠快速返回執行結果，如啟動階段高優任務等；
- 次高優佇列：用於執行需要立即返回的任務，如業務page檔案載入等；
- 普通（低優）佇列：主要用於不需要立即返回的任務，如網路請求；
- 後臺（最低優）佇列：用於處理一些使用者不會感知的任務，如埋點、耗時的IO操作等；
- 主執行緒閒時佇列：用於處理不需要立即執行，但業務又不支援按需執行的任務，只有在主執行緒檢測處於空閒狀態時才會執行
二、網路庫
網路請求作為場景中耗時大頭，其效能表現幾乎決定了場景首屏耗時表現，我們針對網路請求的各個環節，做了鏈路監控與極致最佳化，重點包含：請求精細化排程、併發預處理、DNS預載入、連線複用等。
請求鏈路示意圖：
- 排隊：對請求進行精細化排程；對執行緒資源分級，高優請求有自己獨立的資源，同時資源可以高佔低，但低不能佔高，實現高優請求 0 排隊。同時限制低優請求併發量，避免併發過多導致底層頻寬搶佔；
- 預處理：主要包含公參、簽名、加密等一系列耗時操作，將預處理操作從原來的序列轉為並行，壓低預處理耗時；
- DNS解析：常用域名做白名單，在啟動時即會進行常用域名DNS預解析，真正使用時，實現解析0耗時；
- 建連：透過使用h2長連線、預建連等策略，實現建連幾乎0耗時；
- 請求上/下行：根據body大小，智慧判斷是否需要壓縮，降低body大小，減少傳輸耗時；
- 解析回撥：針對響應較複雜的場景（如規劃），使用更高效的資料協議格式（如pb），降低資料大小&解析時間。
正序長線管控
最佳化是從“果”倒退“因”的過程，已經發生問題了再去解決，是一種倒序解題的思路。那麼如何讓問題從“因”的源頭上截住，或者說讓已經最佳化的效果不發生倒退，那麼我們的思路三是：
長線持續的正序管控，避免原有業務的持續惡化，同時鞏固專項的最佳化成果。
高德地圖客戶端橫向業務上包含出行、搜尋、打車等業務線，縱向架構上包含業務層、平臺適配層、跨端引擎層和地圖引擎層，跨多個語言棧，效能問題具有跟進流程長和排查鏈路長的特點。因此管控思路集中在標準、流程、自動化平臺和工具的建設上。
標準
在經過全面的專項治理後，效能管控的目標和要求是避免持續惡化的狀態，由於測試波動的存在及熱更、快速迭代、動態化外掛的頻繁釋出，需要管控的出口非常多，如果存在管控遺漏區，效能就會不可避免的持續惡化。因此管控標準確定為以固定基線為基準，以環比數值為量化標準，把所有變化因素都包含到管控中，有效防止疊加惡化。
流程
高德客戶端主版流程主要分為三個大階段：需求分析和設計、業務獨立迭代開發、整合測試，整合測試階段本身有大量的業務BUG，所以留給效能問題發現和解決的時間非常緊張，為了解決這些問題，管控流程需要利用好主版流程的每一個階段，分階段消滅效能問題。
- 需求分析和方案設計計算，提前識別問題；
- 迭代開發階段，提前發現和解決問題，降低效能問題暴露晚導致來不及修復，影響線上使用者體驗的風險；
- 整合測試階段每天彙總資料大盤，及時發現問題，依託平臺和工具快速排查，加速問題流轉；
- 灰度和釋出階段關注線上資料大盤，建立報警機制，及時發現問題，透過使用者日誌排查線上問題。
平臺
依託泰坦持續整合平臺和ATap自動化測試平臺，打造連通開發，構建，效能測試，問題跟進、排查、流轉、解決完整鏈路的工具鏈，提高問題發現和解決的效率。
- 泰坦持續整合平臺
-- 定時構建，支援定位出包任務，構建型別支援效能包
-- 自動化測試觸發，支援打包觸發和定時觸發兩種觸發方式
-- 整合卡口及決策，整合申請展示效能測試結果，整合決策審批流程
- ATap自動化測試平臺
-- 效能大盤，彙總效能資料，快速發現問題
-- 埋點詳情，整合快速排查工具，加速排查
-- 問題跟進，結合Aone，監控問題解決流程，加速流轉
總結
目前為止，高德核心鏈路的效能體驗最佳化效果得到了較大的提升。從最初的拿到最佳化結果，到後來的最佳化效率提升，最佳化成本降低。整體的最佳化程序總結下來：
- 戰術上，採用“專項”+“技術沉澱”+“長線管控”的方式，能夠保障效能體驗問題得到良性解決。
- 戰略上，過去我們靠“人”解決問題，現在我們靠“人”、“架構”和“工具”解決問題。未來是否能夠“工具”自己解決問題或者避免出現問題呢？隨著“技術沉澱”積累的工具和“長線管控”建設的平臺不斷增加，相信量變引起質變只是時間問題。
關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！
