Q&A——运行性能（一）

运行性能

Q1：如下图，我们发现WaitingForJob这个函数消耗过高导致了卡顿，请问该卡顿是否由于渲染压力过大导致？

从图中看，该线程最后是在等待 Canvas.sortjob，而这是 UI 排序造成的开销（自Unity5.2版本开始，UGUI的部分计算已经移出了主线程）。
详情参考：http://blogs.unity3d.com/2015/09/07/making-the-ui-backend-faster/
因此理论上，这是 UI 的 canvas.sortjob 在指定的时间上没有完成，从而使得渲染线程等待，且最终导致主线程进行等待而造成的开销。

运行性能

Q2：我们在查看《六龙争霸测评精讲》时，看到下图中的GC的调用，请问该数值的是取决于明式调用System.GC.Collect()这个方法吗，还是指系统自动GC的频率？

手动触发System.GC.Collect和系统触发GC都属于GC的调用。除iOS平台外，Unity项目的GC调用是由Mono来控制的。其主要有两种方式，一种是系统每隔一段时间调用一次，一种则是当堆内存分配过大过快时被触发。
每次GC调用均会造成一定程度上的卡顿，从而降低项目运行的流畅度。因此UWA测评中专设了GC调用详细检测，欢迎开发者上传项目测试！

运行性能

Q3：在报告中我们看到函数uwa-xxx是我们加的自定义代码段采样， 我们发现它们触发了很多GC， 是什么情况呢？

说明这些函数中会经常分配大量的堆内存 。GC是Mono来控制的，当Mono认为累积堆内存较高时，它就会调用GC。同时，哪个函数在分配堆内存时触发了Mono的GC，该GC调用就会被算作是哪个函数调用的。所以如果经常被特定函数来触发GC，那么从概率上来说这个函数或这个代码段分配的堆内存相当高。

运行性能

Q4：项目中勾选Static Batching和不勾选对效率有多大影响？我们在使用中发现勾选了以后包大小会增大一倍。如果不勾选，和自己在代码中调用StaticBatchingUtility.Combine的效率有多大区别？

• 如果在Editor中进行勾选，则会在项目中生成一个较大的VBO，Runtime时通过该VBO来进行渲染，优点是有效减少了Draw Call，缺点是增大了发布游戏包的体积。
• 如果在Runtime通过脚本来进行Batching，则相当于把拼合的时间由Editor中搬到了Runtime，所以加载时间（一般在场景加载时执行Batching）会稍有增加，但游戏包的体积将相应减少。

运行性能

Q5：如何在移动设备上，对Bloom和全屏抗锯齿进行优化？Unity标准资源里面自带的效率比较低（已经尝试过Bloom(Optimized)）。

建议使用Asset Store上适合移动端的Bloom Shader插件，比如FxPro: Bloom&DOF和BloomPro等。

对于AA，目前在移动设备上并没有特别优化的方法，仅能建议在低端设备上关闭AA功能，而在高端设备上可尝试开启较低倍数（2x）的MSAA。

运行性能

Q6：我现在发现两个因素直接影响Overhead，一个是Shader的复杂度，一个是空Update方法及其同类空方法，不知道是否还有其他因素？

Overhead的计算方法是：Profiler当前帧统计的总耗时时间减去所有已知选项的累加时间，即引擎当前还无法识别模块的耗时时间。Overhead数值理论上是趋向于0的，但是由于目前市面上的硬件设备、系统框架过于丰富，所以引擎可能无法识别所有模块的CPU开销。
就我们目前遇到的大部分案例而言，Overhead数值较高一般是由硬件设备的垂直同步算法无法识别而引起的。所以，一般情况下，Overhead的数值其实并不需要开发者特别关注。
在UWA的性能分析中，我们并没有将Overhead计算在内，一方面是其本身数据的统计意义对目前大多数项目的性能优化帮助不大，另一方面是即便知道了它的CPU数值，也无法知道到底是哪些地方引起的，上层很难有针对性地进行优化。
当然，我们会持续对Overhead进行实验和研究，分析其CPU耗时规律、与已知选项的关联性等。后续有任何相关发现，我们都会总结成文，及时分享给大家。