在鴻蒙ArkTS與Native（C/C++）交互的開發(fā)場景中，ArkTS對象被Native引用導(dǎo)致的內(nèi)存泄漏問題是開發(fā)者的一大痛點(diǎn)。

這類問題的傳統(tǒng)定位方式高度依賴開發(fā)者具備深厚的技術(shù)積累，不僅要求開發(fā)者要精通ArkTS引擎垃圾回收機(jī)制、鴻蒙NAPI交互模型等基礎(chǔ)理論，還要深入理解應(yīng)用代碼的實(shí)現(xiàn)細(xì)節(jié)，尤其在應(yīng)用由多個(gè)模塊組成、模塊間依賴關(guān)系復(fù)雜的場景下，問題定位復(fù)雜度倍增。

這種高門檻導(dǎo)致許多開發(fā)者，尤其是初學(xué)者，在面對ArkTS對象被Native引用導(dǎo)致內(nèi)存泄漏問題時(shí)往往無從下手，只能通過參考典型案例、分析大量業(yè)務(wù)代碼來進(jìn)行問題定位，效率較為低下。

為了幫助開發(fā)者更高效地定位和解決此類內(nèi)存泄漏問題，DevEco Studio 的 Profiler 工具迎來了重大升級！本次更新增強(qiáng)了 Allocation 內(nèi)存分析能力，新增了 ArkTS Snapshot 泳道，支持 Local Handle 和 Global Handle 采樣模式，在跨語言調(diào)用場景中，打通 ArkTS 和 C++ 語言邊界，內(nèi)存泄漏大小和泄漏對象信息易觀測，問題定位效率倍增。

本文中，我們將結(jié)合DevEco Studio Profiler 工具，系統(tǒng)梳理 ArkTS 對象被Native 引用導(dǎo)致內(nèi)存泄漏的定位思路、實(shí)操步驟與最佳實(shí)踐。

為什么 ArkTS 對象會(huì)被 Native “鎖死”？

ArkTS 對象被 Native 引用導(dǎo)致內(nèi)存泄漏的根因在于 Native 代碼通過napi_ref或不當(dāng)使用napi_value，導(dǎo)致長期持有 ArkTS 對象，形成了“隱形強(qiáng)引用”，阻斷了 ArkTS 引擎的垃圾回收。

在鴻蒙 NAPI 交互模型中，Native 代碼引用 ArkTS 對象主要依賴兩種句柄：Local Handle(napi_value): 通常指在 Native 代碼執(zhí)行上下文中創(chuàng)建的、作用域較短的引用，由 handle scope 來管理。

Global Handle (napi_ref): 這是一種由開發(fā)者自行管理生命周期的強(qiáng)引用。

ArkTS引擎的垃圾回收是基于“可達(dá)性分析”算法實(shí)現(xiàn)的，當(dāng)ArkTS側(cè)所有引用（變量、閉包等）被清除后，對象理論上應(yīng)被回收。一旦Native代碼通過napi_ref或napi_value不當(dāng)持有該對象，這兩種句柄會(huì)在GC圖中成為一個(gè)“根節(jié)點(diǎn)”。即使ArkTS側(cè)已徹底斷開引用，GC仍會(huì)判定該對象“可達(dá)”，導(dǎo)致無法回收。久而久之，未釋放的句柄堆積，演變?yōu)閮?nèi)存溢出問題。

升級后的Allocation 內(nèi)存分析工具能做什么？

在定位ArkTS對象被Native引用引發(fā)的內(nèi)存泄露問題時(shí)，開發(fā)者常受限于工具或日志信息不足，難以追溯具體是哪塊Native代碼在持有著它。這導(dǎo)致泄漏邊界模糊、引用鏈斷裂，定界分析極為困難。升級后的Allocation工具實(shí)現(xiàn)了關(guān)鍵突破——支持ArkTS對象和Native引用分配調(diào)用棧 的雙向關(guān)聯(lián)，可精準(zhǔn)追溯持有權(quán)屬，快速還原跨語言引用關(guān)系鏈，大幅降低定位門檻。

ArkTS內(nèi)存泄漏分析案例

案例背景

現(xiàn)象：本案例中，通過復(fù)現(xiàn)‘首頁至消息頁’的反復(fù)進(jìn)出操作，觀察到應(yīng)用內(nèi)存占用呈現(xiàn)"階梯式持續(xù)增長"趨勢。在循環(huán)操作10次后，應(yīng)用出現(xiàn)顯著卡頓現(xiàn)象。

初步判斷：典型的“階梯式內(nèi)存增長”，高度疑似內(nèi)存泄漏。

分析流程

步驟1：Memory泳道確認(rèn)泄漏

1、打開 DevEco Studio，連接真機(jī)，點(diǎn)擊 Profiler 工具 Realtime Monitor（也可使用 snapshot 模板的 Memory 錄制觀察，以下是使用 Realtime Monitor 觀察）。

2、啟動(dòng)應(yīng)用，選擇設(shè)備與應(yīng)用進(jìn)程。

3、點(diǎn)擊錄制按鈕，在設(shè)備上重復(fù)操作：進(jìn)入消息頁面 → 停留 2 秒 → 返回首頁，重復(fù)多次。

4、觀察內(nèi)存曲線：

正常預(yù)期：每次退出后內(nèi)存回落至基線附近，整體呈鋸齒狀。

實(shí)際現(xiàn)象：曲線呈階梯狀上升，多次操作后內(nèi)存增長至 314.1 MB 且無明顯回落。

確認(rèn)存在內(nèi)存泄漏，進(jìn)入下一步。

步驟2：堆快照對比定位異常對象

1、在 Profiler 中切換到Snapshot模板，請參考使用 Snapshot 模板基本操作：

Snapshot 模板基本操作:

https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/ide-snapshot-basic-operations

選擇 Profiler 工具 → 選擇設(shè)備與應(yīng)用進(jìn)程 → 選擇 Snapshot 模板 → 創(chuàng)建Session → 啟動(dòng)錄制

2、抓取快照 1：首次在進(jìn)入消息頁前，點(diǎn)擊“Take Heap Snapshot”。

3、抓取快照 2：重復(fù)進(jìn)出消息頁面7 次后，回到首頁，點(diǎn)擊 “Take Heap Snapshot”，再抓取第二次快照，并停止錄制。

4、在快照對比視圖 Comparison 中，選擇CompareTo Snapshot 1。

5、查看對象新增銷毀情況，優(yōu)先關(guān)注：

操作次數(shù)的整數(shù)倍或整數(shù)倍+1（export出的對象本身也有一條引用鏈）;

業(yè)務(wù)對象，即Constructor的結(jié)構(gòu)為包名/模塊名/文件路徑#泄漏對象

關(guān)鍵發(fā)現(xiàn)：

對比結(jié)果中，Proxy對象數(shù)量異常，創(chuàng)建70個(gè)未銷毀。

確認(rèn)Test對象實(shí)例泄漏。

步驟3：追蹤引用鏈

1、點(diǎn)擊 “Shortest Paths” 獲得如下Proxy對象實(shí)例的最短引用鏈，發(fā)現(xiàn)該P(yáng)roxy對象的 Distance 為 1 。說明其為 GC Root 直接持有的對象，被 Native 側(cè)直接持有未釋放，即 JS 對象被 Local Handle / Global Handle 引用導(dǎo)致內(nèi)存泄漏。

2、通過Proxy對象的 Distance 為 1 的References，確認(rèn)內(nèi)存泄漏是由JS 對象被 Global Handle 引用導(dǎo)致。

步驟4：分析Local Handle / Global Handle 類型持有導(dǎo)致泄漏問題

基于步驟3分析得到Proxy對象實(shí)例可能被 Local Handle / Global Handle 引用導(dǎo)致內(nèi)存泄露，我們可以通過以下步驟繼續(xù)分析定位：

1、配置 Allocation 錄制模板并捕獲數(shù)據(jù)

打開 DevEco Studio：確保你的工程已加載，并連接了目標(biāo)設(shè)備或模擬器。

進(jìn)入Profiler模塊：在主界面下方菜單欄，找到并點(diǎn)擊Profiler選項(xiàng)卡。

選擇應(yīng)用進(jìn)程：運(yùn)行應(yīng)用，并在“區(qū)域2 ”選擇目標(biāo)設(shè)備和應(yīng)用進(jìn)程。

創(chuàng)建 Allocation 錄制模板：選擇 “Allocation” 并點(diǎn)擊 Create Session 創(chuàng)建錄制模板

配置錄制參數(shù)

配置模式：選擇詳情模式（即關(guān)閉 Statistics Mode ）。當(dāng)前僅詳情模式支持進(jìn)行 ArkTS 和 Native 的關(guān)聯(lián)分析。

配置開關(guān)：勾選“Local Handle”和“Global Handle”，這是關(guān)鍵配置。這將使Allocation 專門捕獲與 JS-NAPI 句柄相關(guān)的內(nèi)存分配事件。

如果底層鏡像不支持該功能，則會(huì)提示“當(dāng)前鏡像版本不支持，請升級鏡像”。

配置泳道范圍：勾選 ArkTS Snapshot 泳道。這將使 Allocation 在錄制結(jié)尾時(shí)自動(dòng)抓取一份 Snapshot 快照用于關(guān)聯(lián)分析。

啟動(dòng)錄制：勾選了“Local Handle”開關(guān)后，如果是在應(yīng)用本生命周期內(nèi)首次錄制local handle數(shù)據(jù)，會(huì)觸發(fā)彈窗請求重啟應(yīng)用以便錄制對應(yīng)信息，此時(shí)點(diǎn)擊OK允許重啟即可。

運(yùn)行應(yīng)用程序：運(yùn)行目標(biāo)應(yīng)用，執(zhí)行相關(guān)被懷疑引入內(nèi)存泄露的業(yè)務(wù)操作，持續(xù)一段時(shí)間以增加內(nèi)存壓力和捕獲更多數(shù)據(jù)。

停止錄制：自動(dòng)觸發(fā)抓取一份Snapshot快照用于關(guān)聯(lián)分析。點(diǎn)擊快照，查找到疑似泄漏對象Proxy。

2、泄漏對象關(guān)聯(lián)分析

定位可疑ArkTS對象：選中一個(gè)懷疑被泄漏的ArkTS對象實(shí)例（或?qū)ο箢愋停榭磾U(kuò)展標(biāo)簽頁。

查看 Native List：若某個(gè) ArkTS 對象的distance值為 1，則可以通過擴(kuò)展標(biāo)簽頁中的Native List標(biāo)簽頁，查看所有當(dāng)前與該 JS 對象關(guān)聯(lián)的 Native 句柄引用，以確認(rèn)該 JS 對象是被Local Handle或Global Handle引用的對象。

關(guān)鍵信息：

(1)句柄類型：調(diào)用棧底層的符號ArkGlobalHandle或ArkLocalHandle判斷泄漏類型

(2)調(diào)用棧：通過調(diào)用棧，可以定位到應(yīng)用的Native代碼（可能是ArkUI框架代碼或你自己代碼）中創(chuàng)建napi_ref的地方。

(3)注意點(diǎn)：

如果該 JS 對象節(jié)點(diǎn)不是一個(gè)被 Local Handle 或者 Global Handle 引用的對象，則會(huì)提示 "No Detail"；

如果該JS對象確實(shí)是一個(gè)被Local Handle或者Global Handle引用的對象，但是對應(yīng)的native內(nèi)存的申請事件已經(jīng)在此次錄制之前完成內(nèi)存分配，本次錄制結(jié)果則無法展示對應(yīng)的內(nèi)存申請調(diào)用棧，需要重新錄制，錄制時(shí)需要注意將錄制時(shí)執(zhí)行的業(yè)務(wù)邏輯范圍調(diào)整的盡量更早一些。

3、分析內(nèi)存分配調(diào)用棧

排查調(diào)用棧：“Native List”標(biāo)簽頁中的調(diào)用棧，找到對應(yīng)業(yè)務(wù)代碼

關(guān)鍵排查點(diǎn)：

檢查是否在適當(dāng)?shù)臅r(shí)候調(diào)用了對應(yīng)的句柄釋放接口如napi_delete_reference等。

梳理這段Native代碼需要引用ArkTS對象的合理性，識別這個(gè)引用的生命周期是否過長，是否應(yīng)該在某個(gè)條件滿足后被釋放；

對于napi_ref，其引用計(jì)數(shù)是關(guān)鍵。確保在不再需要引用時(shí)正確調(diào)用了napi_delete_reference。注意，引用計(jì)數(shù)可能因其他代碼路徑的創(chuàng)建或刪除操作而意外增減。

檢查句柄的作用域是否合理。local handle是否應(yīng)該只在 JS 執(zhí)行上下文切換前使用？global handle是否真的需要在整個(gè)應(yīng)用生命周期都有效

修復(fù)驗(yàn)證

1、重新運(yùn)行應(yīng)用，再次使用 Memory 泳道監(jiān)控。

2、重復(fù)多次進(jìn)出消息中心頁。

3、驗(yàn)證結(jié)果：

內(nèi)存曲線恢復(fù)鋸齒狀，每次退出后回落至基線。

再次抓取快照對比，多次操作后業(yè)務(wù)對象實(shí)例數(shù)量無明顯增長。

泄漏問題已修復(fù)。

體驗(yàn)與推廣

DevEco Studio Profile 工具的跨語言交互內(nèi)存泄漏定位能力已就緒，歡迎開發(fā)者前往 DevEco Studio 體驗(yàn)最新內(nèi)存分析功能，助力開發(fā)者提高內(nèi)存問題定位效率。