1）DrawInstance和徹底不作合批狀況下的性能差別
2）UWA報告中檢測出工程沒有的資源
3）精靈設置九宮後，如何不在界面中顯示出來
4）關於AssetBundle資源的卸載問題
5）Total Mono忽然上漲的緣由html
這是第236篇UWA技術知識分享的推送。今天咱們繼續爲你們精選了若干和開發、優化相關的問題，建議閱讀時間10分鐘，認真讀完必有收穫。數組
UWA 問答社區：answer.uwa4d.com
UWA QQ羣2：793972859（原羣已滿員）網絡
Rendering
Q：我作了個測試，環境：Unity 2019.4.15 ，機型：小米5X，繪製1000個物體（頂點數>300，不動態合批），測試順序是：Unity默認渲染（20 FPS）–>Update中經過Graphics.DrawInstance（16.5 FPS）–>經過CommandBuffer實現的DrawInstance（21.5 FPS），對於第二個測試DrawInstance性能反而下降了不太理解，有大佬幫忙解答嗎？性能
圖片和測試工程可經過原問答下載。測試
A：1.Instancing耗時更高主要緣由仍是GPU壓力比較大，見下面的測試案例：優化
測試1：1000個物體（頂點數88，關閉動態合批）網站
Default：子線程Camera.Render（14.59 ms）、Gfx.PresentFrame（3.94 ms）url
Instancing：子線程Camera.Render（7.1 ms）、Gfx.PresentFrame（4.70 ms）spa
測試2：1000個物體（頂點數1278）.net
Default：子線程Camera.Render（15.02 ms）、Gfx.PresentFrame（9.01 ms）
Instancing：子線程Camera.Render（8.21 ms）、Gfx.PresentFrame（19.15 ms）
Instancing是可以明顯下降CPU渲染（Camera.Render）耗時的，但GPU調用DrawInstanced()比Draw()的性能彷佛差一些，致使CPU端等待耗時較高。因此Instancing整體幀率有所降低主要是GPU的壓力較大致使的。
2.以下圖Graphics.DrawMeshInstanced在Update中每幀調用存在腳本耗時明顯DrawInstancing更高（在Update中準備相關DrawInstance參數），Demo渲染的是靜態物體，使用CommandBuffer實現DrawInstancing可優化這部分耗時，同時在Update中的邏輯也會有New XXX[]數組這樣的Mono堆內存頻繁的分配，也會有GC影響（這部分影響較小）。
結論：Instancing能夠下降CPU渲染耗時，但GPU API性能會有所下降，幀耗時仍是受到CPU渲染耗時及GPU耗時的綜合影響，不一樣的機型可能表現的會有所差別。
Instancing的使用：推薦繪製大量靜態物體時使用CommandBuffer的實現，例如草海之類的。
感謝羽飛@UWA問答社區提供了回答
Texture
Q：請問一下：性能報告中，RGBA32的圖片有一些在工程中沒有，可是在報告中卻體現，請教一下這些是哪裏產生的？
A：截圖中的Background、UIMask、UISprite是由UGUI中默認的UI元素引入的，以下圖中的ScrollView：
UnityNormalMap這個是因爲Shader中的紋理使用Bump做爲默認的值，可是在材質球中又沒有給這個紋理賦值致使的。對於這種空紋理的資源，在UWA本地資源檢測中是能夠檢測出來的。
感謝Xuan@UWA問答社區提供了回答
UGUI
Q：導入一張171*41的圖片，設置完九宮信息後建立UI圖片。而後設置圖片寬高爲0，並設置圖片模式爲Sliced。可是仍是能看到圖片顯示出來了。我的感受上是UV計算錯誤了。若是切換到Simple則圖片正常不顯示。請問大佬這是什麼原理？
測試工程可在原問答下載（版本：Unity 2018.4.23）
A：這個和九宮格圖片的實現原理有關，能夠看看下面這個圖片：
當你選擇Sliced模式，他有一個最小的繪製區域，也就是四個角：一、三、7和9，必須繪製出來。當你設置的Rect大於一、三、七、9四個角組成的區域時，那麼2和8則是在x方向進行縮放，y方向不變，而4和6則是在y方向縮放，x方向不變；而5則是x和y方向都會進行縮放。當你選擇Simple模式，則是根據你設置的Rect範圍決定的，若是Rect比原始尺寸大，那麼就拉伸，反之則縮小；這也就是你能夠不顯示的緣由。
感謝李星@UWA問答社區提供了回答
AssetBundle
Q1：公共資源public.ab作全局預加載，常駐內存。某特定資源A引用了public.ab裏的一張大圖紋理，以及另一個a.ab裏的資源。在沒加載A時，public.ab即便常駐內存也不會實際將那張大圖紋理實例化。
如今的問題是，當加載並用完A資源後，想把A完全從內存中清理出去時，對a.ab進行Unload(true)能夠把a.ab清理掉，可是public.ab裏的那張大圖，在不對public.ab進行Unload(true)的前提下，是沒有任何其它辦法能將它從內存中清掉嗎？
A1：若是能拿到那張Texture的引用，能夠嘗試使用Resources.UnloadAsset。
但我的認爲既然是公共資源，說明有可能被不少地方引用到，應作好public.ab裏面的資源都常駐內存的內存預算準備。不然，按照你例子中的說法，可能把這張大紋理單獨拿出來會好一些。
感謝範君@UWA問答社區提供了回答
Q2：因爲該大圖紋理被多個UI預置體引用，所以放到了public.ab裏，但這些UI預置體，在遊戲大部分時間（好比掛機戰鬥時）不會打開，所以也是不須要用到的，故而想卸載。看來仍是隻能再拆分出一類不常駐內存的公共資源，來解決這類問題了？
A2：既然要做爲公共資源，常駐內存，那麼就是從App的開始到App的結束都是不會去卸載的。若是你想原來在公共資源裏的小圖只有特定場景下才會使用到，平時不用時想卸載，能夠參考下這個運行時動態圖集，動態將小圖合併到常駐內存的圖集中，不用時在動態剔除回收。
感謝Coyote@UWA問答社區提供了回答
Mono
Q：現象：在Total Mono忽然撐大的那幾幀中，Used Mono並無上漲，如圖：
Used在50MB左右時，Total忽然分配到140MB，這是爲何？
A：頗有多是一幀中分配了大量的堆內存，將Total撐大了，但自己的堆內存是能夠GC掉的，因此Used並無太大的變化。
該問答由UWA提供
封面圖來自網絡
今天的分享就到這裏。固然，生有涯而知無涯。在漫漫的開發週期中，您看到的這些問題也許都只是冰山一角，咱們早已在UWA問答網站上準備了更多的技術話題等你一塊兒來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之「石」，也能攻你之「玉」。
官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com 官方技術QQ羣：793972859（原羣已滿員）