DrawCall是指CPU准備各種數據送達到GPU進行渲染的過程，屬於重度操作，DrawCall影響最大的是幀率！直接體驗就是卡！
目前優化了大地圖里面UI的DrawCall問題，由之前的數量相關，合並優化之后，DrawCall降為2個
同樣，主界面的UI也是，原來雜亂無章的擺放，導致DrawCall數量太多，有意識的重新組織順序，根據Unity 的渲染順序，則可以保證在動態batch中，合並大量的DrawCall！目前主界面UI的DrawCall又30個下降到5個左右（包括一部分3D Mesh,所以無法直接降為2）
此外，主界面有3D的模型作為背景，經檢查，此部分DrawCall多達150個，令人發指啊，簡直不能忍！目前展開優化的方式有三種：1.直接將背景隱藏（影響原本效果），2.將所有的隕石背景合並（目測影響效果）3.由指定方式渲染（即修改順序，修改參數，對效果的影響幾乎可以忽略）
為了達到最低的DrawCall，又不過多損失效果，采取符合規則來進行Batch的策略。目前根據Unity渲染順序，及官方文檔提供的說明，整理出優化方案如下：
1.排列順序：UGUI的渲染順序為從上到下，即你所看到的Hierarchy上面的順序，在使用同一圖集的情況下，連續多次對圖片（相同或者不同）的渲染，只占用一個DrawCall，對文字的渲染同理，只要不交叉渲染圖片和文字，理論上講，這樣可以把整個UI的Draw降低到2！
2.渲染文字：最好使用同一字體，在使用多種字體的時候，最后如1所提示，按順序來！
3.圖集的是用，將圖片打包成圖集的時候，有可能因為圖片的格式問題，或者通道之類的問題，導致明明設置在同一圖集名稱，卻打包成了統一圖集的兩組。所以，盡量使用統一格式！
4.同材質模型：渲染許多使用相同材質的模型，有個最容易忽略的地方，Scale如果不一樣不能Batch，此外還有對頂點數目，shader的pass數量等有限制，不符合會break batching！
5.腳本對材質的訪問：訪問某個使用共享材質的mesh時，考慮使用render.sharedMaterial而不是render.material，后者會在內存中生成一份拷貝！
6.靜態batch：在制作場景的時候，如果能保證mesh本身不發生任何變化，可以使用，效果不錯，就限制大！