instantiate 卡顿严重_Unity3D_记一次CPU卡顿的排查实践

这是一次CPU卡顿的排查实践，开发环境是Unity5.3.4p5 + uGUI

======

为了避免打log引起的额外消耗，所以以下分析基于log关闭后的Profiler数据

Debug.logger.logEnabled =false;

问题1：ConfigUtil.Get().Single(Func)

List  ConfigUtil.Get()内含List.AddRange()申请临时内存，相对GC Alloc和耗时较多；

T  List.Single(Func)多次遍历查找同一个List，耗时较多。影响范围较广。

修行状态的红点计算NinjaPracticeController.UpdatePracticeState()较为复杂，查询修行配置有多层循环嵌套，而且内层嵌套有多次重复计算，且频繁出现于回包中。比如心跳回包会计算修行红点状态，其他一些回包触发OnSyncSthChangeCommand的也会引起修行红点计算。

修改前(60次+60次)：

将查询全量配置提前到for循环之前算好。并且classEvolveCfg和classUpgradeCfg这两项配置信息并不总是需要，而是根据底下if-else的条件局部需要，所以挪到实际需要的地方才计算。

修改后(40次+3次)：

Single方法的调用还可以进一步优化(配置List转换为Map，然后for循环内按Key查找)。

更新忍者状态的NinjaController.UpdateNinjaState也有类似的现象：

初次加载忍者技能、忍者课程修炼也是如此：

其他模块的List  ConfigUtil.Get()调用，建议按需修改。

问题2：MaouOutline的数组重置操作

为达到更佳的描边效果，重写了ModifyMesh/ModifyVertices的实现，而MaouOutline脚本又频繁出现在各个界面。影响范围较广。

修改前：

发现主要消耗是在重设数组长度。将vertexs数组初始化时指定初始长度，性能可小幅度提升。

经实测，List vertexs =newList(256);

指定初始长度为256，比128或512或其他都好一丢丢(减少了SetCapacity(Array.Resize)的消耗，但同时增加了List构造函数的消耗)。

第一次修改后：

进一步修改，调整为静态全局数组，就不会每次都重置数组长度了：

第二次修改后：

MaouOutline的ModifyMesh/ModifyVertices已经没问题了，但是Unity自带的Outline的ModifyMesh仍然有重置数组长度的现象。

经排查，发现TaskItem有两个按钮Text使用了Outline而非MaouOutline。于是将所涉及prefab的Outline脚本全部替换成MaouOutline脚本即可。

Outline替换为MaouOutline后：

到此GC Alloc基本解决了(0.9M=>22K)。

但进一步又发现，剩余的耗时问题集中到了ModifyVertices(每次ModifyVertices调用都会触发8次ApplyShadow调用)，此问题待解决。

问题3：GameObject.SetActive(ture/false)引起的毛刺，即使并没有实际改变true/false的状态，也会有额外的消耗。

建议封装一个静态方法：先判断GameObject.activeSelf当前状态，然后再作GameObject.SetActive(ture/false)修改状态。

对于在业务View初始化方法中只作一次GameObject状态初始化的，可以不做修改。

对于操作时会变更状态的(比如赌小游戏滚动前后的按钮状态切换、奖励展示切换)，建议增加判断。

已封装为UIUtil.SetActive(GameObjectgo, bool v)，可直接使用。

修改前：

修改后：

赌小游戏已修改，其他模块可按需修改。

比如排行榜的一个条目：

问题4：B.GetView=>B.OnShow=>A.OnHide

界面切换会有新界面(B)的GetView和OnShow，以及旧界面(A)的OnHide，而这里的多次SetActive(true/false)会引发多个脚本OnEnable/OnDisable。

现象：

一次SetActive(true/false)会引发上百次的OnEnable/OnDisable：

两个建议：

(1)对于Instantiate创建的VIew，无需默认设为SetActive(false)，因为马上就OnShow=> SetActive(true)了。

(2)对于需要频繁显示和隐藏的常驻VIew(比如TitleBar之类的)，OnShow和OnHide中除了使用SetActive(true/false)外，也可考虑position移入移出屏幕，或者设置Scale为1或0等等。

但是需要注意，应该增加忽略隐藏状态下业务逻辑的代码。

问题5：可疑的Graphic.Rebuild=>Text.OnPopulateMesh=>Font.CacheFontForText

初始化或更换Text.text的文本，会引发Text.OnPopulateMesh，有时还会引起Font.CacheFontForText=>TextUpdateGeometry(耗时)和Text.cachedTextGenerator(GC Alloc)。

Image也有类似现象。优化方法待思考。

问题6：可疑的Tx.OnUpdate

这里的大毛刺使得战斗开场那一帧比较卡，看到界面显示一个空的战斗场地，等一两秒后才有人物跳出来。

由于Profiler信息量太大，无法使用DeepProfiler查看详情。

通过添加Profiler代码定位，最后定位到Tx.OnUpdate()里的tx_object_unity_update();，然后线索就断了。

真实原因待查。

添加了Profiler辅助方法：

其中加载了许多图标，包括忍者头像、战斗上阵的人物等。如果原因是资源尺寸过大，可考虑能否裁剪成多张小尺寸的。

问题7：可疑的Text. preferredWidth

在普通副本和精英副本切换时，发现有一个可疑的Text. preferredWidth，它会触发Text.cachedTextGeneratorForLayout，从Profiler看似乎是申请了一个长度较大的List。

经走读代码发现该行代码实际是不需要的，于是直接注释掉。

另全量搜索发现其他脚本也多处出现Text. preferredWidth，还需逐一排查。

问题8：可疑的Component.GetComponentFastPath

进入某些列表界面(比如任务界面)，初始化MaouGrid组件时会调用SetParent。

而SetParent会触发一些Unity自有脚本(比如MaskableGraphic)的OnEnable/OnDisable的成倍调用，耗时和GC Alloc累积起来也比较可观。

切换SetActive(true/false)也有类似现象。

展开MaskableGraphic.OnEnable/OnDisable，最后落到Component.GetComponentFastPath，此方法耗时和GCAlloc原因待查。

问题9：debug信息输出导致的额外损耗

VersionView每一帧Update()都在刷新帧率，导致过渡频繁的字符串Format和Concat

建议修改为StringBuilder，而固定字符串(版本信息字符串、网络状态字符串)可改为分别用单独的UI.Text显示，每次只刷新变化的数据(比如帧率)。

(优先级较低，暂时可忽略，且正式版本会屏蔽)

另一个可疑的debug信息(PrettifyProto.ToStr和LogUtil.WritePre)，常见于一些回包中，也可以考虑处理一下：

问题10：界面加载和界面刷新时的耗时

界面加载时有较多的资源加载。比如通灵兽界面：

又比如任务界面：

领取任务奖励后，任务条目更新又有一些耗时的刷新操作：

经分析，这里每次都会先Hide(全部)，然后Show(其中某几个)，可考虑优化。

问题11：切换普通副本和精英副本，会有瞬间的白屏

问题12：图标加载时有额外的字符串操作消耗。

比如副本介绍界面的奖励图标加载(除了字符串操作，还有一个可疑的IdUtil.TryGetId)：

或者任务条目的奖励图标查询(除了字符串操作，还有一个可疑的Behaviour.set_enabled)：