Prefab 最佳化:預製體中的各種細節選擇

侑虎科技發表於2020-12-21

在上一期《Shader:優化破解變體的“影分身”之術》中,我們針對UWA本地資源檢測最新的Shader Analyzer功能所涉及到的新規則和相關知識點進行了講解。這些看似細小的知識點,很容易在大家的開發和學習過程中被疏忽,而長期的問題積累最終都會反映到專案的效能表現上。為此,我們將這些規則列出,並且以一個個知識點的形式向大家逐一解讀。

本期,我們將繼續講解UWA本地資源檢測中和Prefab相關的規則:“使用了Outline的Text元件”、“使用了預設紋理的RawImage元件”、“不可見的RawImage元件”、“開啟Prewarm的粒子系統”和“開啟Collision或Trigger的ParticleSystem”。我們將力圖以淺顯易懂的表達,讓職場萌新或優化萌新能夠深入理解。


1、使用了Outline的Text元件

Prefab 最佳化:預製體中的各種細節選擇

這裡有兩個概念需要和大家簡單說明下。首先是Text元件,它是UGUI系統下的一個可以用於文字顯示與編輯的控制元件。

Prefab 最佳化:預製體中的各種細節選擇

在Text控制元件中我們可以對文字內容進行多種設定,比如字型型別、字型大小和對齊方式等。

Prefab 最佳化:預製體中的各種細節選擇

然後是Outline元件。Outline元件和Shadow元件一般都用於對圖片或者文字新增陰影效果。而且從形式上看,這倆基本沒有區別。

Prefab 最佳化:預製體中的各種細節選擇

而從效果上來看如下圖,Outline用於新增輪廓效果 ,Shadow則是用於新增陰影效果;從效能上來看,Outline生成的網格Triangles會比Shadow多。

而且根據實際測試,如下圖是一段文字分別在“無陰影效果”、“開啟Shadow”和“開啟Outline”時的頂點數情況。由圖可知如果我們在Text元件中使用了Outline來實現輪廓效果,那麼頂點數和網格數的上升會非常明顯。

在這裡我們推薦大家嘗試使用TextMeshPro來實現相關的顯示效果,在效能和展示效果上都優於Outline和Shadow。

所以在本條規則找出使用Outline的Text元件後,開發團隊可視實際情況去選擇是否保留Outline,或者換用TextMeshPro;也可以讓美術人員直接做出美術字來使用,從根源上減少頂點數,降低效能開銷。

2、使用了預設紋理的RawImage元件

在之前《Prefab優化:向預製體打出最有效的組合拳》一文中,我們簡單說明了Image元件。Rawlmage元件和Image元件類似,都是UGUI系統下的影像元件。針對於Texutre設定的TextureType來說,Image元件只能使用TextureType為Sprite型別的資源;而RawImage使用的紋理資源可以設定為任意Type,需要注意的是,如果在RawImage元件內拖入的是TextureType為Sprite的紋理,其實是引用了Sprite內的原始紋理。從UGUI原始碼中看,RawImage型別的API函式很少,功能比較簡單,而Image型別的功能較複雜。

如果Rawlmage元件的Texture屬性沒有賦值,那麼會生成一張白色的預設紋理,這張白色的紋理存在效能開銷。雖然不排除直接使用預設紋理的情況,但大部分的應用場景下,我們都會為Rawlmage元件新增符合場景和介面需求的紋理來達到預期的顯示效果。

所以我們會找出這些使用預設紋理的Rawlmage元件,以供開發團隊進行進一步的判別,方便大家及早發現並修改這類紋理使用不當的問題。

3、不可見的RawImage元件

這一條和我們在之前的文章《Prefab優化:向預製體打出最有效的組合拳》講到的“不可見的lmage元件”非常相似。在大部分的應用情形下,“視覺上消失,但物理上存在”背離了作為影像元件的使用初衷。

當我們把Alpha值全為0(即透明不可見)的Texture資源匯入到相關RawImage元件後,這種情況下,Rawlmage影像元件不僅沒有為專案提供任何的展示效果,反而為專案帶來了效能和計算上的額外佔用與消耗。

當然,還是要強調一下,我們不能武斷地排除RawImage元件不視覺化的特殊應用,開發團隊要根據專案的實際需求來進一步判斷這些被本條規則篩選出的Rawlmage元件。

4、開啟Prewarm的粒子系統

在Unity的粒子系統應用中,我們經常會接觸到一個叫做“預熱”(Prewarm)的概念。我們可以在粒子系統的初始化皮膚內進行Prewarm的相關設定。

Prefab 最佳化:預製體中的各種細節選擇

開啟Prewarm選項後,粒子系統會在載入後立刻執行一個完整的粒子發射週期,一般用於特定的粒子效果的展示需求。

最典型的就是火焰特效的應用,在某些場景過場中,例如戰亂中一間燃燒的木屋。開啟Prewarm選項,我們就能直接看到熊熊燃燒的大火,而不是看一遍火焰從小燒到大的過程(不然這就違和得離譜)。

在一些粒子系統渲染規模較大的場景中,如果開啟Prewarm選項,會使得粒子系統在使用時的第一幀產生相對集中的CPU耗時,那麼很可能會造成執行時區域性卡頓,從而對整個專案的執行過程產生感官和體驗上的明顯影響。

所以本條規則會找出這些開啟Prewarm的粒子系統,開發團隊進行進一步的檢查後,根據實際使用需求去決定是否需要關閉相關的粒子預熱效果。

5、開啟Collision或Trigger的ParticleSystem

在Unity中,粒子系統一般用於各種渲染效果,不具備實物特性。但在某些具體的應用中,我們希望粒子具有現實中的物理性質來更好地表現想要的效果。

比如在某些二戰題材的軍事遊戲內,用粒子系統去表現M16防空車的彈幕射擊。為了更好地實現曳光彈、燃燒彈的射擊,碰撞和四散的效果,這時候就需要開啟粒子系統的物理碰撞。

Prefab 最佳化:預製體中的各種細節選擇

如圖,這是粒子系統中的Trigger(觸發器)和Collision(碰撞器)設定。簡單來講,合理使用這兩個設定,就能很好地模擬出粒子的實物碰撞效果。甚至可以實現比如子彈跳彈後的變軌,雨水滴到湖面後的反彈等現實的物理性質。

不過這些物理碰撞效果的實現是以高額的物理計算消耗為代價的。在實際使用中,大部分的粒子系統只是承擔了渲染的作用,並不涉及粒子與物體碰撞的效果反饋。所以在這種情況下,開啟Collision或者Trigger並不會使得原有渲染效果有顯著提升,反而會帶來相當大的效能負擔。

所以本條規則會找出這些粒子系統,以供開發團隊檢查,在確認當前ParticleSystem不需要實現物理特性後,開發團隊就可以果斷關閉相關屬性設定以減小專案的效能開銷和計算壓力。

希望以上這些知識點能在實際的開發過程中為大家帶來幫助。需要說明的是,每一項檢測規則的閾值都可以由開發團隊依據自身專案的實際需求去設定合適的閾值範圍,這也是本地資源檢測的一大特點。同時,也歡迎大家來使用UWA推出的本地資源檢測服務,可幫助大家儘早對專案建立科學的美術規範

萬行程式碼屹立不倒,全靠基礎掌握得好!

相關推薦
《UWA本地資源檢測又更新|幫你把關Shader變體問題》

效能黑榜相關閱讀

《那些年給效能埋過的坑,你跳了嗎?》
《那些年給效能埋過的坑,你跳了嗎?(第二彈)》
《掌握了這些規則,你已經戰勝了80%的對手!》

相關文章