【厚積薄發】為什么Mono堆內存總是居高不下

這是第475篇UWA技術知識分享的推送，精選了UWA社區、UWA AI問答的熱門話題等技術知識點，助力大家更全面地掌握和學習。

UWA社區主頁：community.uwa4d.com

UWA QQ群：793972859

本期目錄：

• 持續性字符串拼接：每幀5KB從何而來？

• 碎片占比超50%：Mono內存碎片化怎么避免？

本次推送的實戰案例來自于使用UWA服務的項目的真實且典型的問題。UWA將關鍵線索、定位路徑與處理建議整理成了可復用的案例筆記，便于大家快速對照、排查自身項目中的同類問題。

實戰案例

Q：GOT Online Mono模式報告顯示，我們項目Mono堆內存中存在持續的字符串拼接現象，這是什么原因導致的，該怎么定位和優化？

A：看到在UIPanel.LateUpdate中全程出現持續的String.Concat的分配，出現這種現象常見的原因包括：UI元素的name賦值；Panel取名等邏輯里存在字符串拼接；業務打點日志中頻繁做字符串拼接；Shader查找流程中存在名稱拼接操作等。優化原則是避免每幀進行字符串拼接操作，將拼接結果緩存復用，減少Mono堆內存臨時分配，字符串拼接邏輯本身也不應放在游戲核心循環的熱路徑中。

從當前報告數據來看，僅僅是 持續字符串拼接每幀新增約5KB臨時垃圾分配，再加上NGUI中一些其它分配，累計每萬幀分配量超90MB。UWA推薦Mono報告中Top10函數平均每10k幀分配堆內存總和小于50MB，目前僅一個UIPanel.LateUpdate就已超出推薦值范圍，因此要對以UIPanel.LateUpdate為首的多個分配較高的函數進行排查。

排查方法是在Mono模式報告中，按"分配視角"查看函數堆棧，定位累積分配最多的葉子函數，追溯其調用路徑。另外還可以利用報告里的倒序調用分析模塊，它能直接定位高分配的底層問題函數，幫我們省去逐層排查的繁瑣操作，例如上述的String.Concat問題就能直接定位到。

Q：另外我們還在報告中發現Mono堆內存出現了一個52MB的大數組，但查不到具體來源，該怎么排查？

A：我們可以從這份Mono模式報告看到，這個byte數組從測試開始就存在，但無法獲取其分配堆棧。這是因為在 UWA性能采集啟動前（ 游戲初始化階段 ）， 該數組就已經完成分配了，所以追蹤不到來源。

需要我們采集數據的時候，在SDK面板上點擊Direct Mode進行采集。點擊Direct Mode后會在開始采集時殺掉進程并重新啟動游戲，從游戲啟動開始，Mono分配的整個生命周期就會被采集，這樣就可以追蹤到之前無法獲取堆棧的大數組來源了。

這類大數組常見來源多為大型配置表、場景標記數據等。

若確認是配置表導致，可優化兩點：

• 將配置表數據下沉至Native層存儲，不占用Mono堆內存，規避GC壓力與回收耗時；

• 改用更緊湊的數據結構，例如用bit替代int存儲標記信息，進一步縮減內存占用。

實戰案例

Q：Mono內存碎片化比較嚴重，怎么避免，有什么優化建議？

A：從報告來看，碎片占比高達112MB/219MB（約51%），在堆內存分配釋放較為頻繁的項目中，UWA也常觀察到對象實際占用的部分和碎片會逐漸趨于相等。 Unity的Boehm GC為非壓縮回收器，不會主動整理Mono堆碎片，頻繁產生臨時內存分配，是造成碎片化的主要原因； 即便GC回收空閑內存，已形成的碎片也無法合并成連續大塊，只能被小對象復用，因此要盡量減緩碎片占比逐漸上升的趨勢。

我們可以從以下三個方面進行優化：

第一，減少臨時分配，避免在熱路徑上進行字符串拼接、容器擴容等操作；

第二，對頻繁創建銷毀的對象使用對象池復用；

第三，對可預期的容器預分配足夠容量，避免運行時擴容。

無論是社區里開發者們的互助討論，還是AI基于知識沉淀的快速反饋，核心都是為了讓每一個技術難題都有解、每一次踩坑都有回響。希望這些從真實開發場景中提煉的經驗，能直接幫你解決當下的技術卡點，也讓你在遇到同類問題時，能更高效地找到破局方向。

封面圖來源于網絡

今天的分享就到這里。生有涯而知無涯，在漫漫的開發周期中，我們遇到的問題只是冰山一角，UWA社區愿伴你同行，一起探索分享。歡迎更多的開發者加入UWA社區。

UWA官網：www.uwa4d.com

UWA社區：community.uwa4d.com

UWA學堂：edu.uwa4d.com

點擊下方名片關注我們，將我設為星標，及時接收小編每日推送哦，性能優化不迷路～

近期精彩回顧