UGUI 合批原理
轉自：?UGUI合批原理筆記 - 趙青青 - 博客園
UGUI合批規(guī)則圖解_時光不染-CSDN博客_ugui合批規(guī)則
合批的過程#
網格更新機制#
- Cavans.SendWillRenderCanvas
- m_LayoutRebuildQueue
- m_GraphicRebuildQueue
- Canvas.BuildBatch 更新所有DrawCall
- WaitingForJob 子線程網格合并
- PutGeometryJobFence
- BatchRendere.Flush UI如果開多線程渲染，BatChRender.Flush會增高，主線程在等待子線程的結果時Flush會等待。
哪些因素的改變會引起合批#
從源碼中可以看到，這些數據的改變會引起合批
源碼地址： UI / UnityEngine.UI / UI / Core / Utility /?VertexHelper.cs?
private List<Vector3> m_Positions = ListPool<Vector3>.Get();//頂點位置的拷貝或指定新頂點位置的數組 private List<Color32> m_Colors = ListPool<Color32>.Get();//顏色 private List<Vector2> m_Uv0S = ListPool<Vector2>.Get();//基本紋理坐標 private List<Vector2> m_Uv1S = ListPool<Vector2>.Get();//第二套紋理坐標 private List<Vector2> m_Uv2S = ListPool<Vector2>.Get();//第三套紋理坐標 private List<Vector2> m_Uv3S = ListPool<Vector2>.Get(); private List<Vector3> m_Normals = ListPool<Vector3>.Get();//法線 private List<Vector4> m_Tangents = ListPool<Vector4>.Get();//切線 private List<int> m_Indices = ListPool<int>.Get();//mesh的索引Mesh的API：http://wiki.ceeger.com/script/unityengine/classes/mesh/mesh
http://wiki.ceeger.com/script/unityengine/classes/mesh/mesh.getindices
怎么避免合批#
盡量減少“動態(tài)”長文本(運行時修改文本內容)
Image或Text，如果不需要點擊，則不要勾選Raycasts
降低界面的更新頻率
避免圖集分離，使用相同的圖集。
同一圖集的Image元素應盡量保證在Hierarchy中連續(xù)，避免中間插入其他圖集，或插入文本。
避免圖片疊加在一起（遮擋，旋轉）
如果sprite是中心鏤空且切圖為九宮格時，可以去除fill center，以減少over draw
透明Image，用來做響應點擊事件，同樣存在開銷
避免或減少Mask的使用，1個Mask至少增加兩個DC
避免頻繁刪除/增加UI對象，UI層次結構變化會引起Canvas的更新
避免頻繁動態(tài)的更新UI元素的Vertex, Rect, Color, Material, Texture等，可能引起Canvas數據更新和Batch更新計算，有可能引起VBO Update（重新提交頂點數據）。
盡可能使用少的UI Material和貼圖（使用圖集），使得可以Batching。
同一父節(jié)點下所有子節(jié)點，保持相同的層次結構（如List控件下的item），便于底層相同depth下UI元素Batch。
避免UI元素數目過多和層次結構過于復雜影響B(tài)atch更新速度。
固定的Text考慮與背景圖層合在一張圖上（可能不便本地化，但可以減少drawcall）。
使用緩存池，對緩存頻繁使用的元素。
部分內容參考：http://gad.qq.com/article/detail/25947
HUD處理(動靜分離)#
Canvas重建就是為了合并DC，將經常變化的文字放在獨立的Canvas，手動分離Canvas（會增加DC，不能和其它文字合并），但文字變化時其它Canvas就不需要重建。
示例：名字和血條分開在兩個不同的節(jié)點下。這樣當血條變化時，就不會引起名字的更新。如下圖所示：
2、設置scale為0，而不是設置active = false/true，或者添加Alpha Group，設置alpha=0/1
不勾選FillCenter#
鏤空九宮格不勾選FillCenter，在Scene的Overdraw下可以查看到，不勾選FillCenter，overdraw會減少。
少用Effect功能#
少用Outline，Tiled Sprite
outline額外生成7倍頂點#
在一個空場景中，給Text添加outline之后，頂點數大約是未添加之前的7.5倍。
去掉outline之后，頂點數下降了很多。
Image不使用Tiled#
type=simple時的頂點數
使用Tiled之后，頂點數也上漲很多。
參考資料#
Unity官方論壇發(fā)布?Unity UI性能優(yōu)化技巧
UGUI優(yōu)化：批次合并源碼分析及工具
工具：UI層級輔助工具，用于顯示UI的層級、批次等數據，便于UI性能優(yōu)化。使用者可以結合以上規(guī)則，分析當前UI元素排列順序、材質貼圖設置，優(yōu)化UI Batching，減少UI Drawcall。
Unity UI優(yōu)化小結
重建 是UGUI優(yōu)化的關鍵 -- Unite2017嘉賓楊懷忠分享《UGUI深度優(yōu)化》
原理圖解
批處理: 大致就是Unity在運行時可以將一些物體進行合并，本來需要多個drawcall指令才能渲染完成的降為1個drawcall就能搞定
使用: UGUI在合批之前，會根據ui的Depth、MaterialID 、MaterialID、RendererOrder進行排序，之后對相鄰的UI進行檢測。判斷MaterialID和TextureID是否相同，如果相同則可以進行合批處理。如果不同則會打斷合批
先決條件：MaterialID,TextureID相同
這兩個很容易達成，不對默認Material做修改，并使用同一個圖集即可
我們這里主要講解的是打斷合批的情況
排序圖解
首先看下圖
文字 Texture 是Font Texture
?
?
空白圖片 Texture 是UnityWhite
1.首先由Depth排序，蓋在最里面的白色圖片深度為0
2.Text在白色圖片上面，二者材質(Material)相同,但紋理(Texture)不同，不能合批，Text深度為1
3.再往下，紅色圖片蓋在Text上面，同理不能合批，red深度為2
4.黃色和紅色材質和紋理都相同，可以合批，yellow深度為2
5.同理綠色圖片green深度為2
?
這里我們打開Profiler(command + 7)看一下，3個批次符合判斷
注一
以上覆蓋關系與控件大小無關，與控件在Hierarchy的布局位置無關，只與渲染的三角面有關，如圖
?
?
scene選擇Wireframe，可以看到渲染的三角面
顯示如下，控件大小為藍色調整大小的區(qū)域，實際渲染的只有左上的小方塊三角面
紅色圖片的方框一部分與Text線框重合。所以打斷了合批。
我們嘗試把Text上移一些，如下圖
?
?
?
?
對比以上圖片可發(fā)現(xiàn)，Hierarchy布局未發(fā)生變化，只是移動了Text的位置，Text區(qū)域框依然和red區(qū)域有重疊。合批卻發(fā)生了變化。
實例圖解
實際應用案例
下面是一個常見界面，對比一下合批的效果
不打包圖集
?
?
使用圖集
?
一些注意事項
1.一些打斷合批的細節(jié)
如圖，第一個道具的 label_destory 沒有隱藏，img_btn 能完全覆蓋，顯示效果是一樣的。
?
但是label_destory 會打斷 img_cellBg 與 img_btn的合批，平白多出2個批次
2.圖集打包的注意事項
?
drawcall并不是最求極限越小越好。
如文中的道具圖標，如果有大量圖標，打包到同一個圖集里會使圖集很大。
決定渲染模塊性能的除了Draw Call之外，還有用于傳輸渲染數據的總線帶寬。當我們使用Draw Call Batching將同種材質的網格模型拼合在一起時，可能會造成同一時間需要傳輸的數據（Texture、VB/IB等大大增加，以至于造成帶寬“堵塞”，在資源無法及時傳輸過去的情況下，GPU只能等待，從而反倒降低了游戲的運行幀率
這種界面一般重復使用的UI打包為一個圖集。
圖標根據數量分為多個圖集，或者由美術直接提供圖集自己做裁切。
圖集大小根據各公司規(guī)范略有不同，大多是512或1024
?
總結
- 上一篇： winform窗体控件（全）
- 下一篇： xcode 自动化出包