【厚積薄發(fā)】小游戲發(fā)熱的系統(tǒng)排查與性能調(diào)優(yōu)實(shí)戰(zhàn)

這是第482篇UWA技術(shù)知識(shí)分享的推送，精選了UWA社區(qū)、UWA AI問(wèn)答的熱門(mén)話題等技術(shù)知識(shí)點(diǎn)，助力大家更全面地掌握和學(xué)習(xí)。

UWA社區(qū)主頁(yè)：community.uwa4d.com

UWA QQ群：793972859

本期目錄：

• 小游戲發(fā)熱問(wèn)題的系統(tǒng)排查法

• iOS高性能模式下的內(nèi)存與合批博弈

本次推送的實(shí)戰(zhàn)案例來(lái)自于使用UWA服務(wù)的項(xiàng)目的真實(shí)且典型的問(wèn)題。UWA將關(guān)鍵線索、定位路徑與處理建議整理成了可復(fù)用的案例筆記，便于大家快速對(duì)照、排查自身項(xiàng)目中的同類(lèi)問(wèn)題。

實(shí)戰(zhàn)案例

Q：我們項(xiàng)目最近發(fā)熱問(wèn)題比較嚴(yán)重，玩家反饋集中在“玩一段時(shí)間后手機(jī)發(fā)燙”。我們用UWA GOT Online跑了一份小游戲性能報(bào)告，針對(duì)里面CPU占比偏高的幾個(gè)模塊做了一輪優(yōu)化，但實(shí)際跑下來(lái)降溫效果并不明顯，想問(wèn)一下，除了CPU模塊本身，是不是還有別的維度漏看了？這種發(fā)熱問(wèn)題該怎么系統(tǒng)排查？

A：移動(dòng)端發(fā)熱可以從CPU、GPU、屏幕、網(wǎng)絡(luò)四個(gè)維度切入。屏幕和網(wǎng)絡(luò)我們也做過(guò)測(cè)試，對(duì)發(fā)熱確實(shí)有貢獻(xiàn)，但很難單獨(dú)拆出來(lái)，真正能動(dòng)手優(yōu)化的還是CPU和GPU。

圖源：微信官方文檔

受小游戲接口限制，UWA GOT Online小游戲報(bào)告暫時(shí)拿不到CPU/GPU溫度數(shù)據(jù)，我們改用UWA Gears工具補(bǔ)測(cè)后發(fā)現(xiàn)，CPU溫度持續(xù)高于GPU，所以這個(gè)項(xiàng)目的發(fā)熱主導(dǎo)確認(rèn)是CPU。接下來(lái)拆解GOT Online的CPU數(shù)據(jù)，可以看到問(wèn)題主要集中在三類(lèi)結(jié)構(gòu)性負(fù)載。

第一類(lèi)是戰(zhàn)斗邏輯模塊。高負(fù)載場(chǎng)景下出現(xiàn)明顯的幀級(jí)Spike，單幀耗時(shí)甚至超過(guò)100ms，本質(zhì)是戰(zhàn)斗Tick在復(fù)雜場(chǎng)景中的集中執(zhí)行，造成階段性壓力堆積。

第二類(lèi)是渲染模塊。整體平穩(wěn)，但大廳與武器、復(fù)雜UI界面耗時(shí)升到20ms左右，主要來(lái)自半透明對(duì)象渲染造成的Overdraw，以及UI嵌套過(guò)深導(dǎo)致的Batch Break，DrawCall超過(guò)250的UWA推薦閾值。

第三類(lèi)是UI模塊。均值耗時(shí)8-9ms（高于UWA推薦值），CanvasRenderer.SyncTransform調(diào)用頻次異常高（峰值達(dá)940次），根因是UI狀態(tài)切換過(guò)于頻繁（SetActive/Instantiate/銷(xiāo)毀），重建鏈路反復(fù)觸發(fā)，形成尖刺型耗時(shí)。

除上面三類(lèi)主要負(fù)載，CPU里還有一個(gè)容易忽略的次級(jí)開(kāi)銷(xiāo)“物理空轉(zhuǎn)”，報(bào)告里Physics 3D的Overlaps調(diào)用次數(shù)全程為0，說(shuō)明項(xiàng)目沒(méi)觸發(fā)過(guò)3D物理碰撞（實(shí)際可能只用到Physics 2D的射線檢測(cè)或重力），但物理模塊依然按默認(rèn)Fixed Update模式持續(xù)Step。如果業(yè)務(wù)上不依賴(lài)自動(dòng)模擬，可以把Update Mode改成Script，如果還需要射線檢測(cè)，再勾上Auto SyncTransform保證Transform實(shí)時(shí)同步。

回到這個(gè)項(xiàng)目，發(fā)熱的本質(zhì)不是單點(diǎn)CPU過(guò)高，而是CPU內(nèi)部三個(gè)模塊的負(fù)載疊加，邏輯代碼的實(shí)例化Spike、渲染的Overdraw與Batch Break、UI的重建過(guò)頻。物理空轉(zhuǎn)是順手處理的小尾巴，GPU整體只是次級(jí)貢獻(xiàn)。

實(shí)戰(zhàn)案例

Q：我們iOS端開(kāi)了高性能加模式，圖標(biāo)比較多，如果都打到一張圖集里，會(huì)導(dǎo)致內(nèi)存占用偏高，你們之前有沒(méi)有遇到過(guò)這種情況？有什么優(yōu)化建議嗎？

A：在這種配置下，圖集帶來(lái)的“內(nèi)存增長(zhǎng)”，需要先區(qū)分是工具統(tǒng)計(jì)層面的變化，還是實(shí)際會(huì)影響閃退風(fēng)險(xiǎn)的系統(tǒng)級(jí)壓力變化，否則容易出現(xiàn)判斷偏差。

在iOS高性能模式下，紋理相關(guān)內(nèi)存的分布機(jī)制與Unity Heap并不完全一致，部分紋理資源會(huì)進(jìn)入系統(tǒng)圖形層（GPU/iOS圖形內(nèi)存池）進(jìn)行管理，因此在小游戲側(cè)看到的內(nèi)存增長(zhǎng)，并不一定完整等價(jià)于最終的進(jìn)程級(jí)內(nèi)存壓力。

小游戲的閃退判定也不是只看Unity Heap總量，而是取決于整體內(nèi)存壓力來(lái)源，包括WebContent進(jìn)程RSS、Native內(nèi)存占用、GPU紋理壓力以及系統(tǒng)Jetsam機(jī)制的綜合結(jié)果。因此，圖集帶來(lái)的內(nèi)存變化本身，并不必然直接轉(zhuǎn)化為閃退風(fēng)險(xiǎn)。

反過(guò)來(lái)看散圖，省的是內(nèi)存，但代價(jià)在CPU和渲染鏈路上。散圖是按需加載的（比如100張圖只用20張，其余不會(huì)進(jìn)入內(nèi)存），從“單次內(nèi)存占用”來(lái)看確實(shí)更輕。但碎片化資源會(huì)導(dǎo)致UI合批被打斷，紋理切換增加，同時(shí)UI提交階段CPU開(kāi)銷(xiāo)上升，這部分開(kāi)銷(xiāo)在小游戲環(huán)境下往往比單純的紋理內(nèi)存增長(zhǎng)更容易影響幀率與發(fā)熱。

圖集方案則是另一種權(quán)衡：它會(huì)帶來(lái)一次性的加載成本，包括貼圖解碼與GPU上傳，同時(shí)內(nèi)存占用更集中。但換來(lái)的收益是更穩(wěn)定的合批效果、更少的紋理切換，以及更低的UI渲染提交CPU開(kāi)銷(xiāo)。

所以在圖標(biāo)較多的UI場(chǎng)景下，在iOS高性能加模式+無(wú)Read/Write紋理的前提下，我們一般仍然建議優(yōu)先使用圖集。首次加載雖然有額外開(kāi)銷(xiāo)，但在穩(wěn)定運(yùn)行階段，整體CPU成本和渲染穩(wěn)定性會(huì)更優(yōu)。從工程角度看，這里的關(guān)鍵不是“圖集是否更省內(nèi)存”，而是它在CPU渲染鏈路上的收益通常會(huì)覆蓋內(nèi)存集中帶來(lái)的成本。

無(wú)論是社區(qū)里開(kāi)發(fā)者們的互助討論，還是AI基于知識(shí)沉淀的快速反饋，核心都是為了讓每一個(gè)技術(shù)難題都有解、每一次踩坑都有回響。希望這些從真實(shí)開(kāi)發(fā)場(chǎng)景中提煉的經(jīng)驗(yàn)，能直接幫你解決當(dāng)下的技術(shù)卡點(diǎn)，也讓你在遇到同類(lèi)問(wèn)題時(shí)，能更高效地找到破局方向。

封面圖來(lái)源于網(wǎng)絡(luò)

今天的分享就到這里。生有涯而知無(wú)涯，在漫漫的開(kāi)發(fā)周期中，我們遇到的問(wèn)題只是冰山一角，UWA社區(qū)愿伴你同行，一起探索分享。歡迎更多的開(kāi)發(fā)者加入U(xiǎn)WA社區(qū)。

UWA官網(wǎng)：www.uwa4d.com

UWA社區(qū)：community.uwa4d.com

UWA學(xué)堂：edu.uwa4d.com

點(diǎn)擊下方名片關(guān)注我們，將我設(shè)為星標(biāo)，及時(shí)接收小編每日推送哦，性能優(yōu)化不迷路～

近期精彩回顧