NGUI开发优化技巧（下）

NGUI更新开销：NGUI进行自身的数据更新以及生成网格的过程中所产生的开销，目前UI部分的CPU耗时大部分都是这部分的开销；

NGUI的更新开销几乎全部来源于UIPanel.LateUpdate中；一般超过3~4ms，说明这部分更新开销较高；

UI更新的数量和频率通过合理的布局，可以把这部分的开销限制在很多小的范围里面；

在关卡的切换或点击一些UI界面时，可以出现一些较高的峰值；

但在战斗部分要保证UIPanel.LateUpdate在很小的范围内波动，一般在2~3ms；

 

UIPanel.LateUpdate在进行完全的重建时，才会出现较高的堆内存开销；

NGUI更新的对渲染的影响：

NGUI的更新在渲染时的耗时出现在MeshRenderer.Render，Mesh.DrawVBO和Mesh.CreateVBO有一部分是由NGUI造成的，NGUI中UIPanel的刷新和UI元素的变动导致网格发生了变化或更新，都会使Mesh.Create产生开销；

UIPanel.LateUpdate的总堆内存分配在10~20M之间，是合理的；（10000~20000帧）

UIPanel的堆内存是有UIPanel的刷新引起的，堆内存越高说明UIPanel的刷新频率越高，所涉及的UI元素的数量可能越大；

UILabel的更新开销

1：Font.CacheFontForText

2：Shadow

3：Outline

在手机上，纹理的大小会有所限制，纹理的内容会不停地变动，纹理不停地刷新，会导致

Font.CacheFontForText不停地被触发；

出现文本比较大，首次出现，并且用的是动态字体，就会产生比较高的Font.CacheFontForText函数开销，对于频繁地、反复使用的文本，尽可能地做成静态字体；

开启和不开启Shadow的区别；

开启和不开启Outline8的区别；（比Shadow的性能开销还大）

 

对于频繁移动的文本，开启Effect效果，对性能开销比较大；

 

对于动态的文本（会移动或会变颜色），尽可能少用这些特效，对于静态的不影响；（不会每一帧去更新网格）

 

UISprite的更新开销

（Size越大，平铺地越多，三角面片和网格数越多，造成开销越大）

使用和不使用Tiled模式的区别；

 

UISprite或文本的UI元素本身在移动或变颜色时，才会真正产生开销；静止时则不会更新，

不产生开销；

 

 

UIPanel更新机制

1：更新单个UIDrawCall；

2：更新所有的UIDrawCall；

 

UIDrawCall：一个UIPanel中可能会有各种各样的UI元素，这些UI元素可能来自于不同的图集，对于来自于不同图集的元素最终渲染时不能合在同一个DrawCall里面，所以一个UIPanel里面会包含很多个UIDrawCall，这些UIDrawCall首先按照UI元素的深度（Depth）进行排序，

然后再根据相邻元素是否来自于同一个图集来进行合并，这里的每一个UIDrawCall都包含了若干个UI元素，这些UI元素来自于同一个图集，且深度值在排序里面是相邻的；

 

进行Panel更新时，有两种模式：

1：更新单个UIDrawCall：在更新过程中，某个UI元素进行了移动，只会更新自己所在的UI元素里面的网格，不会影响其他的DrawCall；

2：更新所有UIDrawCall：一旦满足某种条件，会直接重建UIPanel里面所有的DrawCall；

 

并不是把DrawCall降低地越低越好，当一个顶点发生变化时，因为这个顶点和其他的顶点在同一个Mesh上面，所以一个顶点的更新会导致所有Mesh的更新；

 

如果添加的界面并不是和变动的UI元素在同一个DrawCall里面，那么在更新元素时，并不会产生影响；

总结

对于频繁变动的UI元素，其所在的UIDrawCall面片数越少越好；

 

更新所有的UIDrawCall：

主要原因：UIPanel中的UIDrawCall发生了变化；（在UIPanel里面添加了DrawCall或是把UIPanel里面原有的DrawCall拆分成多个（动态地添加或删除一些UI元素））

在这一帧内，有很多网格进行了重建，会影响到Mesh.CreateVBO；

动态添加窗口，穿插了NGUI Panel，导致UIPanel的完全重建；

将其中一个UIDrawCall分离到其他的UIPanel中后

 

不同UIPanel下的UI元素是不能进行合并的；

调整深度，不要打断原有的DrawCall；

动态的UI元素中少放东西，或直接把它独立成一个UIPanel；

 

更新所有UIDrawCall的条件

1：添加/删除元素时，穿插了其他的UIDrawCall；

2：添加/删除的元素自成一个UIDrawCall；

 

总结：

1：对于频繁变动的UI元素，其所在的UIDrawCall面片数越少越好；

2：动态添加UI元素时，注意Depth的设置，尽可能合入已有的UIDrawCall；

（在添加UI元素时，这个Depth是包含在现有的DrawCall里面的，并且这个DrawCall的材质和所添加的元素的材质是一致的，这样就不会产生完全的重建）

3：对于需要动态添加UI元素的UIPanel，减少其复杂度，从而避免在更新所有

UIDrawCall时开销过大；（战斗过程中出现的连击提示，应尽可能地减小这种界面的复杂度，

不要把静态的东西（头像、置顶的怪物的血条）也放在UIPanel里面）

 

动态字体（字体在不停变换时）：在手机上，文本所对应的字体、材质、纹理会不停地进行更新，每一次想往纹理里面添加新的文字，当发现纹理不够时，会触发刷新的操作，会根据当前创建纹理大小的限制（比如需要创建512*512，但根据某些机制发现只能创建256*256的），则会先把屏幕上激活状态的文本填入纹理，对于出现过的，但是已经被禁用的文字就会全部被剔除掉，这个过程相当于完全更新了纹理里面的内容，这种操作也是耗时最大的操作；

动态字体优化的两种方式：

1：如果字体可以做成静态的，则优先做成静态的，就可以避免Font.CacheFontForText；

但也会出现一些问题（比如：在一些剧情比较复杂的游戏中，涉及的剧情非常多，每一段剧情需要的文本量非常大，如果做成静态的，可能带来10多张1024*2048这种纹理，这就不同通过转成静态字体这种方式来处理这种情况）；

2：文本只出现一次，后面不会出现，可以让它预先出现，比如创建一个Label，里面有这个文字，并且是处于激活状态的，只是相机看不到，可以把这些峰值移动到可以卡顿的地方，在真正播放剧情时，通过移动或者修改Layer让这些文字更流畅地逐渐显示出来；

进入读条时，先把这些文本放成激活状态，让动态字体需要的纹理先生成好；

 

 

多个动态的物体，放在一个Panel好，还是放在多个Panel好；

通常进行分组比较好，可以少量地提高合并网格的计算量（优化量并不多，因为网格总量是一样的，只是分成几个分组而已），影响比较大的是:Camera.Render里面的CreateVBO；

 

做UI元素的分离时有一个好处：

一个屏幕上存在多个UI元素，只有少量的UI元素在移动，可以做动态Panel的划分，对于静态不动的网格不应该去更新；