转 https://zhuanlan.zhihu.com/p/43111806
最近在做Unity的项目，负责UI相关的工作，学习了一下Unity UGUI更新的原理，以及优化相关的部分。本文主要参考UWA的分享，UWA专注性能优化，感觉有很多值得学习的文章， UWA - 简单优化、优化简单 ，打好理论基础，少走弯路，后面实际项目中就是尽可能去实现这些细节了。
目录
- 1.元素更新方式
- 2.Draw Call合并规则
- 3.网格更新机制
- 4.降低界面的渲染开销
- 5.降低界面的更新开销
1.元素更新方式
UGUI
public class VertexHelper:IDisposable
{
private List<Vector3> m_Position = 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<Vector3> m_Normals = ListPool<Vector3>.Get();
private List<Vector4> m_Tangents = ListPool<Vector4>.Get();
private List<int> m_Indices = ListPool<int>.Get();
}
有这样一个VertexHelper类，和UI元素有一一对应的关系，包含顶点信息，UV，颜色，等等 当UI元素发生变化的时候，就会从位置，长宽等数组填充这些list。
对制作的影响
当UI发生改变的时候，须要对数组的元素进行更新， *“动态元素”少用Outline，Tiled Sprite *尽量减少“动态”长文本
image
如上图Tiled生成了大量网格，在填充的时候耗时更长。 OutLine，是通过把一个四边形重复5次，画出的OutLine的效果，会使文本的定点数乘以5，使更新的数组过长。
更新方式
-
UIPanel.LateUpdate
-
轮询
-
UIPanel.UpdateWidgets
-
Cavans.SendWillRenderCanvas
-
队列
-
m_LayoutRebuildQueue
-
m_GraphicRebuildQueue
NGUI每帧更新UIPanel，轮询，不管发生变化与否，哪怕是静态的，还是会有开销
UGUI更新包含2个队列，渲染之前在SendWillRenderCanvas的回掉里面处理2个队列的元素，如果大量静态，消耗几乎为0。
对动态HUD缓存机制的影响
-
NGUI
-
适量元素：Color.a= 0，移出
-
大量元素：SetActive(false)
-
Time + 二级缓存
-
UGUI
-
Scale = 0, Alpha Group = 0
如血条，伤害数字，经常会出现消失的UI元素，如果出现就创建，消失就destory，开销会非常大。所以通常的做法通过缓存，如果通过SetActive有时候会有额外的开销，
UGUI通常的操作方式可以通过scale = 0 ，或则Alpha Group为0，可以快速隐藏，不要直接alpha = 0 ，在draw call 上是没变化的，实际上还是画了个透明度为0的面片。
NGUI中和UGUI相反，如果设置alpha = 0 ，是会把顶点移除掉，可以减少setActive的开销。
2.DrawCall 合并规则
渲染顺序
-
NGUI： Depth
-
设置depth值，以UIPanel为单位，按照大小进行排序，相同材质进行合并
-
UGUI：hierarchy
-
重叠检测
-
分层合并
存在优势，也有一些问题，UGUI的合并规则是进行重叠检测，然后分层合并。下面的例子中，不同颜色代表不同图集。
image
第一个图，4种颜色，左边和右边数序相同，蓝色是0层，白色都是1层，这样会分层合批成4个DrawCall。
第二个图，左边的蓝色是0层，右边的黑色是0层蓝色是1层，这种情况下不会合批，所以会是9个drawCall
第三个图，把黑色延长到重叠的地方，黑色同处0层， 所以DrawCall又降到了5。
所以在制作UI的时候，须要考虑层级关系，结合UGUI的合批规则，这样可以达到对drawCall的优化，
调试工具
- NGUI：DrawCall tool
- UGUI：Frame debugger
NGUI 可以通过DrawCall tool看到多少个三角面，多少个widgets，通过观察widgets的关系，对NGUI层级直接调整，来进行合批。
NGUI使用drawcall tool，通过调整index，把相同材质的放在同一层。
UGUI用frame Debug看每个drawcall绘制了哪些东西，再做调整
image
对界面的影响
-
UGUI
-
不规则图标的摆放
-
UI元素的旋转
-
动态遮挡
-
3D UI
-
NGUI
-
手动排序
UGUI中，对于不规则图形，视觉上icon没有重叠，但是UI层是包围盒的形式，Icon重叠了，UGUI在判断的时候没办法进行合并。
UGUI对于发生旋转的UI，包围盒是会发生重叠，会限制UGUI在合并DrawCall的操作。
如下图：
image
NGUI把不同的元素设在一个图集中，进行同批次绘制。
3.网格更新的机制
-
UIPanel.LateUpdate 两种更新方式
-
UIPanel.FillDrawCall 更新单个DrawCall
-
UIPanel.FillAllDrawCall 更新所有DrawCall
-
Canvas.BuildBatch 更新所有DrawCall
-
WaitingForJob 子线程网格合并
-
PutGeometryJobFence
-
BatchRendere.Flush UI如果开多线程渲染，BatChRender.Flush会增高，主线程在等待子线程的结果时Flush会等待。
NGUI根据不同的DrawCall 合并不同的网格 UGUI以Canvas为单位，一个Canvas下的元素，合并成一个Mesh，不同的UI元素会以SubMeshes的形式存在。UGUI中如果一个Canvas中有很复杂的动态元素，尽量将静态元素拆分出来，确保更新的效率。
image
优化方法：
-
UGUI
-
拆分Canvas
-
NGUI
-
控制FillAllDrawCalls
-
拆分UIPanel
性能比较
- 功能界面的DrawCall控制 NGUI>UGUI (NGUI通过DC树，通过调整Index进行调整)
- 功能界面的网格更新机制 NGUI>UGUI （UGUI更新任何一个UI，都会更新整个Canvas）
- 动态HUD界面的网格更新机制 UGUI>>NGUI （UGUI在处理动态UV的元素，如血条，动态UI会更有优势）
- 堆内存控制 UGUI>>NGUI （NGUI堆内存占用更高）
参考 https://blog.uwa4d.com/archives/Implosion.html
4.降低界面的渲染开销
- Profiling 定位
- DrawCall 控制
- Mesh.CreateVBO UI变化的网格开销
- Overdraw UI比较容易产生Overdraw
Profiling
UGUI 非多线程渲染Unity5.3 主要集中在RenderSubBatch，
image
DrawCall控制
Z值！=0
合并时只会合并相邻层级，相同图集的元素
左边的图，4个血条红色和白色的z值相同，共2个drawcall，但是右边的图，红色和白色穿插，变成8个drawcall，在3D UI的时候尤其明显，2DUI不要通过这种方法，改Z值，因为2D改了之后，
image
未“隐藏” 的元素
包含 Null Sprite, Color.a = 0 屏幕外
对于隐藏的元素，NGUI的image组件中，alpha为空和sprite为空，都是占用drawcall渲染的，而且会打断前后的drawcall，穿插在上下2个元素中间的时候。
image
Hierarchy 穿插+重叠
如下图红点和Icon在不同图集中，如果红点稍微大一点，遮挡了旁边的Icon，就不能合批，须要调整Icon和红点的节点关系，4个Icons放在一个节点下，4个红点放在一个借点下。在同步位置的时候可能稍微麻烦有点，须要写个脚本同步位置。
image
image
图集分离
可能因为压缩方式的不同，导致UI的sprite在不同图集中，也会影响渲染开销，不同图集中无法进行合批
image
OverDraw
- 减少UI层叠
- 遮挡场景时，关闭场景相机
- 不用Image检测事件
参考： https://blog.uwa4d.com/archives/video_UI.html
5.降低界面的更新开销
- 动静分离
- 降低更新频率
- 避免“敏感”操作
- 优化选项
动静分离
在UGUI中细分Canvas 下图中，血量和经验条会经常更新，如果在一个canvas中，PutGeometryJbFence和WaitngForJob,buildBatch出现的时候，表示更新的开销在子线程中，主线程处在一个等待的状态，差不多有5，6毫秒的等待。
image
拆分之后刚才的WaitingForJob等都没有了，动态的canvas开销就会很小。
image
降低更新的频率
- 设定移动阈值
- 设定更新频率
image
比如像小地图这样的界面,可能移动了一小段距离，小地图上更新了也不明显，可以通过设定阈值的方法，降低开销，或者直接设定更新时间。
避免“敏感”操作
- 元素的Position赋值->Canvas.BuildBatch
下面的一个例子是在Canvas中，所有元素基本是静态的，但是有个元素，在Update中，会跟随target的position，每次发送改变的时候，会重建整个canvas，导致资源的浪费。
image
参考文献：
网友评论