如何使用DevEco Studio性能調(diào)優(yōu)工具Profiler定位應(yīng)用內(nèi)存問題

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

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中提供了針對(duì)鴻蒙應(yīng)用內(nèi)存問題的場(chǎng)景化分析模板SnapshotInsight與Allocation Insight，可以用于分析ArkTS以及Native內(nèi)存，幫助開發(fā)者高效定位解決內(nèi)存問題。下面將從識(shí)別問題、定界定位、優(yōu)化驗(yàn)證三個(gè)方面來(lái)對(duì)DevEcoProfiler定位內(nèi)存問題的方法進(jìn)行介紹。

識(shí)別內(nèi)存問題

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

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

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

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

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

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

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

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

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

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

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

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

定位內(nèi)存問題

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

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

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

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

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

2.1 ArkTS內(nèi)存問題

2.1.1 ArkTS內(nèi)存管理

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

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

圖1 對(duì)象可達(dá)性分析

2.1.2 ArkTSHeap分析

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

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

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

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

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

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

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

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

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

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

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

首先介紹一下Snapshot比較視圖中各項(xiàng)數(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)的對(duì)象后，可以從references里面一層層去尋找、排查在引用鏈上的可疑對(duì)象（一般指與業(yè)務(wù)代碼關(guān)聯(lián)的對(duì)象，尤其是xxx in com.xxx.yyy這種明顯是業(yè)務(wù)使用到的對(duì)象的位置）。

在排查時(shí)，可以主要往兩個(gè)方向：

1）Distance逐漸減小；

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

從這兩個(gè)維度去分析入度引用鏈，找出那些業(yè)務(wù)邏輯上應(yīng)該釋放但是實(shí)際并沒有釋放的對(duì)象及其引用關(guān)系，從這些引用關(guān)系上來(lái)排查是否有不合理的強(qiáng)引用導(dǎo)致的內(nèi)存無(wú)法釋放的問題，進(jìn)而解決內(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)存

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

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

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

Allocation模板通過hook基礎(chǔ)庫(kù)中的某些函數(shù)調(diào)用來(lái)獲取每次內(nèi)存分配的數(shù)據(jù)，并將這些數(shù)據(jù)返回至Profiler中，在Profiler中完整的展示這些內(nèi)存的分配、釋放數(shù)據(jù)以及相關(guān)的調(diào)用棧、庫(kù)等信息。詳細(xì)的使用介紹可以參考這里內(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ù)配置，最新版本的配置頁(yè)面如下，其中的配置項(xiàng)都是針對(duì)NativeAllocation這條泳道的，下面依次介紹：

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

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

3）Backtrace Mode：內(nèi)存分配?；貤７绞?，默認(rèn)FP回棧。FP回棧性能更好，默認(rèn)開啟，但在某些特定場(chǎng)景下（例如so的編譯參數(shù)控制），F(xiàn)P回?？赡苁?，此時(shí)可選擇DWARF回棧嘗試。

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

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

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

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

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

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

抓取到了問題場(chǎng)景的數(shù)據(jù)，接下來(lái)就是對(duì)問題數(shù)據(jù)的分析。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 若涉及ArkTS代碼對(duì)Native的調(diào)用邏輯，可開啟Record JS Stack開關(guān)，將Native的內(nèi)存?；貤Ｖ罦S層，簡(jiǎn)化分析難度；

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

修改及驗(yàn)證

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

總結(jié)

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

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

這樣做到每個(gè)開發(fā)階段都保證了性能的可靠，那么在項(xiàng)目日益增大的同時(shí)，性能問題也不會(huì)嚴(yán)重到離譜、無(wú)法分析。

附錄

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