UWA每周推送的知識(shí)型欄目《厚積薄發(fā) | 技術(shù)分享》已經(jīng)伴隨大家走過了419個(gè)工作周。 精選了2024年十大精彩問答分享給大家，期待2025年UWA問答繼續(xù)有您的陪伴。

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

Q1：PuerTS和HybridCLR哪個(gè)更適合開發(fā)微信小游戲

PuerTS和HybridCLR哪個(gè)更適合開發(fā)微信小游戲？哪個(gè)更快？大家有做過相關(guān)的調(diào)研嗎？

A1：之前測過，HybridCLR的解釋器是在WASM上的，而JS用的是微信的。這倆算力估計(jì)差了50多倍。但現(xiàn)在市面好像沒有好的Unity和TS的框架。

JS算力高，但和WASM交互比HybridCLR低幾倍。

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

A2：可以參考以下文章，但綜合來看應(yīng)該還是HybridCLR更好一些：

https://zhuanlan.zhihu.com/p/646932579

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

https://answer.uwa4d.com/question/66a70d55682c7e5cd61bf888

Q2：如何解決穿插易導(dǎo)致半透明物體合批失敗

請(qǐng)問半透明Shader，距離穿插，打斷SRPBatcher。有什么通用解法？比如一個(gè)火焰特效，用了ab2個(gè)粒子，分別2個(gè)Shader，那么10個(gè)火焰就是ab ab ab......這樣20個(gè)DrawCall嗎？但完全無法合批。

由于半透明開銷比較大。而且需要渲染順序嚴(yán)格導(dǎo)致了一些優(yōu)化失效。大家有什么好的解法嗎？

A1：不透明可以調(diào)RenderQueue，半透明不好調(diào)，可能會(huì)影響渲染結(jié)果。

感謝AQ（Richard Pan）@UWA問答社區(qū)提供了回答

那比如玩家丟出的燃燒瓶，多少米合并成一個(gè)？如果很遠(yuǎn)，半透明物體在火堆之間就出錯(cuò)明顯。我之前是3米合成一次順序，提升不明顯。

A2：我是直接不同材質(zhì)用不同隊(duì)列，犧牲了一些順序正確性，主要用在團(tuán)戰(zhàn)時(shí)候大量技能特效上，本身畫面很亂，順序錯(cuò)誤感受不出來，至于場景中的常駐特效，還是要保證順序正確性，不去調(diào)隊(duì)列。

對(duì)應(yīng)性能好的機(jī)器保證正確性，性能差點(diǎn)的保證性能，忽略點(diǎn)正確性。

感謝AQ（Richard Pan）@UWA問答社區(qū)提供了回答

A3：一個(gè)燃燒瓶丟出來8份火焰實(shí)例，每個(gè)實(shí)例3個(gè)粒子發(fā)射器且Shader不同，導(dǎo)致一堆開銷。嘗試燃燒瓶互相順序不嚴(yán)謹(jǐn)，內(nèi)部定死順序看看。

感謝偶爾不帥@UWA問答社區(qū)提供了回答

強(qiáng)制改變渲染順序粒子是改下圖這里好：

還是材質(zhì)的Queue好：

A4：我是改材質(zhì)的Queue。

感謝AQ（Richard Pan）@UWA問答社區(qū)提供了回答

A5：半透明大部分情況是放棄跨發(fā)射器的合批優(yōu)化。整理了以下幾種辦法供參考，一種辦法就是將兩個(gè)材質(zhì)合并為一個(gè)，這樣就連上了；另外就是在Batch的時(shí)候判斷屏幕Bounds，不重疊的時(shí)候進(jìn)行批次合并；還有種辦法是粒子實(shí)時(shí)Batch成序列幀后使用，遠(yuǎn)處的粒子可以這樣處理，這樣這些粒子都可以一個(gè)批次畫完，畢竟遠(yuǎn)處不管是大小還是幀率都很低，這樣做反而可能是合算的。

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

https://answer.uwa4d.com/question/675673e5682c7e5cd61bf9bf

Q3：Unity引擎關(guān)于APP后臺(tái)下載支持的實(shí)現(xiàn)問題

最近很多游戲在Loading界面會(huì)標(biāo)明支持后臺(tái)下載模式，項(xiàng)目也計(jì)劃實(shí)現(xiàn)一個(gè)，首先找到了Unity自帶的BackgroundDownload解決方案，功能是可以的，也好接入，但項(xiàng)目中的文件數(shù)量比較多，有大幾萬個(gè)，同時(shí)建立這么多鏈接非常卡頓，經(jīng)過簡易優(yōu)化，速度提升了一些，同時(shí)平滑建立連接數(shù)不再那么卡頓，但所有連接建立完還是需要很長時(shí)間，同時(shí)Android環(huán)境在創(chuàng)建1000+個(gè)下載服務(wù)時(shí)，會(huì)崩潰，沒有明確的報(bào)錯(cuò)，每次會(huì)有下圖中的異常！

BackgroundDownload

https://github.com/Unity-Technologies/BackgroundDownload

咨詢下各位大佬，如下幾個(gè)問題：

1. 崩潰如何處理？

2. 如何平滑快速地建立起下載連接？

3. 有沒有其他更好的處理類似問題的解決方案？

A1：可以試試以下方案：

方案1：把所有要下載的任務(wù)，放到1個(gè)隊(duì)列，開多個(gè)線程去處理這個(gè)隊(duì)列的下載任務(wù)，并且限制設(shè)定同時(shí)下載的任務(wù)數(shù)。

方案2：把對(duì)應(yīng)資源，根據(jù)一些規(guī)則（如：等級(jí)1-10級(jí)會(huì)用到的資源在1個(gè)zip包，11-20級(jí)會(huì)用到的資源放在1個(gè)zip包），然后根據(jù)一些條件在不同時(shí)刻來下載不同的zip包。

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

A2：目前匯總下Android端的解決方案，幫助大家踩坑：

1. Unity內(nèi)部使用后臺(tái)運(yùn)行的線程來平滑控制下載量，存在的問題：APP切入后臺(tái)時(shí)，線程會(huì)被掛起，中斷傳輸；

2. 將下載任務(wù)全部篩入原生層，使用Android的Service調(diào)起，同線程也是會(huì)被掛起；

3. 將下載任務(wù)全部篩入原生層，使用Android的Schedule等定期任務(wù)，存在的問題：觸發(fā)時(shí)間不固定，時(shí)間選擇范圍大，但系統(tǒng)會(huì)設(shè)置最小調(diào)用間隔為15分鐘，沒法用；

4. 將下載任務(wù)全部篩入原生層，使用Android的前臺(tái)Service中起一個(gè)線程，逐步傳遞給下載服務(wù)，存在的問題：目前可以持續(xù)運(yùn)行，但會(huì)受到系統(tǒng)的限制，服務(wù)起的線程觸發(fā)時(shí)間會(huì)時(shí)快時(shí)慢，執(zhí)行一段時(shí)間后有概率會(huì)掛起（沒有明顯的輸出，不明原因，就是長期不輸出日志了，服務(wù)都還在）。

用服務(wù)搞定后發(fā)現(xiàn)Android的原生下載服務(wù)速度很慢，所以再次測試了Unity中使用C#的Thread的方案（線程設(shè)置為inbackround=true，使用HttpClient下載），發(fā)現(xiàn)是可以后臺(tái)運(yùn)行且速度可以，之前測試不清楚為什么不行，可能是哪里遺漏了。

另外補(bǔ)充幾點(diǎn)：

• 如果后臺(tái)不運(yùn)行了，可以在手機(jī)的電池管理處，勾選允許你的APP在后臺(tái)運(yùn)行選項(xiàng)；

• Android是可以申請(qǐng)忽略電池優(yōu)化權(quán)限的；

• 但Google對(duì)這個(gè)權(quán)限有很多限制。

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

A3：由于國內(nèi)Android系統(tǒng)的各種定制化，使用BackgroundDownload方案會(huì)在某些機(jī)型上無法下載，并且無法解決。

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

A4：開個(gè)線程驅(qū)動(dòng)下載隊(duì)列，http下載，不要用UnityWebRequest。

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

https://answer.uwa4d.com/question/65e1c0b13625c22cffcb1e3d

Q4：使用SBP打AssetBundle腳本引用丟失

最近項(xiàng)目實(shí)驗(yàn)升級(jí)ScriptableBuildPipeline打包AssetBundle（之前使用的是BuildIn構(gòu)建管線）。使用的Unity為2022.3，SBP版本為2.1.4。

結(jié)果發(fā)現(xiàn)打出的UI AssetBundle中，部分NGUI的腳本丟失引用了，丟的最多的是UIButton。但也不是所有UI都會(huì)丟失，有的就正常。BuildIn管線打包也正常。

真機(jī)上加載資源的時(shí)候會(huì)報(bào)錯(cuò)：

Error: A scripted object (script unknown or not yet loaded) has a different serialization layout when loading. (Read 32 bytes but expected 8136 bytes)

Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?

UnityEngine.AssetBundle:LoadAsset(String)

使用AssetStudio解包AssetBundle，發(fā)現(xiàn)腳本的m_PathId為0。求助，這可能是哪的問題？

A1：針對(duì)出問題的文件單獨(dú)導(dǎo)出獨(dú)立工程Demo去調(diào)試。

發(fā)現(xiàn)出問題的情況是AssetBundle的引用的引用也包含了相同的腳步且這個(gè)引用也是打AssetBundle的， 應(yīng)該是遞歸引用的時(shí)候出問題了。

解決方案：

1. 設(shè)置SBP中BuildParameters的NonRecursiveDependencies為false。

修改方法：

a. 將Library\PackageCache夾子下SBP的組件移動(dòng)到Packages下變?yōu)楸镜亟M件，即可編輯代碼。

b. 使用SBP非兼容模式接口構(gòu)建，New出BuildParameters，然后可修改此屬性。

2. 將腳本信息都寫入到一個(gè)獨(dú)立的Bundle中，這樣所有Bundle都引用它即可，這種方式需要啟用CreateMonoScriptBundle。

修改方法：

在SBP組件中的DefaultBuildTasks腳本Create接口內(nèi)Return出AssetBundleCompatible(false, true);即可。

感謝題主mr.Tian@UWA問答社區(qū)提供了回答

A2：感謝樓主的回答，我們項(xiàng)目用的Addressable，當(dāng)A預(yù)設(shè)（A單獨(dú)打包）引用公共預(yù)設(shè)B的時(shí)候，會(huì)出現(xiàn)部分腳本和Image組件丟失的情況，查看AssetBundle的信息發(fā)現(xiàn)丟失了腳本的相關(guān)信息，采用樓主的建議，把NonRecursiveDependencies設(shè)為false就解決了。

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

https://answer.uwa4d.com/question/66babdd6682c7e5cd61bf8ae

Q5：升級(jí)Unity后產(chǎn)生的Objects內(nèi)存泄露現(xiàn)象

項(xiàng)目升到2022.3.28后觀察到在真機(jī)上出現(xiàn)了之前沒有的內(nèi)存泄漏狀況，用Memory Profiler排查后發(fā)現(xiàn)除了一些正常的資源和堆內(nèi)存有輕微上升外，主要是有一部分Native-UnitySubsystemsObjects- 泄露很明顯，但沒法定位。請(qǐng)問有沒有人遇到這個(gè)問題？怎么解決？

A1：可以參考下這篇官方論壇討論和復(fù)現(xiàn)測試鏈接：

https://discussions.unity.com/t/memory-leak-in-scriptableobject-containingserializereference-in-android-environment/946666

https://issuetracker.unity3d.com/issues/memory-leak-when-using-serializereference-in-il2cpp-build

根據(jù)我們項(xiàng)目中的情況加上自己試驗(yàn)了下，發(fā)現(xiàn)觸發(fā)條件比帖子中還要簡單，都不用ScriptableObject+Addressable，只要任意帶有[SerializableReference]特性的資源被銷毀就會(huì)發(fā)生泄漏。而且看樣子這個(gè)問題大概率會(huì)出現(xiàn)在所有2022以上及團(tuán)結(jié)引擎的項(xiàng)目中，且目前未被修復(fù)。

考慮到使用這些Unity版本一般是基于支持鴻蒙或支持小游戲的主要目的，不大可能回退版本，那么目前處理方法可能就是要盡量避免使用這個(gè)特性。甚至像DoTween這種可能涉及該特性的插件建議都要換掉。

該問答由UWA提供

A2：Unity已經(jīng)修復(fù)了該問題。遇到該問題的可以通過升級(jí)引擎到最新版本解決。

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

A3：Unity 2022.3.34版本修復(fù)，團(tuán)結(jié)1.3.1版本修復(fù)。

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

https://answer.uwa4d.com/question/670c8262682c7e5cd61bf95c

Q6：Unity中如何實(shí)現(xiàn)草的LOD

Unity自帶的Terrain中草作為Detail，無法設(shè)置LOD Group。感覺草的LOD應(yīng)該是一個(gè)非常基礎(chǔ)的功能，Unity選擇不支持這個(gè)功能的原因是什么？要想實(shí)現(xiàn)草的LOD，我想到的幾種方式，還有更好的實(shí)現(xiàn)方式么？

1. 手動(dòng)放置。

2. 自己寫Procedural工具批量生成。

3. 使用Terrain的Paint Trees功能變通實(shí)現(xiàn)。即把草當(dāng)作一種Tree，增大種植密度。不知道這種實(shí)現(xiàn)會(huì)不會(huì)有副作用。

A1：LOD一般不用于草，通常大批量的草都是使用GPU Instance。如果距離遠(yuǎn)的草，你可以通過邏輯控制遠(yuǎn)距離草的顯示和隱藏。

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

A2：草通常是小型和密集的，對(duì)于這些對(duì)象應(yīng)用LOD機(jī)制可能并不會(huì)顯著提高性能。草地的渲染通常依賴于地形的著色器和草地批處理，因此Unity可能認(rèn)為不需要為這些小對(duì)象單獨(dú)設(shè)置LOD。

如果要快速解決問題，可以看看Unity Store中的Infini GRASS GPU Vegetation。

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

https://answer.uwa4d.com/question/65fe527f5c7f5d2c5805d354

Q7：開發(fā)微信小程序游戲，有沒有類似

Debug真機(jī)圖形的方法

開發(fā)微信小程序游戲有什么科學(xué)的Debug真機(jī)圖形的方法嗎？比如RenderDoc？

A1：推薦Frame Debugger，團(tuán)結(jié)可用。

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

A2：1. 游戲可以在瀏覽器跑的話，可以用SpectorJS（ https://github.com/BabylonJS/Spector.js/ ）。

2. RenderDoc曾經(jīng)也可以抓Chrome，但后來官方禁了，可能需要自己魔改編譯一個(gè)RenderDoc。

3. 也可以用MuMu模擬器+RenderDoc抓微信，MuMu需要開啟Vulkan模式，RenderDoc開全局Hook，Attach到MuMu的進(jìn)程上，但是抓到的是Vulkan的API。

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

A3：RenderDoc可以考慮，但需要舊版本的RenderDoc。或者配合模擬器截幀，或者Root的手機(jī)都可以，或者用瀏覽器都行，方式很多，個(gè)人推薦模擬器+截幀。

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

https://answer.uwa4d.com/question/677250003d306f3e9d594de3

Q8：MemoryProfiler中Graphics/No Name

內(nèi)存怎么排查

移動(dòng)端項(xiàng)目，發(fā)現(xiàn)某個(gè)場景里內(nèi)存上升很快、但切場景又能回落回去。在Memory Profiler里看發(fā)現(xiàn)是Graphics下面的 ，怎么排查？Unity版本是2022.3.37。

A：這個(gè)我們之前也遇到過，可以看下這個(gè)場景是不是用了發(fā)射Mesh的粒子？應(yīng)該是臨時(shí)生成的網(wǎng)格都造成了內(nèi)存占用，雖然沒有引用，但要在下次場景切換RUUA的時(shí)候才自動(dòng)卸載。

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

https://answer.uwa4d.com/question/673af015682c7e5cd61bf994

Q9：移動(dòng)平臺(tái)紋理壓縮格式選擇ASTC，

美術(shù)出圖還需遵守POT嗎

移動(dòng)平臺(tái)紋理壓縮格式選擇ASTC，美術(shù)出圖大小還有要求嗎？

1. 美術(shù)出圖還需要遵守POT（2的冪次方）嗎？

2. 如果使用NPOT（非2的冪次方），性能方面有多大影響？

A1：如果是作用于3D場景中物體的貼圖而需要開啟Mipmap的紋理，則仍需要滿足POT。否則，ASTC+Mipmap+NPOT，仍然會(huì)導(dǎo)致紋理在真機(jī)上被解析為RGBA32未壓縮格式；以ASTC4*4為例，變?yōu)镽GBA32則內(nèi)存占用變?yōu)樗谋叮蚁鄳?yīng)的包體大小、加載耗時(shí)、帶寬開銷等其他內(nèi)存開銷也都會(huì)顯著上升。

如果不需要開啟Mipmap的呢，性能方面有影響嗎？

A2：3D場景物體貼圖（模型甚至特效和Spine等只要和相機(jī)有距離變化或者縱深的物體）理論上開啟Mipmap都有利于降低帶寬開銷；若確實(shí)不需要開啟Mipmap的紋理（如UI元素用到的紋理），關(guān)閉Mipmap后使用NPOT分辨率理論上對(duì)性能不會(huì)有什么影響。

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

https://answer.uwa4d.com/question/672edc1f3d306f3e9d594d88

Q10：Application.lowMemory在什么時(shí)候會(huì)生效

Application.lowMemory這個(gè)方法大家有測過嗎？如何生效？

A1：由于Application.lowMemory僅在內(nèi)存極其緊張時(shí)觸發(fā)，因此不應(yīng)該過度依賴這個(gè)回調(diào)來管理內(nèi)存，尤其可能比較常見但其實(shí)有問題的、在回調(diào)中調(diào)用RUUA回收Unused資源的做法，不但降低內(nèi)存的效果有限還會(huì)觸發(fā)卡頓。正確的做法是通過優(yōu)化資源管理、減少不必要的內(nèi)存占用等方式來預(yù)防內(nèi)存問題；或調(diào)用Resources.UnloadAssets或AB.Unload(True)的方式定向卸載內(nèi)存。

該問答由UWA提供

A2：Application.lowMemory說明如圖：

iOS系統(tǒng)，比如普通4G設(shè)備，閃退內(nèi)存也大概為2G左右，通過Xcode可以看到一個(gè)紅線，到了紅線即觸發(fā)閃退，在2G前的一定內(nèi)存回收到lowMemory，下圖的藍(lán)色驟降的地方就是收到lowMemory釋放內(nèi)存，可以作為內(nèi)存釋放的保底方案，只要不是突然申請(qǐng)比較大的內(nèi)存應(yīng)該都可以（像最右端的就是突然一大塊內(nèi)存達(dá)到了Limit直接閃退）。

Android的觸發(fā)時(shí)機(jī)就有點(diǎn)不確定了，這是官方文檔：

https://developer.android.com/reference/android/app/Application.html#onLowMemory%28%29

上圖說的是系統(tǒng)內(nèi)存不足會(huì)觸發(fā)，通常是在所有后臺(tái)進(jìn)程被殺死時(shí)候（但是也說了沒有明確的觸發(fā)時(shí)機(jī)，只是通常是所有后臺(tái)進(jìn)程被殺死）。

但是測試下來發(fā)現(xiàn)，后臺(tái)APP被殺的時(shí)候是能收到lowMemory的，但是可能根據(jù)不同廠商，可能不是所有后臺(tái)APP都被殺之后才收到lowMemory。

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

https://answer.uwa4d.com/question/66f8cd1a682c7e5cd61bf8e6

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

今天的分享就到這里。生有涯而知無涯，在漫漫的開發(fā)周期中，我們遇到的問題只是冰山一角，UWA社區(qū)愿伴你同行，一起探索分享。歡迎更多的開發(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)化不迷路～

近期精彩回顧