# 技術(shù)視界# 【技術(shù)視界】欄目為開發(fā)者提供華為研發(fā)專家對于HarmonyOS關(guān)鍵技術(shù)的專業(yè)解讀，從不同角度、不同方面幫助開發(fā)者更好更快地掌握HarmonyOS相關(guān)開發(fā)知識。本期文章為大家?guī)淼氖侨A為性能調(diào)優(yōu)工具專家的分享，希望能為您的應(yīng)用性能優(yōu)化帶來啟發(fā)~ 作者：shizhengtao，華為性能調(diào)優(yōu)工具專家

應(yīng)用的性能優(yōu)化一直以來都是開發(fā)者所面臨的一大難題，在2023HDC大會上全新亮相的HarmonyOS NEXT開發(fā)者預(yù)覽版，其中鴻蒙開發(fā)套件DevEco Profiler，對應(yīng)用卡頓這一問題的定位解決又提供了哪些能力呢？本文帶你一探究竟。

一

RealtimeMonitor，高效發(fā)現(xiàn)卡頓問題

RealtimeMonitor實(shí)時監(jiān)測應(yīng)用運(yùn)行過程中的一系列性能指標(biāo)，并以可視化面板展示這些指標(biāo)。開發(fā)者使用十分簡單，只需在DevEcoProfiler工具界面的左上角選擇好您要觀測的應(yīng)用進(jìn)程，這一功能即會自動打開。圖一Realtime Monitor在RealtimeMonitor中，您可以看到如下指標(biāo)項(xiàng)：

①系統(tǒng)性能事件：借助HarmonyOS NEXT自帶的性能檢測能力，幫助您自動地發(fā)現(xiàn)一些與性能、穩(wěn)定性相關(guān)的運(yùn)行事件。

②系統(tǒng)異常事件：借助HarmonyOS NEXT自帶的異常檢測能力，幫助您自動地發(fā)現(xiàn)一些異常的運(yùn)行事件。

③前臺Ability：檢測應(yīng)用當(dāng)前在前臺顯示的UIAbility，當(dāng)發(fā)現(xiàn)異常指標(biāo)時，您能夠快速獲知是在哪個UIAbility運(yùn)行時產(chǎn)生的。

④CPU使用率：檢測應(yīng)用的CPU使用率和系統(tǒng)整體的CPU負(fù)載，持續(xù)過高的CPU占用往往會帶來能耗過高的問題，是需要重點(diǎn)關(guān)注的。

⑤內(nèi)存使用量：檢測應(yīng)用的內(nèi)存使用量和系統(tǒng)整體的內(nèi)存負(fù)載，如果出現(xiàn)應(yīng)用內(nèi)存周期性上漲的情況，很可能有內(nèi)存泄漏產(chǎn)生了，需要重點(diǎn)關(guān)注。

⑥設(shè)備FPS：檢測設(shè)備當(dāng)前的FPS幀率，當(dāng)應(yīng)用界面靜止而FPS很高時可能存在過度渲染問題，當(dāng)應(yīng)用界面變化大而FPS不高時則可能存在丟幀問題，也就是前面提到的流暢性問題。

⑦設(shè)備GPU利用率：檢測設(shè)備當(dāng)前的GPU利用率，當(dāng)FPS幀率不夠時，通過GPU利用率和CPU利用率指標(biāo)的對比，即可做一個初步的定界：瓶頸是在GPU側(cè)還是在CPU側(cè)。

⑧器件能耗：檢測應(yīng)用使用各個物理器件的耗電量和總耗電量，幫助您快速分析應(yīng)用當(dāng)前的耗能分布情況。

借助這些實(shí)時的性能指標(biāo)，您可以快速了解應(yīng)用進(jìn)程的運(yùn)行性能，這樣就能在應(yīng)用產(chǎn)生某些性能問題時快速的發(fā)現(xiàn)和定界。

二

場景化分析，直擊問題源碼行

在DevEco Profiler工具的設(shè)計(jì)之初，我們便確定了一條核心理念，就是要提供場景化的低門檻調(diào)優(yōu)工具，構(gòu)建Top-Down式的UX交互設(shè)計(jì)，引導(dǎo)開發(fā)者分析性能數(shù)據(jù)時能夠做到抽絲剝繭、層層遞進(jìn)，而不是一開始便直接陷入到數(shù)據(jù)海洋的細(xì)節(jié)之中。這在性能調(diào)優(yōu)領(lǐng)域是十分重要的，我們希望將每一類性能問題背后的故障模型，通過界面設(shè)計(jì)直觀地體現(xiàn)給開發(fā)者們。開發(fā)者們能夠在拿到性能數(shù)據(jù)的第一時間，便完成對問題的初步定界和判斷，然后有的放矢的去分析抓取到的數(shù)據(jù)，清晰的解決思路是解決性能問題的必備條件之一。除此之外還有極為重要的另一點(diǎn)則是，所有場景我們都希望能幫助開發(fā)者直接定位到問題代碼行，通過工具定位到瓶頸函數(shù)后，可以直接雙擊函數(shù)棧幀，就可以快速在DevEcoStudio的編輯器中打開相關(guān)源文件，開發(fā)者們可以馬上進(jìn)行分析優(yōu)化。

在8月份HDC大會亮相的DevEco Profiler中，除了已經(jīng)發(fā)布的用于函數(shù)熱點(diǎn)和內(nèi)存分析相關(guān)的基礎(chǔ)調(diào)優(yōu)模板之外，今年為各位開發(fā)者們帶來了真正體現(xiàn)場景化這一理念的兩大高級模板：Launch Insight和Frame Insight。

• Launch Insight：全面拆解應(yīng)用冷啟動過程，抓取不同階段的耗時數(shù)據(jù)，幫助開發(fā)者快速分析冷啟動過程的耗時瓶頸。

• Frame Insight：記錄每一幀的渲染數(shù)據(jù)，自動標(biāo)識其中的卡頓幀，并提供同時段的系統(tǒng)Trace信息和函數(shù)棧采樣數(shù)據(jù)，幫助開發(fā)者高效分析卡頓位置和原因。

接下來，讓我們一探Frame模板究竟，看看它到底是如何幫助開發(fā)者有的放矢、抽絲剝繭地分析丟幀問題的。

三

Frame Insight，高效定位卡頓問題

上一節(jié)我們提過，會將性能問題背后的故障模型直觀地體現(xiàn)給開發(fā)者，因此在介紹Frame模板之前，首先需要各位開發(fā)者們先簡單了解一下，在HarmonyOS NEXT中圖形渲染的流程是怎樣的，如果出現(xiàn)卡頓其可能的階段和原因是什么。

在HarmonyOS NEXT中，圖形系統(tǒng)采用了統(tǒng)一渲染的模式，遵循著一個典型的流水線模式，以60Hz刷新率為例，整個過程如下圖二所示，如果是90Hz，每個Vsync的周期就是11.1ms了。

圖二 60Hz刷新率渲染流程

在整個渲染流程中，首先是由應(yīng)用側(cè)響應(yīng)消費(fèi)者的屏幕點(diǎn)擊等輸入事件，由應(yīng)用側(cè)處理完成后再提交給Render Service，由Render Service協(xié)調(diào)GPU等資源處理后，在將最終的圖像統(tǒng)一送到屏幕上進(jìn)行顯示。聰明的讀者想必這個時候已經(jīng)可以由這個流程推導(dǎo)出相應(yīng)的故障模式了，就像圖三圖四所示。

圖三 應(yīng)用卡頓導(dǎo)致丟幀的故障模型

圖四 Render Service卡頓導(dǎo)致丟幀的故障模型

在整個處理流程中，應(yīng)用側(cè)和RenderService側(cè)都有可能出現(xiàn)卡頓導(dǎo)致最終用戶觀測到丟幀的可能，我們分別將這兩種情況命名為了AppDeadlineMissed和RenderDeadlineMissed。一般而言，前者可能是應(yīng)用邏輯處理代碼不夠高效導(dǎo)致的，后者可能是界面結(jié)構(gòu)過于復(fù)雜或者GPU負(fù)載過大等原因?qū)е碌?。這兩個故障模型通過我們的Frame模板都可以直觀地看到。補(bǔ)充好這些預(yù)備知識后，接下來，讓我們進(jìn)入正題。

首先是模板的選擇和錄制，這一步驟是很簡單的。開發(fā)者們只需要點(diǎn)幾下鼠標(biāo)，然后在錄制期間復(fù)現(xiàn)卡頓丟幀場景即可。整個過程如圖五所示，在錄制期間，DevEco Profiler會使用HarmonyOS NEXT中豐富的DFX工具，自動地為開發(fā)者們采集丟幀場景下所需的各類性能數(shù)據(jù)，錄制解析完成之后，就可以展開分析了。

圖五 Frame模板錄制解析

在錄制完成后，您可以觀測到一系列數(shù)據(jù)泳道，如圖六所示。

圖六 Frame模板數(shù)據(jù)泳道

①Frame泳道：直觀呈現(xiàn)丟幀故障模型對應(yīng)的性能數(shù)據(jù)，幫助開發(fā)者快速定位到出現(xiàn)卡頓丟幀的時段，并且能夠?qū)G幀原因做一個初步判斷。

②ArkTS Callstack泳道：抓取和呈現(xiàn)ArkTS的函數(shù)熱點(diǎn)，幫助開發(fā)者定位ArkTS側(cè)的耗時瓶頸。

③Native Callstack泳道：抓取和呈現(xiàn)Native C++的函數(shù)熱點(diǎn)，幫助開發(fā)者定位Native側(cè)的耗時瓶頸。

④CPU Core泳道：抓取和呈現(xiàn)各個CPU核心的運(yùn)行細(xì)節(jié)，幫助開發(fā)者定位線程優(yōu)先級、系統(tǒng)調(diào)度等帶來的性能問題以及線程實(shí)際運(yùn)行的細(xì)節(jié)。

⑤System Trace泳道：抓取和呈現(xiàn)各個進(jìn)程的system trace和user trace,幫助開發(fā)者了解查看系統(tǒng)的運(yùn)行細(xì)節(jié)，和某些核心任務(wù)的準(zhǔn)確運(yùn)行時間。

在分析丟幀問題時，首先可以聚焦展開第一條Frame泳道。在這條泳道中，我們抓取了圖形渲染過程的一些關(guān)鍵節(jié)點(diǎn)信息，并將其可視化了出來，如圖七所示。

圖七 Frame泳道

①應(yīng)用幀處理：為您顯示了應(yīng)用側(cè)每一幀的處理耗時，方塊的長度即為具體的耗時，綠色的即為在預(yù)定周期內(nèi)完成的幀，紅色的則是沒有在預(yù)定周期內(nèi)完成的幀

②RenderService幀處理：為您顯示了Render Service側(cè)每一幀的處理耗時，條塊顯示邏輯同應(yīng)用側(cè)

③提交關(guān)系：通過連線的方式，將應(yīng)用側(cè)提交的幀和Render Service側(cè)接收處理的幀關(guān)聯(lián)起來，并且標(biāo)有相應(yīng)標(biāo)號，您可以立刻觀測到這個應(yīng)用到系統(tǒng)的渲染流程

④期望開始和結(jié)束處理時間：通過兩根豎線標(biāo)記了被選擇幀，期望開始處理和期望完成處理的時間，一旦超時，您可以借助這兩根豎線，去觀測同一時間的其他性能數(shù)據(jù)

⑤詳細(xì)數(shù)據(jù)：為您提供被選擇的幀的詳細(xì)數(shù)據(jù)，通過Corresponding Slice或Preceding Flows的跳轉(zhuǎn)按鈕，您可以快速找到對應(yīng)的詳細(xì)system trace做進(jìn)一步分析

通過這一條泳道，開發(fā)者們可以快速發(fā)現(xiàn)丟幀的位置，并完成初步的定界：如果是應(yīng)用幀處理有紅色出現(xiàn)，那需要進(jìn)一步審視在UI線程中的處理邏輯，是否過于復(fù)雜或低效，又或者是被別的什么任務(wù)搶占了資源；如果是RenderService幀處理有紅色出現(xiàn)，那需要審視是否是界面布局過于復(fù)雜。后者可以借助DevEco Studio內(nèi)的ArkUIInspector等工具進(jìn)一步分析，本文不做過多闡述。針對前一種現(xiàn)象我們繼續(xù)分析。

在找到了處理超時的幀之后，開發(fā)者們可以有兩種選擇，一種是分析system trace，另一種則是分析采樣得到的函數(shù)熱點(diǎn)。前一種方式需要對整個系統(tǒng)和關(guān)鍵的trace點(diǎn)有深入的了解，對于現(xiàn)階段的開發(fā)者們可能還有些困難，所以我們還是建議開發(fā)者們直接分析函數(shù)熱點(diǎn)。分析的方式很簡單，找到ArkTS Callstack泳道，框選一下即可。這里有一個小技巧，開發(fā)者們可以點(diǎn)擊泳道信息區(qū)的收藏按鈕，將應(yīng)用幀處理的泳道收藏置頂，如圖八所示，可以有效防止上下文信息丟失。

圖八 置頂收藏關(guān)鍵泳道

將ArkTS Callstack泳道中紅色幀的時段框選起來之后，就可以在下方詳情面板中查看到這段時間的函數(shù)熱點(diǎn)了。我們提供了兩種函數(shù)熱點(diǎn)展現(xiàn)形式供開發(fā)者選擇，一種是Top-Down形式的一個樹狀列表，如圖九所示；另一種則是許多開發(fā)者可能更耳熟能詳?shù)幕鹧鎴D，如圖十所示。開發(fā)者們可以選擇自己習(xí)慣的方式去查看。一般來說，如果所選的時間段里，函數(shù)棧比較復(fù)雜的話，用火焰圖找熱點(diǎn)會更高效。在這兩種形式之外，我們還提供了一個自動查找瓶頸路徑的能力，也就是顯示在圖九和十右側(cè)的部分。當(dāng)您在左側(cè)Top-Down或火焰圖中點(diǎn)擊某個具體的函數(shù)棧幀結(jié)點(diǎn)后，我們會為您計(jì)算找到從這個節(jié)點(diǎn)往下，最耗時的那條調(diào)用路徑，當(dāng)您點(diǎn)擊這條調(diào)用路徑上的函數(shù)棧幀時，左側(cè)的圖表也會自動展開或聚焦到對應(yīng)結(jié)點(diǎn)上，為您提升瓶頸定位效率。

圖九 函數(shù)熱點(diǎn)Top-Down視圖

圖十 函數(shù)熱點(diǎn)火焰圖

當(dāng)鎖定到某個熱點(diǎn)函數(shù)之后，只需要雙擊函數(shù)結(jié)點(diǎn)，Profiler工具就會為您自動打開對應(yīng)的源文件，并Focus到相應(yīng)代碼行。當(dāng)然了，這里有一個前提，這個源文件須是屬于當(dāng)前工程，并且是在DevEcoStudio內(nèi)完成編譯的。

四

驗(yàn)證和迭代優(yōu)化

通過前述步驟，開發(fā)者們應(yīng)當(dāng)已經(jīng)能夠定位到瓶頸代碼了，但是任務(wù)到此還遠(yuǎn)未結(jié)束。您還需要在優(yōu)化完成后，再次使用工具的前幾項(xiàng)能力來驗(yàn)證，一般而言性能優(yōu)化并不是一件一蹴而就的事，需要循序漸進(jìn)逐步改進(jìn)。這需要經(jīng)驗(yàn)，但更需要耐心，每一次卡頓都很可能是多個子問題共同疊加導(dǎo)致的。這也是性能優(yōu)化這個任務(wù)，往往需要團(tuán)隊(duì)內(nèi)的大牛來進(jìn)行的原因之一。

當(dāng)然了，這其實(shí)也給我們這些程序員指明了一條升職加薪之路，學(xué)會調(diào)優(yōu)，去解決性能問題這種難題，解的多了，自然就成為團(tuán)隊(duì)技術(shù)骨干了，也希望這篇文章和我們的調(diào)優(yōu)工具DevEcoProfiler能為各位開發(fā)者的晉升之路帶來一些幫助，感謝您的閱讀。