鴻蒙應(yīng)用開發(fā)過程中，可能由于種種原因?qū)е聭?yīng)用內(nèi)存未被正的使用或者歸還至操作系統(tǒng)，從而引發(fā)內(nèi)存異常占用、內(nèi)存泄漏等問題，最終導(dǎo)致應(yīng)用卡頓甚至崩潰，嚴重影響用戶體驗。

DevEco Profiler是集成在DevEco Studio中的一款原生鴻蒙應(yīng)用性能優(yōu)化工具，能夠輔助開發(fā)者高效完成鴻蒙應(yīng)用的性能問題定位與優(yōu)化。在集成開發(fā)環(huán)境DevEcoStudio中可以以如下方式打開DevEco Profiler：

在DevEco Studio頂部菜單欄中選擇“View-> Tool Windows -> Profiler”。

在DevEco Studio底部工具欄中單擊“Profiler”。

按“Double Shift”或者“Ctrl+Shift+A”打開搜索功能，搜索“Profiler”。

DevEco Profiler中提供了針對鴻蒙應(yīng)用內(nèi)存問題的場景化分析模板SnapshotInsight與Allocation Insight，可以用于分析ArkTS以及Native內(nèi)存，幫助開發(fā)者高效定位解決內(nèi)存問題。下面將從識別問題、定界定位、優(yōu)化驗證三個方面來對DevEcoProfiler定位內(nèi)存問題的方法進行介紹。

識別內(nèi)存問題

1.1 監(jiān)控應(yīng)用內(nèi)存

當(dāng)應(yīng)用的某項功能開發(fā)完成時，可以使用DevEco Profiler的實時監(jiān)控功能對應(yīng)用的各項資源進行監(jiān)控，其中就包括應(yīng)用內(nèi)存資源。詳細使用方法見性能問題定界。

性能問題定界：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V13/realtime-monitor-V13?catalogVersion=V13

實時監(jiān)控界面所展示的是應(yīng)用在運行過程中實際所使用的物理內(nèi)存（ProportionalSet Size, PSS）、其他進程的物理內(nèi)存占用以及操作系統(tǒng)的空閑內(nèi)存，泳道的藍色部分展示了當(dāng)前進程的物理內(nèi)存占用情況及趨勢，左側(cè)餅圖則展示了當(dāng)前時刻的瞬時內(nèi)存使用數(shù)據(jù)。

此時，我們可以正常地操作應(yīng)用，觀察在當(dāng)前功能運行過程中的應(yīng)用內(nèi)存變化情況，初步判斷是否存在內(nèi)存問題。當(dāng)發(fā)現(xiàn)在一段時間內(nèi)應(yīng)用內(nèi)存沒有明顯增加或者在內(nèi)存上漲后又逐漸回落至正常水平，則基本可以排除應(yīng)用存在內(nèi)存問題；反之，如果應(yīng)用內(nèi)存占用明顯與預(yù)期值不符合、在一段時間內(nèi)不斷上漲且無回落或者內(nèi)存占用明顯增長超出預(yù)期，那么則可初步判斷應(yīng)用可能存在內(nèi)存問題，需要進一步分析。

1.2 初步定界內(nèi)存問題

當(dāng)從實時監(jiān)控頁面初步判斷應(yīng)用可能存在內(nèi)存問題的時候，進一步地可以使用AllocationInsight或Snapshot Insight的Memory泳道來抓取應(yīng)用內(nèi)存在問題場景下的詳細數(shù)據(jù)以及變化趨勢，初步定界問題出現(xiàn)的位置（NativeHeap/ArkTS Heap/dev段等）。

在當(dāng)前步驟下，錄制內(nèi)存數(shù)據(jù)時需要將Allocation Insight或SnapshotInsight中的其余泳道去除勾選，僅錄制Memory泳道的數(shù)據(jù)（注：因為其余泳道會開啟對內(nèi)存分配、內(nèi)存對象等數(shù)據(jù)的抓取，這些功能會帶來額外的開銷，可能會對我們初步定界問題產(chǎn)生噪音，影響分析，故先排除錄制）。

在Memory泳道的錄制過程中，不斷操作應(yīng)用在問題場景的功能，將問題放大，便于快速定界問題點，參考錄制過程中的應(yīng)用內(nèi)存占用曲線，當(dāng)曲線的上漲幅度達到一定大小時即可結(jié)束錄制。

錄制完成后，可以展開Memory泳道，查看應(yīng)用內(nèi)存分段的使用情況，也可以點擊泳道上的options下拉框，自行選擇想要關(guān)注變化情況的內(nèi)存類型。

同時，可以選中Memory泳道或其任一子泳道（直接選中泳道時詳情區(qū)域會展示完整的泳道數(shù)據(jù)）來查看在每個采樣點的詳細應(yīng)用內(nèi)存占用數(shù)據(jù)（注：詳情區(qū)域數(shù)據(jù)采用PSS的維度衡量，數(shù)據(jù)近似于使用`hidumper --mem $pid`的第一列PSS值）。當(dāng)鼠標左鍵單擊選中表格中某一行的數(shù)據(jù)時，對應(yīng)的泳道上將展示出當(dāng)前的時間刻度線，方便快速定位內(nèi)存變化的時間位置。

通過查看Memory的子泳道內(nèi)存分類以及詳情區(qū)域的內(nèi)存詳細占用，我們能夠大致定界出有哪些位置的內(nèi)存可能存在問題。例如上圖中從Memory的子泳道數(shù)據(jù)圖中可以看到，F(xiàn)ilePageOther/Native Heap/ArkTS Heap均有較大的增長，因而可以以這三個方面的內(nèi)存使用作為切入點，來進一步分析問題的根因。

定位內(nèi)存問題

從1.2節(jié)中的分析可知，當(dāng)前應(yīng)用內(nèi)存的增長主要集中在FilePage Other/NativeHeap/ArkTS Heap這三個部分，那么需要使用進一步的分析方法對這三個方面的內(nèi)存進行分析，定位內(nèi)存上漲的根因。

在分析鴻蒙應(yīng)用的內(nèi)存問題時，可以將鴻蒙應(yīng)用的內(nèi)存大體分為兩部分，方舟虛擬機內(nèi)存和Native內(nèi)存：

1. 方舟虛擬機內(nèi)存：由方舟虛擬機管控的應(yīng)用內(nèi)存，同其他的虛擬機內(nèi)存（例如Java）管理策略相似，開發(fā)者可以使用并操控的內(nèi)存基本集中于虛擬機堆上，在方舟虛擬機上被稱作ArkTSHeap，這部分內(nèi)存受到方舟虛擬機的管控。

2. Native內(nèi)存：這部分內(nèi)存主要是應(yīng)用使用到的一些涉及Native的API所申請的內(nèi)存以及開發(fā)者自己的Native代碼所申請使用的堆內(nèi)存（通常是C/C++），這部分內(nèi)存需要開發(fā)者自己去管理申請和釋放。

因為兩種內(nèi)存的使用方式和管理方式不盡相同，因此在對這兩類內(nèi)存的分析過程中所使用的方法也有比較大的區(qū)別，下面將從這兩個方面分別介紹分析方法。

2.1 ArkTS內(nèi)存問題

2.1.1 ArkTS內(nèi)存管理

首先針對ArkTS Heap，由于該部分堆內(nèi)存受到方舟虛擬機的管理，可以對堆內(nèi)存進行垃圾回收（GarbageCollect，GC）和拍攝快照（HeapSnapshot或HeapDump，簡稱dump）以反映出瞬時的全量堆內(nèi)存使用及分布情況，因此這部分內(nèi)存的問題分析手段主要是對堆dump進行引用關(guān)系分析，分析泄漏對象無法被GC回收的原因。

不同于引用計數(shù)算法，方舟虛擬機采用可達性分析的機制來管理對象是否可被垃圾收集器回收，因此針對方舟虛擬機內(nèi)存的分析方法主要集中于對象的引用分析，即分析哪些對象引用關(guān)系是錯誤的或者異常的，從而導(dǎo)致了泄漏對象被長時間持有無法被GC，最終通過解除強引用關(guān)系的手段來解決內(nèi)存泄露問題。如下圖1所示，藍色的對象節(jié)點表示在內(nèi)存引用分析中該對象GCRoot引用可達，其余對象GC Root引用不可達，引用不可達的對象在GC中可以被虛擬機回收。

圖1 對象可達性分析

2.1.2 ArkTSHeap分析

針對虛擬機的內(nèi)存問題分析通常都集中在對dump的對象分布及引用關(guān)系的分析上，方舟虛擬機也不例外，這里在DevEcoProfiler上提供了Snapshot Insight來對方舟虛擬機的堆內(nèi)存進行分析。

在使用Snapshot分析時，通常會使用三快照技術(shù)（Three Snapshot Technique），通過內(nèi)存快照的對比視圖將某兩次快照之間分配且仍然駐留的內(nèi)存篩選出來，這些對象中的一部分就可能是導(dǎo)致內(nèi)存泄漏的對象。通用的流程為：

打開應(yīng)用，初始化場景(觸發(fā)GC)-> 拍攝第一次Snapshot作為基準 -> 多（N）次觸發(fā)內(nèi)存泄漏操作 -> 拍攝第二次堆快照 -> 觸發(fā)主動GC-> 拍攝第三次堆快照

由于方舟虛擬機提供了在獲取堆快照之前自動GC的功能，因此我們可以將上述流程簡化為兩步，同時加上Profiler的錄制功能，整體流程為：

打開應(yīng)用，初始化場景-> 開啟錄制Snapshot Insight-> 拍攝第一次Snapshot作為基準 -> 多（N）次觸發(fā)內(nèi)存泄漏操作 -> 拍攝第二次堆快照-> 結(jié)束錄制

錄制完成后，會得到如下圖所示的數(shù)據(jù)

錄制過程中，我們采集了兩次堆快照，對應(yīng)在Profiler的界面上就是兩個紫色的條塊，每一個條塊內(nèi)的數(shù)據(jù)都是當(dāng)前的虛擬機堆快照。條塊上的數(shù)字大小代表的是虛擬機堆內(nèi)存的實際占用。

由于在每次拍攝堆快照之前，虛擬機都會觸發(fā)GC，所以理論上堆快照內(nèi)存在的對象都是當(dāng)前虛擬機已經(jīng)無法GC掉的對象，所以我們可以將兩個堆快照進行比較，來查看哪些對象是我們在觸發(fā)問題場景時新增了且不能釋放的。

點擊Snapshot Insight面板的Comparison頁簽，將兩次Snapshot進行比較，如下圖。圖中數(shù)據(jù)的含義為以Snapshot2作為基準，Snapshot2對比Snapshot1的數(shù)據(jù)變化量。

即便是比較視圖，東西也非常多，怎么分析呢？

還記得上面說的操作N次嗎，在觸發(fā)內(nèi)存問題場景時將問題觸發(fā)N次，在比較視圖中首先就去找與N強相關(guān)、與業(yè)務(wù)代碼強相關(guān)的constructor，首先來分析這些對象是否正常。

首先介紹一下Snapshot比較視圖中各項數(shù)據(jù)的含義，如下圖，更加具體的也可以參考內(nèi)存泄露分析或者使用Snapshot Insight分析ArkTS內(nèi)存問題。

內(nèi)存泄漏分析：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V13/ide-insight-session-snapshot-V13?catalogVersion=V13

使用Snapshot Insight分析ArkTS內(nèi)存問題：https://developer.huawei.com/consumer/cn/forum/topic/0207154775311720043?fid=0109140870620153026

在找到相關(guān)的業(yè)務(wù)關(guān)聯(lián)的對象后，可以從references里面一層層去尋找、排查在引用鏈上的可疑對象（一般指與業(yè)務(wù)代碼關(guān)聯(lián)的對象，尤其是xxx in com.xxx.yyy這種明顯是業(yè)務(wù)使用到的對象的位置）。

在排查時，可以主要往兩個方向：

1）Distance逐漸減小；

2）引用鏈上都是業(yè)務(wù)相關(guān)的對象。

從這兩個維度去分析入度引用鏈，找出那些業(yè)務(wù)邏輯上應(yīng)該釋放但是實際并沒有釋放的對象及其引用關(guān)系，從這些引用關(guān)系上來排查是否有不合理的強引用導(dǎo)致的內(nèi)存無法釋放的問題，進而解決內(nèi)存泄漏問題。

具體的案例可以參考：使用SnapshotInsight分析ArkTS內(nèi)存問題

使用Snapshot Insight分析ArkTS內(nèi)存問題：https://developer.huawei.com/consumer/cn/forum/topic/0207154775311720043?fid=0109140870620153026

2.2 分析Native內(nèi)存

其次針對Native Heap，由于該部分堆內(nèi)存僅由開發(fā)者自行控制分配釋放，無法使用類似虛擬機的dump手段來分析整體的堆內(nèi)存使用情況，僅可使用Profiler抓取到錄制過程中的應(yīng)用內(nèi)存分配和釋放事件，因此需要開發(fā)者通過內(nèi)存分配/釋放事件以及內(nèi)存分配棧等信息自行找到代碼中的內(nèi)存申請和釋放點來確認是否存在申請、釋放不配對導(dǎo)致的內(nèi)存泄漏問題。

內(nèi)存分析模板Allocation提供了該能力，使用該模板可以抓取到經(jīng)由系統(tǒng)基礎(chǔ)庫分配的Native部分內(nèi)存，分析分配/釋放的匹配邏輯，界面如下圖。

在開始錄制前，需要先了解一些該模板的工作原理以及相關(guān)的配置參數(shù)，以確定能夠抓取到應(yīng)用中可能存在的內(nèi)存問題。

Allocation模板通過hook基礎(chǔ)庫中的某些函數(shù)調(diào)用來獲取每次內(nèi)存分配的數(shù)據(jù)，并將這些數(shù)據(jù)返回至Profiler中，在Profiler中完整的展示這些內(nèi)存的分配、釋放數(shù)據(jù)以及相關(guān)的調(diào)用棧、庫等信息。詳細的使用介紹可以參考這里內(nèi)存分析及優(yōu)化，下面就具體的使用流程做介紹。

內(nèi)存分析及優(yōu)化：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V13/ide-insight-session-allocations-memory-V13?catalogVersion=V13

2.2.1Native數(shù)據(jù)采集

首先，是錄制前的參數(shù)配置，最新版本的配置頁面如下，其中的配置項都是針對NativeAllocation這條泳道的，下面依次介紹：

1）Statistics Mode、Sampling Interval：該項配置代表是否開啟統(tǒng)計模式采集數(shù)據(jù)，默認開啟。開啟后，數(shù)據(jù)會每隔SamplingInterval中設(shè)置的時間從設(shè)備端匯總并返回，該模式下工具的采集性能會更好、負載更低、可采集的時間也更長，但是會丟失掉精準的每次分配釋放的內(nèi)存信息；關(guān)閉該模式，會開啟詳情采集模式，返回的數(shù)據(jù)中會給出每次內(nèi)存分配的詳細情況，包含內(nèi)存分配地址、分配大小、分配棧等信息。推薦使用統(tǒng)計模式，如業(yè)務(wù)側(cè)有需要也可酌情使用詳情模式。

2）Filter Size：過濾內(nèi)存大小。該參數(shù)表示最小抓取的內(nèi)存大小，默認為1024bytes(1kb)，內(nèi)存分配時小于該大小的內(nèi)存分配信息不會被抓取到，應(yīng)用可根據(jù)自身具體情況選擇該參數(shù)。該參數(shù)可能會顯著影響應(yīng)用性能，當(dāng)該值過小且應(yīng)用在分配大量內(nèi)存的場景時（抓取的內(nèi)存分配數(shù)據(jù)量巨大）可能會造成應(yīng)用卡頓，因此建議選擇合適的參數(shù)。

3）Backtrace Mode：內(nèi)存分配棧回棧方式，默認FP回棧。FP回棧性能更好，默認開啟，但在某些特定場景下（例如so的編譯參數(shù)控制），F(xiàn)P回棧可能失效，此時可選擇DWARF回棧嘗試。

4）Record JS Stack：是否開啟JS回棧。當(dāng)該開關(guān)打開時，系統(tǒng)回棧時會自動從Native向JS層回棧，完成Native到JS的棧縫合，適合ArkTS/JS代碼調(diào)用Native的場景。

5）JS Backtrace Depth、Native Backtrace Depth：內(nèi)存回棧深度。代表最大的回棧層數(shù)，層數(shù)越大對性能開銷越大，可結(jié)合業(yè)務(wù)動態(tài)調(diào)整。

注：當(dāng)選擇了DWARF回棧后，JS和Native的回棧深度會變成一個框Backtrace Stack，其層數(shù)代表著JS與Native的共同回棧深度。

做好配置后，可以開始抓取問題場景的數(shù)據(jù)，切記需要在保存數(shù)據(jù)并開啟錄制之后，操作應(yīng)用復(fù)現(xiàn)問題場景，并在問題復(fù)現(xiàn)完成后停止錄制。（注：如果是使用統(tǒng)計模式，錄制的結(jié)束時間需要是SamplingInterval即采集周期的整數(shù)倍，例如當(dāng)采集周期是10s時，停止時間建議在11s+/21s+/31s+，以此類推，留出余量給系統(tǒng)做數(shù)據(jù)處理與傳輸）。錄制完成后界面類似下圖。

其中泳道部分展示了當(dāng)前的內(nèi)存變化情況，Native Allocation泳道下方又涉及兩個子泳道AllHeap和All Anonymous VM，這兩個泳道分別代表使用malloc和mmap函數(shù)分配的內(nèi)存情況，下方的詳情區(qū)域展示對應(yīng)泳道的內(nèi)存分配統(tǒng)計數(shù)據(jù)（Statistics頁簽）與內(nèi)存分配棧（CallTrees）信息。

2.2.2Native數(shù)據(jù)分析

抓取到了問題場景的數(shù)據(jù)，接下來就是對問題數(shù)據(jù)的分析。

首先，框選范圍內(nèi)的數(shù)據(jù)展示的是：在框選范圍的起點之后及在框選范圍的終點之前的所有內(nèi)存分配的數(shù)據(jù)，這個邏輯很重要，會對分析結(jié)論有很大影響，需重點關(guān)注。

接下來，在詳情面板的左下角有一個下拉單選框，能夠篩選當(dāng)前詳情區(qū)域展示的內(nèi)存的數(shù)據(jù)，如下圖所示：

1）All Allocations：框選的時間段的所有分配內(nèi)存信息。

2）Created & Existing：在框選范圍的起點之后分配的，且在框選范圍的終點之前沒有釋放的內(nèi)存數(shù)據(jù)。

3）Created & Released：在框選范圍的起點之后分配的，且在框選范圍的終點之前已經(jīng)釋放的內(nèi)存數(shù)據(jù)。

這三個選項可以根據(jù)具體的業(yè)務(wù)問題和訴求來確定。

第二個框中的Native Size和Native Library代表可以通過這兩個維度：大小和分配庫的信息來做統(tǒng)計，一個是按照分配大小聚合、另一個是按照分配該內(nèi)存的庫來聚合。

通過這個頁簽的統(tǒng)計信息、對未釋放的數(shù)量、大小等列排序后，能夠大致分析出內(nèi)存出現(xiàn)問題的情況以及場景，為分析內(nèi)存棧做一些提前準備。接下來可以把數(shù)據(jù)切換到CallTrees內(nèi)存分配棧上。

該部分數(shù)據(jù)展示了詳細的內(nèi)存分配棧信息，內(nèi)存問題一般都是在該部分通過棧幀信息找出相關(guān)的業(yè)務(wù)邏輯來定位。其中有兩個點需要說明：

1）棧幀中主要為Native棧，除了應(yīng)用本身編譯的一些so及帶有部分接口信息的so信息外，其他系統(tǒng)庫部分僅展示so庫與函數(shù)偏移信息，若需要查看這部分信息，需要導(dǎo)入相應(yīng)版本的帶符號的so庫。具體參考基礎(chǔ)耗時分析中的離線符號解析小節(jié)。

基礎(chǔ)耗時分析：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V13/ide-insight-session-time-V13?catalogVersion=V13

2）開啟Record JS Stack之后，部分棧幀中可能包含JS棧信息，JS棧信息一般對應(yīng)著應(yīng)用源碼，雙擊能夠跳轉(zhuǎn)到代碼行上。

注：所有Category上有高亮色的棧幀信息，都可以通過雙擊跳轉(zhuǎn)到源代碼所在的文件和代碼行上（前提是打開的工程是調(diào)優(yōu)應(yīng)用的相匹配的工程）。

同樣地，在分析調(diào)用棧的過程中，可以使用下方操作欄上的一系列功能，除了上述介紹過的AllAllocations篩選能力之外，在Native Allocation泳道的Call Trees頁簽中，可以通過底部的“Call Trees”和“Constraints”選擇框來過篩選和過濾內(nèi)存分配棧。

Call Trees選擇框包含兩種過濾條件：

Separate byAllocated Size：在內(nèi)存分配棧完全相同的情況下，會按照每次分配棧申請的內(nèi)存大小將棧分開；

Hide SystemLibraries：隱藏內(nèi)存分配棧中的系統(tǒng)堆棧。

Constraints選擇框也包含了兩種過濾條件：

Count：根據(jù)指定的內(nèi)存申請次數(shù)過濾內(nèi)存分配棧信息；

Bytes：根據(jù)指定的內(nèi)存申請大小過濾內(nèi)存分配棧信息。

業(yè)務(wù)方可以根據(jù)自身的業(yè)務(wù)情況與具體的問題場景來適當(dāng)使用這些數(shù)據(jù)篩選能力，同時在下方也提供搜索功能，InvolvesSymbol Name搜索框提供了針對函數(shù)調(diào)用棧的文本搜索能力，可以快速搜索棧幀信息與so庫信息并快捷跳轉(zhuǎn)至對應(yīng)位置。

另外，若表格的樹狀圖不便于直觀看出內(nèi)存信息，可以使用Flame Chart火焰圖開關(guān)，使用火焰圖的形式來分析內(nèi)存分配可能存在的問題，如下圖，火焰圖中的條塊長度越長，代表該調(diào)用棧分配的內(nèi)存大小越大。

2.2.3Native內(nèi)存問題分析

在前面兩個小節(jié)介紹了整個Native Allocation的使用及分析方式，這里簡單介紹具體的問題分析邏輯：

1. 錄制問題場景的內(nèi)存分配信息；

2. 從統(tǒng)計信息及內(nèi)存分配棧查看在當(dāng)前范圍內(nèi)未釋放的內(nèi)存信息（選擇Created &Existing），通過2.2.2節(jié)中介紹的各種分析和篩選能力找出未釋放的內(nèi)存堆棧，并將該堆棧結(jié)合業(yè)務(wù)邏輯分析；

3. 若涉及ArkTS代碼對Native的調(diào)用邏輯，可開啟Record JS Stack開關(guān)，將Native的內(nèi)存棧回棧至JS層，簡化分析難度；

4. 通過這些問題棧幀信息映射到業(yè)務(wù)代碼中，結(jié)合問題場景和代碼分析為何該部分內(nèi)存未釋放，找到問題點。

修改及驗證

當(dāng)經(jīng)過上述步驟的流程分析完應(yīng)用的內(nèi)存問題之后，基本上已經(jīng)可以定位到問題發(fā)生的位置及相關(guān)的代碼段，在此基礎(chǔ)上結(jié)合業(yè)務(wù)邏輯對代碼做修改，修改后重新編譯推包到真機上，在相同的場景下嘗試復(fù)現(xiàn)問題，并使用實時監(jiān)控或者Allocation/Snapshot模板的Memory泳道來監(jiān)測應(yīng)用內(nèi)存占用情況，以確認問題是否還存在。

總結(jié)

問題不是一朝一夕出現(xiàn)的，通常問題會在開發(fā)的過程中逐漸積累，到最終暴露出來時可能已經(jīng)涉及了多個模塊、多種邏輯，各種邏輯互相耦合，導(dǎo)致分析的難度大大增加。

這種情況下，我們建議把性能相關(guān)的工作也能做到平時，在開發(fā)過程中也去關(guān)心程序的性能問題。例如，剛寫了一段很長的引用關(guān)系、增加了一些注冊實例的邏輯或者做了一些組件間的變量傳遞，這種時候就可以去結(jié)合邏輯自己設(shè)想一下，會不會引發(fā)一定的性能問題，甚至可以在平時就用調(diào)優(yōu)工具來檢測一把。

這樣做到每個開發(fā)階段都保證了性能的可靠，那么在項目日益增大的同時，性能問題也不會嚴重到離譜、無法分析。

附錄

DevEco Studio下載鏈接：https://developer.huawei.com/consumer/cn/deveco-studio/

DevEco Profiler官方指導(dǎo)文檔：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-insight-V5