Unity3D_NGUI_性能优化实践_CPU卡顿

博尔特以9.58秒创造了百米世界纪录，假设他是跑酷游戏的角色，卡顿一帧就足以把冠军拱手让人。

Unity3D程序各项性能问题，从Profiler可观察到许多蛛丝马迹。下面看几个典型例子Profiler的CPU指标截图。

有时候蛛丝马迹非常显眼，闪瞎钛白金像素眼。然而有些过于显眼，以至于Profiler都展开不了看详情。囧。

[UICamera.Update]

有时候要展开很多很多很多...层才能抓住元凶。

[UICamera.Update.xxx.xxx.xxx..........GameObject.SetActive]

CPU曲线有偶发性卡顿，比如：

[UIPanel.LateUpdate...FillAllDrawCall]

CPU曲线也有持续性卡顿，比如：

[UIPanel.LateUpdate...FillDrawCall]

游戏单局内每一帧都很关键，卡顿轻则引起操作失误，重则直接撞死。边优化边记录，发现UI原因导致卡顿如下表所列。个别类型频繁亮相。

注：UILabel、UITexture、UISprite都是UIWidget子类，而UIWidget是UIRect子类。

下文举例阐述表格中各种问题与处理方案详情。游戏项目中实际逻辑代码较为复杂，例子中或以Sample代码示意。

①实时加载资源

问题描述：Resource.Load示意代码

Profiler调用节点类似下图所示。

（上图借用其他界面某个瞬间截图）

处理方案：预加载。资源加载不可避免，但触发时机可以提前，也即提早加载资源，比如脚本Start()或OnEnable()，而不是游戏单局中由玩家输入实时触发。

②创建实例分配内存

问题描述：Instantiate示意代码

Profiler调用节点类似下图所示。

（上图借用其他界面某个瞬间截图）

处理方案：预先分配内存。同①，提早分配所需内存，避免实时触发。

③显示与隐藏

问题描述：显示或隐藏物件，常规思路是采用GameObject.SetActive(true/false)，然而此方法会触发一系列UIRect子类的初始化方法。

Profiler调用节点类似下图所示。

处理方案：应避免直接使用GameObject.SetActive(true/false)显示或隐藏物件，改为其他方式代替。比如设置Position把物件移进移出屏幕，或者设置Scale缩放比例、设置Alpha透明度等方式代替。

④设置UIWIdget属性

问题描述：变更UIWidget（UIRect）及其子类属性，包括alpha、color、depth、localPosition、localRotation、localScale、width、height、rawPivot、pivot，会触发UIPanel.LateUpdate.FillDrawCall或FillAllDrawCall。

在UIPanel.LateUpdate代码中可看到，若UIWidget（UIRect）的depth、material、mainTexture变更，一定条件下会重排UIWdiget组件渲染顺序，调用FillAllDrawCall或FillDrawCall。

Profiler调用节点类似下图所示。

可看到FillAllDrawCall明显比FillDrawCall更耗资源。

处理方案：单局游戏中应避免变更UIWdiget的depth次序，或变更UIWdiget所用的material、mainTexture ，为达到同样的界面显示效果，可以采用变更UIWdiget其他属性来达到相同目的。除了depth调整可能触发FillAllDrawCall，其他属性变更并不会触发FillAllDrawCall。

例(1)：调整position代替调整depth，达到完全显示与遮挡的特殊切换效果。

⑤设置UIBasicSprite属性

问题描述：UIBasicSprite继承于UIWidget，除UIWidget属性外，UIBasicSprite自身属性字段包括flip、fillDirection、fillAmount、invert。变更属性值会调用UIWIdget.MaskAsChange，可能触发UIPanel.LateUpdate.FillDrawCall或FillAllDrawCall。问题同④。

一般来说UIBasicSprite这几个属性值变更并不会引发FillAllDrawCall。

处理方案：同④，根据实际情况处理。

⑥设置UISprite属性

问题描述：UISprite继承于UIBasicSprite，除UIBasicSprite属性外，UISprite自身属性字段包括atlas、spriteName、fillCenter。变更属性值会调用UIWIdget.MaskAsChange，可能触发UIPanel.LateUpdate.FillDrawCall或FillAllDrawCall。问题同⑤。

注意，变更atlas会变更mainTexture，进而触发FillAllDrawCall。变更atlas的常见应用场景是因游戏逻辑而实时变更图标。

处理方案：为了避免因atlas变更而触发FillAllDrawCall，有几个思路：

（1）prefab预先创建多个UISprite并设置对应的atlas和spriteName，在实际显示时再通过变更position来达到相同目的。

（2）整合多张Atlas为一张大的Atlas，在实际显示时只切换spriteName。

⑦设置UITexture 属性

问题描述：UITexture继承于UIBasicSprite，除UIBasicSprite属性外，UITexture自身属性字段包括mainTexture、material、shader、border、uvRect。变更属性值会调用UIWIdget.MaskAsChange，进而可能触发UIPanel.LateUpdate.FillDrawCall或FillAllDrawCall。问题同⑤。

处理方案：为了避免触发FillAllDrawCall，应尽量避免变更属性值。一般来讲，固定不变的贴图才适合使用UITexture。

注意，UITexture有一个特殊应用场景是玩家头像。这是因为头像图片是网络下载的资源，默认仅适合UITexture显示。于是变更mainTexture即带来FillAllDrawCall。基于此问题，项目中采用了“动态生成Atlas，游戏中仅切换spriteName”的方案来解决。

此Atlas图集包含了真实玩家头像和NPC头像，于游戏开始前动态生成。

参考：http://blog.csdn.net/u012091672/article/details/35297949

⑧设置UILabel属性

问题描述：UILabel继承于UIWidget，除UIWidget属性外，UILabel自身属性字段很多，其中text和font需重点关注。

（1）text：赋值会带来一系列字符串操作，相对较耗时。此外需特别留意的是，text赋值还会触发Font.CacheFontForText，此方法在真机的实际占用资源比编辑器多很多，实践中应以真机Profiler为准。以下分别是编辑器（0.06ms/0.21ms）和真机（2.12ms/2.39ms）的消耗对比。不管数字、英文或是汉字，现象都一样。

处理方案：为避免实时触发Font.CacheFontForText，可在游戏开始时把可能出现的字符全部赋值一次给UILabel.text，也即避免提前触发Font.CacheFontForText。这里提前赋值的字符Cache最小单位是单个字符。比如表示奔跑距离的UILabel：

即可Cache全部阿拉伯数字加“米”字的展示需求。

（2）font：变更会直接把UILabel从UIPanel的UIWidget列表中移除，再添加一个新的。此操作会带来FillAllDrawCall。实践中鲜见动态修改UILabel.font。若确实需要动态切换UILabel.font，可采用切换两个UILabel来代替，而这两个UILabel分别应用了两个不同font。

⑨重复赋值多个关联UIWIdget组件

问题描述：举一个例子。

游戏单局内的任务进度条先前实现是使用两个UIProgressBar，分别更新图形进度条（红色框内容）和数字进度栏（蓝色框内容）。当任务进度刷新时，两个UIProgressBar.value会同步刷新。

处理方案：经分析，此处相关联的多个UIWidget可合并赋值。数字进度栏（蓝色框内容，更新数字和位置）加上亮光头部（更新位置）算到整个Thumb，这样UIProgressBar.value就只需要更新一次（红色框内容更新时会同步更新蓝色框内容）。

⑩图标位置重排

问题描述：举一个例子。

游戏单局内的Buff列表先前实现是使用一个UIGrid，当数量变更时重排UIGrid。当Item数量减少，需gameObject.SetActive(false)或transform.parent=null，才可以让UIGrid正确重排。这使得UIGrid.Reposition相对耗时。

处理方案：以其他等价方式代替。由于是固定的0~3个图标Item，所以按情况设置这4种情况的每组Item坐标即可。不显示的设置Position移到屏幕外。此方法可避免UIGrid.Reposition。

⑪同一帧逻辑繁重

问题描述：看具体例子。

现象（1），游戏单局内UI界面某些数据变化不频繁，无需每帧实时刷新。为了节省CPU资源，按经验值可以每6帧处理一次。代码片段如下：

游戏单局内Profiler曲线大致如下，可以看到明显有节奏锯齿：

现象（1）处理方案，将耗时逻辑分散到这6帧处理，每帧处理不同逻辑。也即分散了CPU压力。代码片段如下：

调整后Profiler曲线大致如下，看到锯齿有所缓解。由于拆分后每一帧的逻辑复杂程度不一样，所以曲线平滑程度有限，仍有改善空间。

现象（2），当游戏单局内触发某类事件，会立即在UI界面上表现。比如捡到一个道具，UI界面立即显示一个图标。代码片段如下：

从Profiler看到是同一帧处理了多个耗时逻辑。

现象（2）处理方案：延迟处理。

将UI表现逻辑延后一帧再处理，分散CPU压力。代码片段如下：

调整后Profiler曲线大致如下（下图分别是两帧数据），相对修改前能稍微缓和曲线峰值。

⑫ParticleSystem粒子特效与Animation动画

问题描述：游戏中为达到酷炫效果，往往会应用ParticleSystem粒子特效与Animation动画，然而此举较耗CPU资源。当游戏单局内场景帧率要求较高时，较多或较复杂的粒子特效和动画会降低帧率，反而影响游戏体验。

处理方案：有以下思路，需取折衷方案。

（1）调整显示策略。例如：根据高端机、中端机、低端机（根据CPU、运行内存、屏幕分辨率等参数计算的综合性能评分）来决定是否启动特效和动画。

（2）以其他等效方式代替。例如：一个图标渐显渐隐同时放大缩小的效果，可采用组合TweenAlpha+TweenScale动画来代替Animation动画。

⑬其他

除前文提到Unity自带强大Profiler（官方手册），实践中还有很多调试工具和方法。比如：

（1）强制暂停Unity编辑器。

（2）关键节点代码采用return、continue等中断正常流程，以排除法逐渐逼近目标。尤其适用于Profiler展开失败的情况。

（3）构建Development Build调试版本，连接真机Profiler：

http://blog.csdn.net/u014076894/article/details/38050957