Unity效能最佳化之 Draw Call原理<轉>

標籤：

Unity（或者說基本所有圖形引擎）產生一幀畫面的處理過程大致可以這樣簡化描述：引擎首先經過簡單的可見度測試，確定攝像機可以看到的物體，然後把這些物體的頂點（包括本地位置、法線、UV等），索引（頂點如何組成三角形），變換（就是物體的位置、旋轉、縮放、以及攝像機位置等），相關光源，紋理，渲染方式（由材質/Shader決定）等資料準備好，然後通知圖形API——或者就簡單地看作是通知GPU——開始繪製，GPU基於這些資料，經過一系列運算，在螢幕上畫出成千上萬的三角形，最終構成一幅映像。

在Unity中，每次引擎準備資料並通知GPU的過程稱為一次Draw Call。這一過程是逐個物體進行的，對於每個物體，不只GPU的渲染，引擎重新設定材質/Shader也是一項非常耗時的操作。因此每幀的Draw Call次數是一項非常重要的效能指標，對於iOS來說應盡量控制在20次以內，這個值可以在編輯器的Statistic視窗看到。

Unity內建了Draw Call Batching技術，從名字就可以看出，它的主要目標就是在一次Draw Call中批量處理多個物體。只要物體的變換和材質相同，GPU就可以按完全相同的方式進行處理，即可以把它們放在一個Draw Call中。Draw Call Batching技術的核心就是在可見度測試之後，檢查所有要繪製的物體的材質，把相同材質的分為一組（一個Batch），然後把它們組合成一個物體（統一變換），這樣就可以在一個Draw Call中處理多個物體了（實際上是組合後的一個物體）。

但Draw Call Batching存在一個缺陷，就是它需要把一個Batch中的所有物體組合到一起，相當於建立了一個與這些物體加起來一樣大的物體，與此同時就需要分配相應大小的記憶體。這不僅會消耗更多記憶體，還需要消耗CPU時間。特別是對於移動的物體，每一幀都得重新進行組合，這就需要進行一些權衡，否則得不償失。但對於靜止不動的物體來說，只需要進行一次組合，之後就可以一直使用，效率要高得多。

Unity提供了Dynamic Batching和Static Batching兩種方式。Dynamic Batching是完全自動進行的，不需要也無法進行任何幹預，對於頂點數在300以內的可移動物體，只要使用相同的材質，就會組成Batch。Static Batching則需要把靜止的物體標記為Static，然後無論大小，都會組成Batch。如前文所說，Static Batching顯然比Dynamic Batching要高效得多，於是，Static Batching功能是收費的……

要有效利用Draw Call Batching，首先是盡量減少情境中使用的材質數量，即盡量共用材質，對於僅紋理不同的材質可以把紋理組合到一張更大的紋理中（稱為Texture Atlasing）。然後是把不會移動的物體標記為Static。此外還可以通過CombineChildren指令碼（Standard Assets/Scripts/Unity Scripts/CombineChildren）手動把物體組合在一起，但這個指令碼會影響可見度測試，因為組合在一起的物體始終會被看作一個物體，從而會增加GPU要處理的幾何體數量，因此要小心使用。

對於複雜的靜態情境，還可以考慮自行設計遮擋剔除演算法，減少可見的物體數量同時也可以減少Draw Call。

總之，理解Draw Call和Draw Call Batching原理，根據情境特點設計相應的方案來盡量減少Draw Call次數才是王道，其它方面亦然。

Unity效能最佳化之 Draw Call原理<轉>