【小松教你手游开发】【unity实用技能】NGUI研究院之为什么打开界面太慢

http://www.xuanyusong.com/archives/2799

http://www.xuanyusong.com/archives/2925

NGUI打开界面太慢了，起初一直以为是unity的问题，最近经过我的全面测试我发现这和unity没有关系。一般一个比较复杂的界面大概需要150个GameObject  或者 UISprite 。我用NGUI直接载入发现竟然需要250多毫秒，仅仅只是两张小图。同样的GameObject 我用unity2d的Sprite载入只需要70多毫米，可见Unity2d的效率要比NGUI高多少。。我可能说的不完全对，因为U3D是闭源的，我只能猜测。

在普及一下基础知识。

C#

1

2

GameObjectgo=GameObject.Instantiate(Resources.Load(“prefabName”))asGameObject;

go.AddComponent<Test>();

 我想上面这一行代码，大家应该再也熟悉不过了。实例化一个Prefab，然后给它身上帮一条脚本。如下图所示，我用的是 红米作为测试机器。实例化对象我们可以拆成4部分。我用NGUI加载了150个UISpirte = 41 + 4 + 30 + 194 = 269毫秒，一般打开界面超过500毫秒的话用户就会明显感觉卡顿了。而我这个仅仅是一张图而已，事实证明NGUI加载太慢了，到底为什么这么慢？

 

1.Resources.Load

Resources.Load是一个”同步”耗时操作，Unity内部维护了资源的内存池，但是调用Load的时候Unity会自动的把Prefab上所引用的资源在加入内存池，它不会重复加载资源。也就是说当你加载相同的UIAtlas的时候，只会第一次比较卡。你可以试试一些线上的unity游戏，一般第一次打开某界面的时候要比以后打开此界面时间长一些。

2.GameObject.Instantiate

很多人认为加载慢的原因罪魁祸首是Instantiate()。其实我告诉你它的时间反而是最快的，上面的截图我相信就是最好的证明。第一次Instantiate要比以后执行Instantiate要慢一些，可能Unity在做一些特殊处理吧。

3.第一次添加脚本。

添加脚本一般会有两种形式，第一种是通过AddComponent<Script>的形式把脚本添加给游戏对象，还有一种是你的Prefab天生就带着这个脚本。无论哪种加载时间都是一样的。第一次加载脚本要比以后加载慢，我觉得应该是和Resources缓存池的原理一样吧。

4.第二次以后的GameObject.Instantiate 和 AddComponent<Script>

GameObject.Instantiate 就不用说了,它载入很快，这里要详细的说说Script。

对！导致于你界面打开慢的原因就是prefab上绑的脚本，罪魁祸首就是脚本。

AddComponent<Script> 以后 或者  Prefab上预先绑定的脚本。当你GameObject.Instantiate()同步方法执行的时候，并不是把脚本挂上去就完了，而它要等脚本里面的一些方法执行完毕才算结束。

脚本中有两个很典型的方法 Awake 和 OnEnable。当Prefab 用Instantiate()方法载入的时候，它的脚本必须执行完Awake和OnEnable两个方法以后才算完整载入。那么如果你的脚本这里面有一些耗时操作，那么必然载入会慢了。。

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

voidAwake()

{

for(inti=0;i<1000;i++)

{

 

}

}

voidOnEnable()

{

for(inti=0;i<1000;i++)

{

 

}

}

如果你在Awake() 或者 OnEnable()方法里面继续去实例化对象，继续绑定脚本，那么依然还需要把新实例化对象的 Awake()和 OnEnable()方法执行完毕才会结束。。。

这里并没有完，还有一个地方也会引起打开界面慢。代码中用Pubilc 声明的对象，然后是在编辑器拖拽赋值。

C#

1

publicGameObjectgo;

拖拽赋值，如果是资源很大的话unity需要load ，然而load就是一个同步耗时操作，那么它也会影响打开界面的时间。

如下图所示，NGUI里面 UISprite UITexture UILabe 这三个脚本上面都有 public 绑定的对象。 NGUI打开界面慢的罪魁祸首就在这里，我尝试把public 绑定的代码全部取消， 发现 20几毫秒 就载入完成了。。。 知道原因了，但是我们也没办法，因为不能随便乱改它的代码。。 

一定要把一个界面的所有GameObject做成一个Prefab，有些人不想用unity的Prefab，想通过一种规则程序运行时利用GameObject.Instantiate()  和 AddComponent<Script>  来生成界面的树状结构。我做过测试如果单纯加载一个Prefab和 代码动态生成对应树状结构 前者要比后者快30%左右。所以如果做UI编辑器的话，一定要先把Prefab生成出来，一定要只加载一个Prefab。

至于Unity 的Sprite载入 为什么要比NGUI的Sprite载入快，那么唯一可以解释的就是Unity可能后台用的是C语言，而NGUI用的是纯C#，从执行效率上C会快很多，所以我们还是早日期待Unity可以自身完美的解决做界面的问题。unity4.6预览版看起来很赞，不过我更期待unity5的到来。

最后我们在说说怎么让NGUI打开界面的速度能快一些。

1.修改界面结构，尽可能让界面上绑定UISprite UITexture UILabe这样的游戏对象少一些。

2.如果界面没法拆开，那么就把界面的prefab拆成多个，比如底框是一个Prefab ， 内容是一个Prefab ，列表是一个Prefab ，这样打开界面的时候用协同任务 一个一个打开，这样用户就不会感觉到界面卡顿了。。

3.期待您的补充。。

Unity3D做项目有三个地方处理不好游戏整体就会出现卡顿的问题。

1.NGUI直接打开界面卡，建议看看我之前写的这一篇文章 http://www.xuanyusong.com/archives/2799 （本文就不赘述了）

2.角色放技能的时候卡

尤其是放群体攻击技能时， 因为每个人身上都要产生一个技能特效。技能都是用粒子特效做的，虽然Unity中粒子特效也是一个GameObject.但是 Particle System这个组件太特殊了。Instantiate以后会自动的执行脚本的初始化工作，Particle System组件肯定也是个脚本，虽然我们看不到它实现的方式，但是Instantiate以后它定会先执行Awake()和OnEnable()一类初始化的方法。

经过我的测试发现，粒子特效真正慢的地方在于Play()的时候，Play内部肯定是启了协同一类的方法。因为根据粒子特效的原理，粒子特效其实就是个脚本，当播放的时候它会自动创建Mesh，从而生成它的运动轨迹。所以我们一定要控制同屏幕同时播放的粒子数量。

所以美术在做粒子特效的时候要注意3点

1.同屏的粒子数量一定要控制在200以内，每个粒子的发射数量不要超过50个。不然在iPhone4或者一些比较烂的Android手机上就会有问题

2.尽量减少粒子的面积，面积越大就会越卡。

3.粒子最好不要用Alfa Test（但是有的特效又不能不用，这个看美术吧） 、如下图所示，粒子的贴图用黑底的这种，然后用Particles/Additive 这种Shader，贴图必须要2的幂次方，这样渲染的效率会高很多。个人建议 粒子特效的贴图在64左右，千万不要太大。。

 

在回到粒子卡的话题上，Play()方法我们是控制不了的，所以我们能做的就是在播放Play方法之前让粒子特效所有的准备工作都已经完成。

1.粒子特效的GameObject实例化完毕。

2.确保粒子所用到的贴图载入内存

3.让粒子进行一次预热（目前预热功能只能在循环的粒子特效里面使用，所以不循环的粒子特效是不能用的）

1

2

3

4

//实例化粒子特效。

GameObjectnewGo=GameObject.Instantiate(go)asGameObject;

//把它的状态设置成隐藏

newGo.SetActive(false);

因为实例化粒子特效以后，实际上粒子的脚本就已经完成了初始化的工作，也就是Awake()和OnEnable()方法。然后设置SetActive(false)仅仅是把粒子特效隐藏起来。

上述操作完毕以后，让游戏中真正要播放粒子特效的时候，粒子不用在载入它的贴图，也不用实例化，仅仅是执行一下SetActive(true)。SetActive(true)的时候就不会执行粒子特效的Awake()方法，但是它会执行OnEnable方法。

3.载入模型的时候卡

一般在战斗场景，突然出现一大堆怪的时候， 屏幕会卡一下。角色的骨骼数量一定要少于30根，你可以用Profiler 里面看看，当你实例化一个动画模型的时候时间都卡在加载动画这块。如下图所示，在QualitySettings里面，一般手游我们都选择Good 选项，下面有一些别的选项，能关就关了，垂直同步也一定就关了。

如果要想游戏运行时不卡，我们必须要进行预加载，意思就是放技能或者出现怪物的时候，程序只需要SetActivie(true) 就可以了。但是你又不能预加载的东西太多，因为预加载和内存就像一把天枰，一旦预加载过多了你的游戏内存可能就爆了。

所以我觉得用Unity3D开发游戏，你必须要用缓存池。啥意思呢?

1. Instantiate 一个动画模型，这时候unity会先判断模型身上的资源是否在内存里，如果内存没有加入内存。

2.GameObject实例化完毕后，会同步执行它身上所有脚本的初始化工作，这里执行的不止是我们自己写的脚本，U3D自身的组件脚本也会初始化，比如动画这块很卡的地方就是Animation这个组件。

3.Destroy(gameObject)， 它不会把模型所用的贴图资源释放掉，但是它会把游戏对象和脚本释放掉。 啥意思呢？就是如果你再次Instantiate的时候，它不会再去载入模型所用到的贴图，但是它要执行脚本的初始化工作。我们不知道U3D内部组件脚本是如何初始化的，但是就自己写的脚本而言，它必然要同步执行Awake()和OnEnable()这两个方法，如果这里有耗时操作，那么必然会卡一下。

所以一些使用频繁的模型，不用的时候不要把它直接Destory掉，而是SetActive(false)。 这样当你再次使用的时候只需要SetActivie(true) 这样对应这个游戏对象来说 它只会执行OnEnable()这一个方法，所以载入速度是最快的。

所以我们用缓存池也是，在Loading进入战斗场景的时候，把频繁用到的模型，特效，全部Instantiate进去 SetActivie(false) 放入缓存池，当程序用到的时候在去池子里面拿，这样你就不会发现卡了。

缓存池你可以自己去写，不过网络上已经有一些缓存池的工具了。比如 PoolManager，这里我有做的详细的例子，http://www.xuanyusong.com/archives/2974 他是一个例子工程，写的很清晰。改一改就可以直接拿来用了，很方便。。

欢迎大家提出自己的看法， 我们可以互相讨论互相学习，嘿嘿。