HarmonyOS NEXT帶來的DevEco Profiler助您輕松分析應(yīng)用性能問題

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

一、Realtime Monitor，高效發(fā)現(xiàn)卡頓問題

Realtime Monitor實時監(jiān)測應(yīng)用運行過程中的一系列性能指標，并以可視化面板展示這些指標。開發(fā)者使用十分簡單，只需在DevEco Profiler工具界面的左上角選擇好您要觀測的應(yīng)用進程，這一功能即會自動打開。

圖一：Realtime Monitor

在Realtime Monitor中，您可以看到如下指標項：

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

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

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

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

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

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

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

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

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

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

在DevEco Profiler工具的設(shè)計之初，我們便確定了一條核心理念，就是要提供場景化的低門檻調(diào)優(yōu)工具，構(gòu)建Top-Down式的UX交互設(shè)計，引導(dǎo)開發(fā)者分析性能數(shù)據(jù)時能夠做到抽絲剝繭、層層遞進，而不是一開始便直接陷入到數(shù)據(jù)海洋的細節(jié)之中。這在性能調(diào)優(yōu)領(lǐng)域是十分重要的，我們希望將每一類性能問題背后的故障模型，通過界面設(shè)計直觀地體現(xiàn)給開發(fā)者們。開發(fā)者們能夠在拿到性能數(shù)據(jù)的第一時間，便完成對問題的初步定界和判斷，然后有的放矢的去分析抓取到的數(shù)據(jù)，清晰的解決思路是解決性能問題的必備條件之一。除此之外還有極為重要的另一點則是，所有場景我們都希望能幫助開發(fā)者直接定位到問題代碼行，通過工具定位到瓶頸函數(shù)后，可以直接雙擊函數(shù)棧幀，就可以快速在DevEco Studio的編輯器中打開相關(guān)源文件，開發(fā)者們可以馬上進行分析優(yōu)化。在8月份HDC大會亮相的DevEco Profiler中，除了已經(jīng)發(fā)布的用于函數(shù)熱點和內(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ù)，自動標識其中的卡頓幀，并提供同時段的系統(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)消費者的屏幕點擊等輸入事件，由應(yīng)用側(cè)處理完成后再提交給Render Service，由Render Service協(xié)調(diào)GPU等資源處理后，在將最終的圖像統(tǒng)一送到屏幕上進行顯示。聰明的讀者想必這個時候已經(jīng)可以由這個流程推導(dǎo)出相應(yīng)的故障模式了，就像圖三圖四所示。

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

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

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

首先是模板的選擇和錄制，這一步驟是很簡單的。開發(fā)者們只需要點幾下鼠標，然后在錄制期間復(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ù)熱點，幫助開發(fā)者定位ArkTS側(cè)的耗時瓶頸。

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

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

⑤ System Trace泳道：抓取和呈現(xiàn)各個進程的system trace和user trace，幫助開發(fā)者了解查看系統(tǒng)的運行細節(jié)，和某些核心任務(wù)的準確運行時間。在分析丟幀問題時，首先可以聚焦展開第一條Frame泳道。在這條泳道中，我們抓取了圖形渲染過程的一些關(guān)鍵節(jié)點信息，并將其可視化了出來，如圖七所示。

圖七：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)起來，并且標有相應(yīng)標號，您可以立刻觀測到這個應(yīng)用到系統(tǒng)的渲染流程

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

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

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

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

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

圖九：函數(shù)熱點Top-Down視圖

圖十：函數(shù)熱點火焰圖

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

四、驗證和迭代優(yōu)化

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

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