一、 为什么要做性能优化？
性能：是一种优秀的能力。唤醒快、运行持久、稳定。
这种能力在游戏上能让你的用户感觉很爽，表征表现为加载快，手机不发热，运行流畅，不卡顿。所以，性能优化的终极目标是，让你的用户感觉很爽，当然这种爽你不能以牺牲自己为代价，要考虑成本和副作用（总不能频繁使用伟哥对吧）。
我们要优化性能，首先要搞明白是哪些因素会影响性能？是体力不行就得加强锻炼，是操劳过度就应该学会休息。点击链接加入群聊【Unity/Cocos交流群】
在我们的游戏中，哪些因素会影响性能呢？
二、 影响性能的因素有哪些？
如果大家不知道如何分析，那我给大家引导下。
当你玩游戏的时候，首先是不是要将你的游戏加载到内存。前戏太长，你肯定会等得不耐烦吧，不爽，是不是要优化。那么第一个问题来了，如何优化游戏加载速度（三、1），我们先记录下来，下面逐一讲解。
其次，你好不容易把东西放内存里去了，但是屏幕没任何东西，也不给你发出点声音。这体验不好！也就是说屏幕渲染游戏界面耗时太长，卡顿，需要优化，所以，第二个问题，如何优化渲染速度（三、2）？
最后游戏运行过程中，运行速度受什么影响？与设备内存、CPU、代码有关，所以我们要做内存优化（三、3）、CPU占用及性能优化（三、4）。
三、 性能优化从哪些方面着手？
1. 如何优化游戏加载速度【加载优化】
问大家一个问题，你一个8M的东西和人家一个1M的东西，你说谁会先加载进去？肯定是1M的，所以首先要想方设法优化包体大小。
【优化包体大小】的方法有哪些？
首先想下你的包体里面有啥？哪些东西占用的内存最大，哪些东西压缩的可能性最大？
项目路径下有res、scenes、scripts，还有游戏引擎，等。
简言之，包体的组成分为：资源和代码。
（1）资源：图片、声音、动画等。
避免大尺寸的图片出现：纯色图片或有规律的图片用一像素的图片表示，带圆角的按钮背景图片用九宫格形式展示。
另外有一点也要格外注意，cocos creator所支持的最大图片尺寸为2048*2048，超过这个尺寸的图片在显示时会有问题，常见于一些Spine动画打包出来后没注意资源图片尺寸，导致动画显示异常。
如果是地图资源超过2048*2048，常见于一些mmo项目，这种情况下，需要对地图资源进行切分，切分成小于2048*2048的若干图片，在游戏中再拼接在一起。
图片压缩：
图片的压缩格式：背景，jpg体积要小于png，背景图片jpg，很多图片格式，导出美术图后，这些图，仍然可以压缩。
百度搜索在线压缩图片，即可找到相应网站直接操作。
图片分辨率： 1920x1080 > 960x540，减少分辨率； -->降低了清晰度的；
尽可能的时候九宫格的图片，来代替一张整图按钮200x100， 300x100； -->大大的降低的图片的分斌率，这样就可以节省资源；
类似这样，将各个界面的美术资源、帧动画分类并且打包成图集也是比较好的处理方法，将资源进行模块化。这样在加载时，以及游戏运行时，会有以下几点好处：
1.提升加载速度
省去了多次打开/关闭文件所带来的时间损耗
2.减少文件的体积
多张图片合并到一起，在包体上面会有一定的优化
3.减少DrawCall
使用时，由于这些美术资源都是一起配合使用的，因此放在一张图集中，可以减少渲染的DrawCall数量，对渲染的性能也有优化的作用。
同时在不需要使用这些资源时，比如说某个界面 不需要再显示时，可以将这个界面的资源统一释放，避免占用内存。
另外通用资源可以统一打包在一张图集中，让这些通用的常用资源常驻与内存，方便使用。避免频繁的重复释放和加载。
同样，声音也可以采用相应方法处理。
音乐音效资源(压缩格式背景音乐的大小，音乐的数量，声道，采样率)。
如下是压缩后的音乐文件和压缩前的音乐文件大小对比，缩小为压缩前的十分之一了。
字库：
尽可能的不要自己带字库。
(1)特效文字，尽量使用位图字体，几个字母+图片，体积远远小于一个完整的字库，性能还要好，数字、界面的文字，例如我们的《极速赛车》中就是采用这种方案！
bmpfont -- .png + .fnt文件；
(2)尽可能的使用系统字库；
(3)字库可以压缩fontmin；特定的数量固定的文字；
(4)位图字与矢量字，哪个性能更好? ? ?
位图字：速度快，但是，内存大；
矢量字：速度慢，但是内存小；
【预制体】：
首先先说一下prefab在使用时的步骤：从文件中读取数据 → 反序列化数据 → 还原得到Prefab节点树 → 预处理 → 实例化
Prefab这块的加载优化主要集中在两个地方：一个是load加载耗时优化，另一个是实例化耗时优化。
①合理拆分Prefab
越大的prefab文件在加载过程中的耗时是越长的，而且通常不是等比，而是以类似平方曲线这样的去增加时长的。
例如读取一个100kb的文件，可能耗时也就10毫秒，但对于一个1M或者是2M的文件，我们在加载时就不是100毫秒，可能就是几百毫秒。
类似这样七八百kb的prefab文件，我们就要去思考一下，是不是里面的节点都必须做成一个prefab？
是否可以拆分成2个以上的prefab，通过拼接的方式组合？
一个prefab我们可以将它看作为一个功能模块，而功能模块并不是越大越好，而是功能职责越单一越好，遵循这个原则，我们可以对prefab做更好的拆分。
记住：职责单一原则，逻辑清晰，解耦，便于后期维护。加载快！！
②延迟加载资源
在场景处可以找到。
在Creator的资源管理器中点击编辑好的prefab资源，在属性检查器中我们可以看到延迟加载资源的选项。勾选这个选项可以减少prefab的加载耗时，但首次显示的耗时会增加。
这是由于勾选后，Prefab所引用的资源，像图片、音效这些，不会在load时加载，而是会在Prefab第一次显示的时候再进行资源的加载。因此需要根据具体的使用环境进行选择。
③选择优化策略
在prefab的属性检查器中，我们可以看到优化策略这个选项。这个也需要我们根据实际的使用情况进行选择。
当我们选择“优化多次创建性能”这个选项时，Prefab加载后会进行一个预处理的操作，这个预处理其实就是动态生成一些prefab的实例化代码，并把这些代码交给jit去进行优化。
这样在实例化时的耗时将会大大减少，相应的，在load时的耗时会有所增加。
当我们选择“优化单次创建性能”这个选项时，prefab加载后会跳过预处理的步骤，这样在加载时的耗时会减少很多，但实例化时的耗时会增加。例如一些固定UI界面，由于方便加载场景或者时进行功能划分，通常会做成prefab，这种prefab只会加载一次的，就可以选择这个选项，提升加载的性能。
需要注意的有一点：由于微信小游戏平台禁用了动态加载代码，类似eval这些不能使用，因此优化策略这个选项在微信小游戏平台是无效的。
（1）代码：
代码体积(引擎+业务逻辑代码) -大头在引擎。
解决方案：引擎：非常简单，你只要把不要的模块去掉就可以了，你要知道哪些模块是占体积多的，物理引擎，能不用的模块，就不用。【项目设置】-【模块设置】，只打包必要模块即可。能不用tilemap就不用，因为Cocos中有足够优秀的2D编辑器，可以替代tilemap，能用碰撞检测引擎就不用物理引擎。可以通过项目设置，去掉游戏中没有使用的功能模块，减少包体大小。如下图，将不需要的模块去掉，再打包。
业务逻辑代码一般我们也没法修改，你的业务逻辑差不多，但是，要注意一个95%以上的同学，都会忽略的一个事实：src文件夹内的settings文件。
其实settings文件大小是可以修改的。首先大家要搞明白它的大小是由谁决定的？ 如果你不搞清楚这个问题，你就没办法优化，即使别人告诉你这么做，你也会纳闷。所有需要代码加载的资源放到resources，否则坚决不放到resources文件夹内。因为程序不知道哪些资源需要加载，也不知道你什么时候加载，所以会一股脑在settings文件中建立资源的映射。如下图所示，将资源放在res中和将资源放在resources文件夹下，settings文件的大小对比。
注意：需要清空build再打包。
2. 如何优化渲染速度【渲染优化】
渲染方面优化主要集中在如何降低draw call上，draw call越多，渲染的压力也就越大，对应的帧率可能就会下降，正常情况下如果draw call超过100就有可能带来卡顿，所以要注意这方面的优化。
draw call：游戏场景里面物体，分几次提交给显卡绘制，这个次数就是等于drawall次数。
100个物体，100次提交给GPU，就是100个draw call。
draw call过高为什么会影响性能？
GPU：每次绘制我们的图像---》一次能吞吐一定数目的三角形的，如果你的draw call过高,每次绘制的时候，GPU本来可以一次吃更多的三角形，但是你没有让我吃饱，GPU性能没有发挥出来。
CPU：10个精灵，--》10张图片；每次渲染管道里面再绘制的时候，只能带一张纹理， 每个精灵的纹理对象，是不一样的， 所以无法合批()
到底什么样的能在一个draw call里面绘制呢?
mesh相同---纹理相同，shader要相同,参数要相同，draw call合批-- >绘制;
比如，10个物体：sprite1, sprite2, sprite3, label, 9宫格sprite, sprite;
推荐方法：
【1】合并渲染批次，降低 DrawCall，提升渲染性能
(1)使用自动图集或使用 TexturePacker 对碎图进行打包处理：只有图集内的精灵才有可能在一个draw call绘制→合批.这样操作的话，可以让多个 Sprite 渲染的纹理都是同一张图集图片，合并这些 sprite 的渲染批次，就可以减少 DrawCall 以及 CPU 的运算开销。
(2)合批的时候，尽可能的不要打乱了合批：例如上面label的出现打乱了sprite的结构，就不能合批。
(3)为什么label会单独做一个draw call？ 文字会绘制在纹理中。
(4)资源处理，减少 Mask 组件数量：由于 Mask 组件需要在 stencil 和 content 前后都添加修改 gl 状态的 render command，因此使用 Mask 会打断我们的 DrawCall 批处理。
对于一些特殊的显示，例如圆角的 icon 等，如果条件允许，尽量不要使用 Mask 组件来进行处理，而是通过对资源进行处理达到同样的效果。
目前 Mask 组件、Spine 组件、DragonBone 组件都会打断批处理，在节点结构上我们要避免被打断的情况发生。
（5）复用节点，减少节点数：当显示或隐藏这个界面时，大量的节点会带来大量的 enable 和 disable 的开销。比如好友排行，假设有1000名好友，没必要设置1000个节点，设置一页显示的节点即可，之后更换这些节点的显示内容。
最快的办法就是合并碎图成图集，然后同一图集的按照顺序摆放节点，中间不能插入其他图集的节点。
3. 内存优化
静态资源的内存管理：
静态资源指的是场景中直接或间接引用到的所有资源（脚本动态加载的资源不算在内）。
在场景资源的属性编辑器中可以勾选“自动释放资源”选项，从而在切换场景时，会自动将旧场景使用的静态资源释放掉，从而节省内存的占用。
动态资源的内存管理：
动态资源统一使用cc.loader进行资源的加载以及管理。参考：动态加载
要注意的一点是，CocosCreator中通过cc.loader去加载资源的所有方法，都是异步的。所以需要在回调中，确认加载完成后才能使用资源。也可以通过cc.loader.getRes这个API去同步的获取资源，但需要对get到的资源进行检查，如果没有加载或者没有加载完成，则需要等待或者通过cc.loader进行加载。
这样的话整个代码会清晰一些，避免掉入JS的回调地狱中
例如：_loadRes = function(url, type, callback){
cc.loader.loadRes(url, type, function(){
if(!err){
callback(prefab);
}
});
}
Cc.loader.getRes
_createPrefab(url){
var prefab = cc.loader.getRes(url, cc.Prefab);
If(prefab !== null && typeof(prefab) !== "undefined"){
return cc.instantiate(prefab);
}
return null;
}
通过简单的封装两个方法，在使用时可以保持代码的整洁易读。
另外一点需要注意的是，当批量进行加载时，cc.loader也提供了onProgress回调，这个回调中的三个参数中。
totalCount并不是指的是加载的资源总个数，而是加载这个资源所需要加载的依赖项个数。比如加载一个SpriteFrame，它的totalCount就是3，这3个item分别为：json，texture2D和SpriteFrame。
所以当totalCount为0时，并不是代表加载资源总个数为0，而是意味着这些资源已经加载过在内存中了，可以直接使用。
复用一切可复用的对象
最后是内存使用的一个理念：复用一切可复用的对象。
复用，并不仅仅是为了节省对象在alloc造成的开销，更重要的是避免GC时带来的额外开销。
像一些战斗中的掉血数字，敌人的血槽，怪物，子弹，英雄头像等等，都是我们常常回去做复用的地方。
对于常见一些复杂对象，我们可以使用对象池NodePool进行复用
对于基础的对象我们可以直接进行赋值从而达到复用的目的。
1. CPU及性能优化
1、绝对避免游戏中出现死循环。
2、控制游戏帧率。
3、H5游戏，JS代码级别优化
for(var i=0,len=arr.length; i<len; i++){
}
4.JS异常捕获
Try_catch
一单抛出异常，效率就会直线下降。尽量避免在for循环中try。。
5.全局变量的使用要慎重！！
6、优化节点树，减少节点数量。
7、场景中不要挂载过多的Prefab，可适当将一些Prefab变成动态加载的。
四、 性能优化应注意什么？
效率、成本。不要花百分之九十的时间、成本去尝试获取百分之一的性能提升。
很多时候，需要两害相权取其轻。点击链接加入群聊【Unity/Cocos交流群】
网友评论