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次數才是王道，其它方面亦然。

轉載于:https://www.cnblogs.com/wonderKK/p/3918052.html

總結

以上是生活随笔為你收集整理的（转）Unity3D - 性能优化之Draw Call的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。