精進(jìn)與突破 | UWA問答精選

【厚積薄發(fā)】精選了UWA社區(qū)的熱門話題，涵蓋了UWA問答、社區(qū)帖子等技術(shù)知識點(diǎn)，助力大家更全面地掌握和學(xué)習(xí)。本期 精選了2025年上半年的十大精彩問答分享給大家，期待UWA問答繼續(xù)有您的陪伴。

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

Q1：OpenGL中Shader LOD失效

我切換為OpenGL之后，發(fā)現(xiàn)切換Shader LOD的功能不能用了，切換為Vulkan沒問題，但是OpenGL就不行。同樣的Shader代碼，同樣的LOD配置。有什么解決思路嗎？

切換為OpenGL之后，F(xiàn)rame Debugger抓幀，都看不到那些本來要繪制的物體，感覺是完全沒有找到對應(yīng)的LOD SubShader。

A1：Unity引擎里沒有處理好關(guān)于CBuffer變量的問題。如果CBuffer中有Shader用不到的變量，并且這個變量沒有在Properties中定義，那么就會導(dǎo)致對應(yīng)的Pass直接不渲染。

修改方法就是，要么直接去掉這些不用的CBuffer中的變量，要么增加對應(yīng)Properties中的定義。

感謝付炳楠@UWA問答社區(qū)提供了回答

A2：我也在Unity 2022.3.51f1c1里碰到類似的情況了，明明寫了3級LOD，結(jié)果永遠(yuǎn)只有最大的那一級正常，中間或者更低的輸出的都是紅黑藍(lán)這種奇怪的顏色。

但是我Vulkan那邊同樣也是不正常的，不過在重新整理過CBuffer后痊愈了。

感謝王禹@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/6784ada03d306f3e9d594e0f

Q2：iOS進(jìn)程增加內(nèi)存上限的接口

在打iOS包的時候注意到Xcode里有這么一個設(shè)置，在文檔里搜到了如下鏈接，說是能讓應(yīng)用獲得更高的內(nèi)存上限？實(shí)際效果怎么樣，有沒有什么副作用？大家有沒有用過?

https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.kernel.increased-memory-limit

A： 應(yīng)該說的是Xcode里Increased Memory Limit這個設(shè)置。我們項(xiàng)目實(shí)測能讓iOS設(shè)備對APP因內(nèi)存而閃退的臨界值從1.8GB上升到2.3GB，多出這500MB能做很多很多事了。

注意點(diǎn)基本也寫在文檔里了：只能在iOS15版本以上的設(shè)備使用；實(shí)際提升空間是跟硬件設(shè)備走的，要用接口os_proc_available_memory | Apple Developer Documentation（

https://developer.apple.com/documentation/os/3191911-os_proc_available_memory

該回答由UWA提供，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/67b2a8453d306f3e9d594e5f

Q3：關(guān)于CanvasRenderer.SyncTransform觸發(fā)調(diào)用的機(jī)制

已知UGUI主要耗時函數(shù)Rendering.UpdateBatches下的堆棧CanvasRenderer.SyncTransform調(diào)用次數(shù)較高確實(shí)會導(dǎo)致更高的整體耗時。看文檔和字面意思，應(yīng)該是UI元素Transform信息變化后進(jìn)行同步，但實(shí)際項(xiàng)目中測下來發(fā)現(xiàn)調(diào)用次數(shù)遠(yuǎn)比預(yù)期的要高，所以這個東西實(shí)際的機(jī)制到底是什么？

A：在Unity 2021和2022的較新穩(wěn)定版本上都做了實(shí)驗(yàn)，發(fā)現(xiàn)有以下幾種情況：

1. 任何UI元素Transform信息變化（如位移、旋轉(zhuǎn)、拉伸，例如飄字這類Ul動畫）都會導(dǎo)致自身觸發(fā)一次CanvasRenderer.SyncTransform。若同時發(fā)生Transform信息變化的UI元素多，則顯然會導(dǎo)致調(diào)用次數(shù)高，比如像我們項(xiàng)目場景中玩家和野怪單位的大量HUD元素會隨著玩家視角變化頻繁位移。

2. 調(diào)用SetActive(True)激活UI元素時，會使當(dāng)前Canvas下和其父Canvas下所有UI元素都觸發(fā)CanvasRenderer.SyncTransform。特別地，調(diào)用SetActive(False)隱藏UI元素時，不會觸發(fā)。

3. Instantiate實(shí)例化UI元素時，會使當(dāng)前Canvas下和其父Canvas下所有UI元素都觸發(fā)CanvasRenderer.SyncTransform。

4. Destroy銷毀UI元素時，會僅使當(dāng)前Canvas下所有UI元素都觸發(fā)CanvasRenderer.SyncTransform。

PS：以上API未實(shí)際生效時（如對一個已經(jīng)被激活的對象調(diào)用SetActive(True)），則不會觸發(fā)CanvasRenderer.SyncTransform。

所以定位到問題后，優(yōu)化手段上還是UI這塊老生常談的解放方案：即對1這種情況主要考慮控制更新頻率；對其他情況則是關(guān)注Canvas的層級設(shè)計，做好動靜分離。

該回答由UWA提供，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/67bbeb12682c7e5cd61bfa06

Q4：如何讓GameObject銷毀時無論是否Active過，都調(diào)用OnDestroy

請教一個問題，MonoBehaviour的OnDestroy方法，如果這個GameObject的實(shí)例化時就是隱藏的，銷毀時不會調(diào)用OnDestroy方法。我們項(xiàng)目有些核心邏輯是基于這個OnDestroy做的（時間太久遠(yuǎn)，耦合太多邏輯不好改出去了）。有沒有什么辦法，可以讓這個GameObject銷毀時無論是否Active過，都調(diào)用OnDestroy。

A：要觸發(fā)OnDestroy，必須要觸發(fā)過Awake（Awake可以不明著寫出來），通常是被實(shí)例化或者第一次激活的時候觸發(fā)Awake，如果一直處于不激活的狀態(tài)，那么銷毀的時候不會自動觸發(fā)OnDestroy。所以可以在激活的父節(jié)點(diǎn)上主動SetActive一下：

感謝旋@UWA問答社區(qū)提供了回答

A2：1. 一般一個Prefab本身是點(diǎn)亮的，大部分是里面的某些節(jié)點(diǎn)才會隱藏。如果是我說的這種情況，應(yīng)該是在根Prefab摧毀的時候主動調(diào)用一次需要控制調(diào)用的子組件。

2. 如果你真的是根Prefab就隱藏的那更簡單了：

（1）做一個工具掃描所有Prefab檢查并且修改點(diǎn)亮情況；

（2）編輯器模式下加載完一個Prefab之后檢查是否點(diǎn)亮，如果沒有則打印Error。

感謝沈杰@UWA問答社區(qū)提供了回答

A3：我們也遇到了這個，主要導(dǎo)致的問題自定義組件清理不掉Lua注冊過來的回調(diào)，導(dǎo)致返回登錄報錯。

我這邊解決思路是：在腳本反序列化之后，將自己注冊到UI根節(jié)點(diǎn)的管理腳本上，由這個管理腳本在Destroy時清理下面的子節(jié)點(diǎn)。

Base腳本如下圖：

有幾個要點(diǎn)說明下：

1. 我們只處理了UI（其他地方基本不會出這問題），項(xiàng)目的用法上每個UI根節(jié)點(diǎn)有必掛的組件，這個組件一定會執(zhí)行Awake。

2. 如果組件自身Awake走到了，就不需要額外的銷毀管理，需要從管理器中將自己移除。

3. 反序列化接口中有一堆限制，要小心處理，比如常用的接口只能在主線程執(zhí)行，如果在子線程要跳過。還有Prefab打開的編輯狀態(tài)也有一些狀態(tài)取不到，我這邊直接暴力忽略了（因?yàn)椴怀Ｓ茫?/p>

感謝Walker@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/67d390183d306f3e9d594e7a

Q5：FairyGUI圖標(biāo)文字合批失敗的原因

項(xiàng)目現(xiàn)在使用的是FairyGUI，界面中會有一排類似下圖的比較常見的組合按鈕（圖+特效+文字）。

在FrameDebugger中注意到這部分的DrawCall情況有點(diǎn)慘；老項(xiàng)目用UGUI+TMP作類似的UI應(yīng)該是沒有問題都能合的。父節(jié)點(diǎn)FairyBatching是勾了的，圖集是合好了的，圖和圖、文字和文字之間應(yīng)該也沒有互相遮擋覆蓋；考慮到可能是特效穿插的問題，所以運(yùn)行調(diào)試時直接把特效的節(jié)點(diǎn)刪掉了，還是不行。請問還有什么思路？

A：遇到過類似的問題。首先FairyGUI的結(jié)構(gòu)在導(dǎo)出后應(yīng)該就是固定的了，有可能你運(yùn)行時做了修改刪掉改掉某些東西，但原來的區(qū)域規(guī)格和UI元素仍然占位。所以這里刪特效、對TextField覆蓋面積的調(diào)試檢查，可能都得請UI同學(xué)幫忙，回到FairyGUI編輯器階段處理和檢查，再重新導(dǎo)出看效果。

操作了下，確實(shí)有變化。但現(xiàn)在又有兩個新問題：

1. 確實(shí)導(dǎo)出前就把特效移除有效果，但圖和文字中夾著特效是表現(xiàn)需要，最終不大可能刪，這個是不是就沒什么辦法了？

2. 就算移除了特效，還是發(fā)現(xiàn)只有圖和圖之間合了，文字之間仍然不合。而且這次是確認(rèn)了TextField之間也沒有重疊。這時候看FrameDebugger合批失敗原因變成了超過300個頂點(diǎn)不能動態(tài)合批。請問這個怎么解決呢？

A： 第一個確實(shí)想不到什么辦法了。第二個就像FrameDebugger寫的一樣，你若是用了Shadow、Outline這種效果，文字的頂點(diǎn)就會成倍上升，再加上你字一多，就會超了。不過如果你這些表現(xiàn)上都要用的話，也和特效一樣沒什么辦法了。

感謝Faust@UWA問答社區(qū)提供了回答

A2： 這個看上去很像是文字和背景圖的區(qū)域相交導(dǎo)致的。之前有遇到過類似的問題，F(xiàn)airyGUI排序節(jié)點(diǎn)渲染順序用于動態(tài)合批的邏輯里，完全不相交、完全包含，這種情況沒問題，但是如果關(guān)系是相交的話，可能會阻止節(jié)點(diǎn)的排序。

感謝SunHowe@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/67fcc756682c7e5cd61bfa57

Q6：粒子系統(tǒng)開啟Noise模塊在移動端的消耗如何

粒子系統(tǒng)開啟Noise模塊后在移動端的消耗如何，有什么使用建議嗎？

A：我在OPPO R17測了下，場景里播100個粒子系統(tǒng)*50粒子，前后分別設(shè)置為關(guān)閉Noise模塊、開啟Low/Medium/High Quality的Noise模塊，得到的粒子系統(tǒng)耗時變化如圖：

開啟Noise模塊后會使粒子系統(tǒng)耗時升高，主要開銷來自ParticleSystem.NoiseJob：

這么來看在移動端上的開銷還是比較可觀的，需要酌情使用。

使用時需要注意：

1. Octaves盡量低；

2. Quality盡量設(shè)置為Low；

3. 對粒子系統(tǒng)拆分，例如只對小部分設(shè)置較重的Noise，大部分使用較輕的Noise或者不開啟，等等。

感謝Faust@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/6805b4613d306f3e9d594ec8

Q7：如何用GPU Instancing來優(yōu)化樹木草石重復(fù)模型

項(xiàng)目場景里的樹木草石重復(fù)模型非常多，在嘗試用GPU Instancing來優(yōu)化。使用的Shader應(yīng)該是SRP Batcher和GPU Instancing都支持的，但是材質(zhì)勾上GPU Instancing后看FrameDebugger里還是走的SRP Batcher，要怎么修改比較好呢？

A：如果 Shader兩個都兼容，就會優(yōu)先走SRP Batcher的。常規(guī)做法就是把規(guī)劃要用GPU Instancing的物體用別的不走SRP Batcher的Shader；也可以考慮仍然用兩個都兼容的Shader，但是用MaterialPropertyBlock打斷SRP Batcher，這樣就會順延走GPU Instancing了。

感謝Faust@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/680dd4d53d306f3e9d594ecc

Q8：URP相機(jī)如何將場景渲染定幀模糊繪制

URP有沒有什么方法能控制攝像機(jī)的渲染？比如現(xiàn)在有個功能是，載入副本后，馬上BOSS和場景的渲染定幀，然后模糊處理。在這期間基本是只渲染這個“UI效果”。場景暫時不渲染以實(shí)現(xiàn)優(yōu)化。 如果完全實(shí)時的話，那么每幀都要渲染這種覆蓋全屏的大面片特效，和高斯模糊計算背景。

A： 可以寫一個CopyColor的Pass，將3D場景的內(nèi)容渲染完后，用這個拷貝的Pass將內(nèi)容保存下來，只拷貝一幀，然后將這個Pass Disable掉，再將3D渲染相機(jī)的CullingMask改為Nothing， 這個CopyColor的Pass里面的RT的內(nèi)容可以用來做UI模糊處理。

感謝Faust@UWA問答社區(qū)提供了回答，歡迎大家轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/68219ad6682c7e5cd61bfa65

Q9：為什么場景中沒有剛體更無碰撞事件但仍有較高物理耗時

為什么GOT性能報告和Profiler里看物理模塊耗時都很高？但其實(shí)這時候場景里已經(jīng)沒有剛體了，按理說不會發(fā)生碰撞，只有在代碼里用了Raycast判斷子彈命中，后來我把設(shè)置里的物理模擬關(guān)掉，又打了包，物理耗時確實(shí)降了下來，看子彈還是能正常命中（因?yàn)槭谴a調(diào)的），看粒子里的碰撞也還是能生效。

我不明白的是：之前那么高的物理耗時是在做什么？可能是什么導(dǎo)致的？是有一些我沒留意到的地方用了物理導(dǎo)致的，還是說Unity機(jī)制如此？（Unity版本2022.3.59）

A：的確， 當(dāng)前Unity版本的機(jī)制就是這樣，很多時候必須要關(guān)閉掉物理模擬（指把Simulation Mode改成Script）才可以節(jié)省耗時。具體機(jī)制是場景中只要Static Collider數(shù)量大于0且沒有關(guān)閉物理模擬就會有耗時，和場景中有沒有剛體、有沒有發(fā)生碰撞事件無直接關(guān)聯(lián)。

針對以上問題，有經(jīng)驗(yàn)的朋友歡迎轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/684688ea682c7e5cd61bfaa0

Q10：為什么使用發(fā)射Mesh的粒子系統(tǒng)會使Graphics內(nèi)存暴漲

之前在UWA的分享里看到使用發(fā)射Mesh的粒子系統(tǒng)就會導(dǎo)致Memory Profiler-Graphics- 內(nèi)存類型暴漲問題。我們項(xiàng)目美術(shù)同學(xué)也想用這種粒子，所以得評估一下這個問題（Unity 2022.3.27）。

A：自問自答一下，實(shí)際測下來好多開關(guān)和方法都沒什么用，限制這部分內(nèi)存的只有發(fā)射Mesh的粒子系統(tǒng)組件數(shù)量、發(fā)射粒子的數(shù)量（通過Max Particle限制）和發(fā)射的Mesh的面數(shù)。

這么一看要么把這些因素控制到很低、要么還是索性不要用了，因?yàn)樯蠞q的內(nèi)存比Particle數(shù)量乘以每個Mesh的內(nèi)存還要大一些，太容易一下就占好幾十MB了。

另外要卸載這些內(nèi)存還沒法通過定向接口來做，非得調(diào)用RUUA。總之目前是不大敢用了，看后續(xù)有沒有修掉這個bug的Unity版本了。

針對以上問題，有經(jīng)驗(yàn)的朋友歡迎轉(zhuǎn)至社區(qū)交流：

https://answer.uwa4d.com/question/6858e8713d306f3e9d594eff

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

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

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

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

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

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

近期精彩回顧

【學(xué)堂上新】

【厚積薄發(fā)】

【學(xué)堂上新】

【厚積薄發(fā)】