UI 性能
Q1：我用NGUI开发，因为角色名字导致重建，使得UIPanel.LateUpdate的CPU占用很高。如果将它们分离到多个UIPanel里，是否这个开销会相对小一些？
将较多的动态UI元素分组放在不同的UIPanel中确实是UWA比较推荐的方式，一方面可以降低重建的概率，某些分组中可能没有UI元素发生变化，从而不会进行重建；另一方面可以降低重建的开销。通过分组，可以将每个UIPanel所产生的Mesh控制在较小的范围内，从而控制其重建的开销（通常重建的开销会因Mesh的增大而明显升高，且不是线性的关系）。虽然这种做法会产生额外的DrawCall，但DrawCall的开销与网格重建相比通常都非常小。
UI 加载
Q2：加载UI预制的时候，如果把特效放到预制里，会导致加载非常耗时。怎么优化这个加载时间呢？
UI和特效（粒子系统）的加载开销在多数项目中都占据较高的CPU耗时。UI界面的实例化和加载耗时主要由以下几个方面构成：
1. 纹理资源加载耗时
UI界面加载的主要耗时开销，因为在其资源加载过程中，时常伴有大量较大分辨率的Atlas纹理加载，我们在之前的Unity加载模块深度分析之纹理篇有详细讲解。对此，我们建议研发团队在美术质量允许的情况下，尽可能对UI纹理进行简化，从而加载UI界面的加载效率。
2. UI网格重建耗时
UI界面在实例化或Active时，往往会造成Canvas（UGUI）或Panel（NGUI）中UIDrawCall的变化，进而触发网格重建操作。当Canvas或Panel中网格量较大时，其重建开销也会随之较大。3. UI相关构造函数和初始化操作开销
这部分是指UI底层类在实例化时的ctor开销，以及OnEnable和OnDisable的自身开销。
上述2和3主要为引擎或插件的自身逻辑开销，因此，我们应该尽可能避免或降低这两个操作的发生频率。我们的建议如下：
1.在内存允许的情况下，对于UI界面进行缓存。尽可能减少UI界面相关资源的重复加载以及相关类的重复初始化；
2.根据UI界面的使用频率，使用更为合适的切换方式。比如移进移出或使用Culling Layer来实现UI界面的切换效果等，从而降低UI界面的加载耗时，提升切换的流畅度。
对于特效（特别是粒子特效）来说，我们暂时并没有发现将UI界面和特效耦合在一起，其加载耗时会大于二者分别加载的耗时总和。因此，我们仅从优化粒子系统加载效率的角度来回答这个问题。粒子系统的加载开销，就目前来看，主要和其本身组件的反序列化耗时和加载数量相关。对于反序列化耗时而言，这是Unity引擎负责粒子系统的自身加载开销，开发者可以控制的空间并不大。对于加载数量，则是开发者需要密切关注的，因为在我们目前看到的项目中，不少都存在大量的粒子系统加载，有些项目的数量甚至超过1000个，如下图所示。因此，建议研发团队密切关注自身项目中粒子系统的数量使用情况。一般来说，建议我们建议粒子系统使用数量的峰值控制在400以下。
UI 原理
Q3：能否就UGUI Batch提出一些建议呢？是否有一些Batch的规则？
在 UGUI 中，Batch是以Canvas为单位的，即在同一个Canvas下的UI元素最终都会被Batch到同一个Mesh中。而在Batch前，UGUI会根据这些UI元素的材质（通常就是Atlas）以及渲染顺序进行重排，在不改变渲染结果的前提下，尽可能将相同材质的UI元素合并在同一个SubMesh中，从而把DrawCall降到最低。而Batch的操作只会在UI元素发生变化时才进行，且合成的Mesh越大，操作的耗时也就越大。
因此，我们建议尽可能把频繁变化（位置，颜色，长宽等）的UI元素从复杂的Canvas中分离出来，从而避免复杂的Canvas频繁重建。
UI 原理
Q4：ScrollRect在滚动的时候，会产生Canvas.SendwillRenderCanvases，有办法消除吗？
ScrollRect在滚动时，会产生OnTransformChanged的开销，这是UI元素在移动时触发的，但通常这不会触发Canvas.SendWillRenderCanvases。
如果观察到Canvas.SendWillRenderCanvases耗时较高，可以检查下ScrollRect所在的Canvas是否开启了Pixel Perfect的选项，该选项的开启会导致UI元素在发生位移时，其长宽会被进行微调（为了对其像素），而ScrollRect中通常有较多的UI元素，从而产生较高的Canvas.SendWillRenderCanvases开销。因此可以尝试关闭Pixel Perfect看效果是否可以接受，或者尝试在滚动过程中暂时关闭Pixel Perfect等方式来消除其开销。
原文出处：侑虎科技
本文作者：admin
转载请与作者联系，同时请务必标明文章原始出处和原文链接及本声明。
