H5游戏的优化之路

优化一

我优化游戏大概有以下几个方面：
1.减少资源内存占用
2.减少计算
3.降低draw call
4.使用对象池
5.动态调整游戏帧率
一.内存中的资源占用：
1.使用适当的设计分辨率不要将设计分辨率定的太大 1136 x 640 足矣
2.不使用的资源及时释放

二.减少计算量
这个只能根据游戏来处理了，减少一些不必要的运算，使用更好的算法，一般的小游戏计算量其实都还好

三.降低draw call
1.将小图合成大图使用打图集的工具
2.Label使用BMFont
3.减少Mask使用
4.不要使用jpg图片
5.减少粒子使用
有些人可能会说明明这些都做了为什么Draw Call还那么高？

1.不同图集之间渲染被打断
合并draw call就是同一张图片渲染中间不能出现不同的纹理，如果一个场景中只有一张大图，场景中只有Sprite，那么draw call 肯定为1 (如果是使用自动图集的必须要发布出来才能生效)，如果场景中有两张大图，只有相同大图的node一起渲染，才不会打断draw call , 当图集A的所有Sprite 都在node 1 ，图集B的所有Sprite都在 node2就会只有两个 draw call，或者图集A的所有 Sprite 都在图集B所有 Sprite 的之前渲染也会只有两个draw call 。如果不同大图之间的Sprite对象交叉在一起渲染draw call就会变高。

2.相同层级中间穿插Label
如果多个Label使用的相同BMFont 字体并且在同一个node ，label与label之间没有其他的node，label的draw call也会合并，如果sprite之后有一个label，label之后又有一个sprite，这样两个sprite就不能合并draw call，label尽可能在sprite之后渲染或者放到单独的Node上。

3.使用Mask组件会打断draw call

四.使用对象池减少游戏过程中动态创建对象
游戏中多次出现的东西有加入对象池，比如一些游戏中出现的效果，游戏中的道具，游戏中浮现的加减分数，有必要就不用label，自己封装个对象，将0-9出成图片，打入大图中。

五.动态修改游戏帧率
我以前从来没有修改过游戏帧率，怕影响游戏效果，但是打出APP包，在一些手机上发热特别严重，玩一小会就感觉可以当暖手宝用，现在做的是一个休闲的小游戏，感觉对帧率要求不是很高，就把游戏中不显示动画的时候帧率设为45帧，有动画的时候把帧率设为60帧,使用的接口就是cc.game.setFrameRate();

六.动态移除游戏中的部分效果
我在游戏过程中启动了一个update，将游戏卡顿划分等级，我这边是，当连续6帧内，帧率低于50帧为一级卡顿，连续低于45帧为二级卡顿，我这个游戏背景上有很多的特效，将可以移除的特效放到数组中，检测到当前是几级卡顿就停掉对象的效果，还有就是如果有些效果可以用图片代替也可以在较为卡顿的时候给替换为图片，如果有些重动态修改了帧率，不要忘了将设置的卡顿帧率乘以缩小的系数。

优化二

1、引擎首加。
目前已经处理，引擎模块裁剪后是900KB+， 但settings文件有300KB. 还有一些其它加载。

2、场景/prefab等节点解析慢
根据官方解释，场景或者prefab的解析相对较慢。 建议把重复的节点删除，改为代码创建。
试过了，这个确实有效，但Cocos Creator的可视化编辑基本上就没卵用了。
另外，有一些复杂的界面，即使不重复的节点也很多的。 有点心累。

3、动画加载慢
这算是最大的一个效率优化点。 简单的动画要经过动画文件加载解析，动画相关资源加载，组装动画。。 最后才得已显示。 我们之前的动画是挂接到节点的Animation上的。 导致进场景很卡。
现在改为了第一次播放时加载。 进游戏房间快了很多。
但很明显这个动画组件的提升空间非常大。
4、合理规划图片资源结构，自动Atlas
加载时间过长最大的一个开销就是发起了太多的HTTP加载请求。 使用Atlas可以大大减少这个开销。 但为了避免前期不必要的加载。 最好做资源分类。 比如， 大厅的资源就放到一个Atlas中。 游戏的资源就放到另一批Atlas中。
4、资源压缩
我们使用了pngquat命令行，把web-mobile/res整体压缩了。 可以使加载量减少50%左右

以上就是我们做的优化。
目前看来，要想做到很好的加载体验。必须将场景分拆。 并且prefab的加载效率决定了我们不能大批量的使用

优化三：

1.资源分步加载
游戏和web界面不同，是有很多动画，图片资源，这部分的体积占了游戏的90%，如何处理好游戏资源的加载，这对游戏的加载速度体验很关键。
针对游戏的分为各个部分，模块，资源也可以相应的划分为各个组，egret在资源这块处理的很好，提供了RES这个模块进行资源的处理，资源分组。相应的，在游戏中，进行分步加载也变得更加简单。比如，我把游戏资源分为三个组，游戏主场景，比赛场景，以及一些二级弹窗资源，这样划分之后，就可以对资源进行分步加载。一开始进入游戏，只加载主场景资源，提高游戏启动速度，加快进入游戏时间，避免在加载界面停留过长而流失用户。进入游戏之后再进行加载比赛场景和一些二级弹窗。当然，这样做的话，也会有一些弊端，在二级弹窗和比赛资源还没加载完成时，这时进入比赛或者点弹窗，就需要一些处理，等待资源加载完成后再进入，可以采用promis异步，或者添加事件监听。这样会造成一定的体验不好，需要取舍。如果资源整体不大，就无需分步加载。
2.对象池
对一些复用的组件，建立对象池，这是一个很常见的做法，也是最需要做的事情。虽然现在浏览器的性能有了很大提升，但是，对于一低端机型，对象池还是很有必要。建立对象池，对一些重复使用的组件进行回收利用，而不是直接销毁，这对页面性能提升很大。这是因为js的垃圾回收不是及时的，如果在一些密集渲染的情况下，就会出现卡顿，设备发烫的现象出现，影响用户体验。
比如，我之前做的一个战舰战斗的场景，10艘战舰进行随机发射炮弹，鱼雷和火箭筒，还伴随着爆炸效果动画，轰炸的声音。这么多的图片动画渲染，对设备性能要求是很高的，在一些低端机上，会出现卡顿，发热现象。我统计过，webgl的drawcall达到了300+，这是一个很恐怖的数字，内存的占用也达到了一个恐怖的数字。总之，这是一个糟糕的用户体验。后来，我做了一些处理，写一个对象池，对炮弹进行复用，提升很大，卡顿，发热现象没有了，画面也流畅了，内存占用也大大减少。
3.屏幕适配
针对不同的机型，进行适配一直是件很头疼的事情。市面的手机太多了，各种不同尺寸的屏幕，还有一些刘海屏，全面屏，适配是很麻烦的事情。屏幕适配这块，egret提供一些见简单的适配方案，比如拉伸占满屏幕，按宽度适配，高度适配，缩放保持原宽高比。这些方案都有些不足，会出现图片拉伸变形，黑边等等问题。所以，手机端的适配最好的方法是背景拉伸占满屏幕，而里面的组件就按照相对位置进行摆放。所以，在设置各个组件位置的时候，就必须写相对坐标，而不是绝对坐标，在一开始就解决屏幕适配问题。
pc端的话，就更加麻烦，所以，我的处理是之间缩放占满屏幕。
4.其他一些小坑
图片资源一定要压缩，能压缩很多。之前美术提供的图片没压缩，一张图片就达到了2M多，几张图片就十几M，这加载速度肯定很慢。压缩之后，只有几十k，速度一下子就上去了。
对于图片进行合并，这是常规做法，但是需要注意的点是注意合图尺寸，手机端不要超过2048。目前发现在苹果6s和小米黑鲨手机上会出现图片加载黑块的问题。帧动画的合图也是。
还有就是，写界面时，划分一定要清晰，哪怕多写几个类也要分清楚，这对后期需求变更修改起来方便很多。都知道，需求变更这种事情是很常见的。