cocos creater H5游戏优化

H5游戏注重加载速度，让用户以最快的时间进入游戏，然后可以立即体验游戏。

H5版本的优化，大方面来说以下几点：

具体可以细分为以下几个：

优化文件结构，就是说，要把游戏中之一眼展示给玩家的，玩家可以立即体验的游戏资源预先加载，像logo，主界面资源，这些图片都是需要进游戏之前加载的。另一些资源，比如音效，特定状态下出现的特效，可以在进游戏之后再进行加载。这样可以缩短玩家进游戏的时间。一定要注意一个原则问题，就是玩家不能卡住，或者不能卡住太长时间，否则会大大影响到体验，导致用户流失。减少打包后生成的文件数，则可以减少游戏的请求数。文件太多会增加请求数，并拉长单个文件下载前的等待时间，尤其是特别小的文件，可能下载只要几毫秒，但是因为请求数多，要等待几百毫秒；减小单个文件的体积，因为大文件会拉长下载时间，所以大文件要根据实际情况拆分，这个优化点要在打出包之后看实际加载情况来定；图片采用压缩方案来缩小图片体积，点击这里查看；音效采用单声道，并降低码率，缩小音效体积；预制体采用延迟加载策略；频繁创建和销毁的组件使用对象池或者重复使用，点击查看重复使用item的例子；代码优化，游戏的逻辑优化（这方面的优化就要看个人的编码水平了，主要的优化点就是减少组件的创建和销毁，尽量使组件可以复用）。 优化文件结构

优化文件的工作如何验证已经做好了？打包之后（一定是打包后），在浏览器的开发者工具里查看一栏，并勾选上 cache选项，然后自己搭建一个本地服务器，修改一下服务器的下载带宽，模拟网络情况不好时的加载情况，这样你就可以清晰地看到加载了多少资源进入游戏，进入游戏之后又加载了多少资源（服务器推荐使用nginx，修改带宽方法自己查）。

减少文件请求数

当把以上的工作做好以后，就可以开始下面的优化了。这里着重讲下减少请求数的解决方案。

想要减少请求数，我们先要搞清楚请求的文件都来自哪里。打出web-包后，有好多文件，我们来一一解答下。最外层目录的文件就不多说了，缺一不可，都是很重要的游戏启动文件，但也可以进行优化，在后面说明。

我们看一下res目录里面：有、raw-、raw-共3个文件夹。

：这个文件夹里有一些奇怪的目录，放着长文件名的json文件，这些是游戏场景，预制体，图片信息的配置文件；

raw-：这是游戏的图片，声音文件位置；

raw-：这是游戏默认的一些图片，粒子资源存放目录。

我们现从这3个文件夹入手。

文件夹

文件夹减少配置文件生成。减少配置文件生成需要在制作游戏时遵循一个原则，那就是官方文档里关于目录的解释：所有需要通过cc..动态加载的资源，都必须放置在 文件夹或它的子文件夹下。如果一份资源不需要由脚本直接动态加载，那么千万不要放在 文件夹里。所有放在里未被场景或者预制体文件引用，并使用cc..方法加载的文件（声音资源例外，引用不引用都是它自己，打包之后它只会消耗一个请求），打包之后都会在文件夹生成一个json文件。所以我们要尽量让资源被引用到，引用并不会消耗性能，使用cc.方法创建并add到节点才会消耗性能。像预制体，动画文件，一定要放在res目录。如果项目中使用cc..方法加载预制体，则放弃这种创建方式，把预制体引用到场景中，需要的时候再创建。在我看来，cc..方法只适用于播放音效，加载url图片（如微信头像）。图片只要有被引用到，放在res目录和目录都是可以的。

raw-文件夹

raw-文件夹存放声音和图片文件，一个声音文件就是一个请求，这个我们无能为力。图片使用图集，自动图集和都可以。但使用自动图集时要注意上面的问题，一定要把所有图片都引用到。否则放在目录下的未引用到的图片就会产生一个json配置文件。粒子图片无法打成图集，有一个比较好的优化方案，就是把粒子图片使用的图片转换成字节码，放到粒子文件.plist文件中（推荐使用 ），亲测web平台可以完美运行，原生平台不支持。

raw-文件夹

raw-目录我们可以完全去除掉。如果需要使用到的默认图片，则让美术同事做一张一样的图拿出来放在res目录或下。需要注意的一点，创建组件时，属性选到看一下，如果不把这边默认的图片都叉掉，就算选择了SCALE或者其它属性，依然会在打包的时候把默认图片打出来，导致请求的增加，游戏的增加。每一个都有这样的风险，所以一定要注意一下。项目中没有使用到默认图片的组件，在打包的时候自然就不会生成这个目录了。

外层文件优化进阶

在这之后又有了新的思路，点击查看H5优化方案进阶，文件的优化又做了一个小小的升级。

打包之后把.png图片和style-.css文件合并到index.html中也可以减少两个请求。方法如下：

把.png使用在线转换工具，把png图片转换成格式的长字符串，点击这里转换；把转换得到的字符串替换style-.css文件中的#中的的url内容，不用加引号，直接把./.png替换成上面得到的字符串；在index.html中找到对style-.css文件的引用位置，注释掉，并添加新的标签xxx，然后把style-.css文件中的内容复制，并替换掉xxx；把生成好的index.html文件放到build-文件夹中（不知道这是什么的，点击这里查看官方文档），如果文档找不到，可以在文档里搜索定制项目构建流程。

这样就成功把两个很小的文件又融入到了index.html中，减少了两个请求。

以上工作做完了，你可能觉得main.js，.js文件也可以放到index.html中，也不是不可以。但我们发布web版本，构建时一般都勾选md5选项，这样每次生成的文件内容可以会有改变，导致文件的后缀也会随着改变，放入模板中不太合适，所以在打包之后，追求极致请求数的同学，可以把main.js文件和.js文件也整合到index.html中。

延迟加载策略

延迟加载是什么？举个简单的例子，网页游戏进游戏之后，有些图片非常模糊，人物有的也可能就是个黑影身上加个问号，但是完全不影响游戏逻辑，你的游戏可以正常进行，并且看到随着时间的推移，图片慢慢变得清晰了，人物也都慢慢出来了。这就是在延迟加载，不会影响到游戏的进行，但是显示上可能和正常的游戏不一样。的H5版本，一些预制体如果不勾选延迟加载，则会卡住游戏。再举个简单的例子，假如游戏里有很多特效绑定在一个预制体上，这个预制体上的图片有部分必须要在进入游戏之前加载，但是另一部份可以在进入游戏之后再加载。如果这个预制体没有勾选延迟加载，那么再调用这个预制体的时候，系统会去检测这个预制体上用到的图片是否已经全部加载了，如果没有，那就会卡住等待。如果勾选了延迟加载，就不会卡住，而是把已经加载的图片显示出来，未显示的图片会在加载完成之后自动显示出来。延迟加载策略可用于游戏玩法主场景的预制体，主场景玩法中必要的资源在进入游戏之前加载，特效资源进入游戏后加载，这样保证玩家不会在游戏环节中卡住，又可以保证加载速度快。

减少游戏

减少的办法有两个，打图集，优化游戏的场景组件结构。一般在打了图集之后，都能得到很好的控制。具体的介绍请移步官方文档。点击查看。

是衡量游戏性能的一个重要指标，是CPU对底层图形绘制接口的调用命令GPU执行渲染操作，渲染流程采用流水线实现，CPU和GPU并行工作，它们之间通过命令缓冲区连接，CPU向其中发送渲染命令，GPU接收并执行对应的渲染命令。影响绘制的原因主要是因为每次绘制时，CPU都需要调用而每个都需要很多准备工作，检测渲染状态、提交渲染数据、提交渲染状态。而GPU本身具有很强大的计算能力，可以很快就处理完渲染任务。当过多，CPU就会有很多额外开销用于准备工作，CPU本身负载，而这时GPU可能闲置了。

我们可以通过使用相同的材质、贴图、来合并以减少CPU负担。

提供了自动合并图集功能的auto atlas，只需要在纹理所在文件夹创建一个auto atlas即可。

然后在属性框点击便能看到自动产生的图集。

注意如果纹理文件夹存在嵌套情况，外层文件夹的auto atlas会包含子文件夹中的纹理，因此要避免子文件夹创建auto atlas产生重复多余的资源

如果auto atlas未包含任何图片，打包发布时会报: pac is not 的错误。可通过点击auto atlas的按钮查看哪个报的错

虽然auto atlas用起来很方便，开发过程中增减贴图不需要手动去调整图集，但也有局限性：

可控性弱，如果同个文件夹上贴图比较多，或者存在子文件夹，自动产生的图集组织方式可能并不是你所希望的。需要细划并分归类每个文件夹中的贴图。产生的图集是未经过严格压缩的，通常情况下能使用第三方图片压缩软件减少四分之三左右的存储空间。虽然非原生平台发布，可以选择打完包后将图集进行压缩后拖进ZIP包，但每次打包发布都需重复上述操作。只有打包后才会真正产生并使用自动图集，因此开发过程中用的还是散的贴图，无法真实的查看指标。

如果项目处于后期优化阶段，并且之前用的是散图，那么auto atlas能快速降低游戏。

如果项目尚处初期，还是建议使用传统的开发流程。

渲染顺序会影响到的合并，类型的物体，一般引擎都会进行排序，使相同材质的物体在同一批次渲染。然而类型的物体，为了显示的正常，渲染顺序严格按照在场景中从后往前的顺序渲染，即跟中node的有关。如果相同材质UI之间存在其他材质的UI，则合批会被打断。

node作为最基本的组件，集成了过多功能，以至于失去了一些灵活性，与U3D的、UE4的actor不同的是node参与渲染排序。默认情况下按场景中node从上到下顺序渲染。 我们可以通过node的调整渲染顺序

/**
     LocalZOrder is the 'key' used to sort the node relative to its siblings.
     The Node's parent will sort all its children based on the LocalZOrder value.
     If two nodes have the same LocalZOrder, then the node that was added first to the children's array will be in front of the other node in the array.
     
     Also, the Scene Graph is traversed using the "In-Order" tree traversal algorithm ( http://en. *** .org/wiki/Tree_traversal#In-order )
     And Nodes that have LocalZOrder values < 0 are the "left" subtree
     While Nodes with LocalZOrder >=0 are the "right" subtree.
     
     @see `setGlobalZOrder`
     @see `setVertexZ`
     *
     * @param localZOrder The local Z order value.
     */
    virtual void setLocalZOrder(std::int32_t localZOrder);

是 “key” (关键)来分辨节点和它兄弟节点的相关性。 父节点将会通过 的值来分辨所有的子节点。 如果两个节点有同样的 ，那么先加入子节点数组的节点将会显示在后加入的节点的前面。 同样的，场景图使用 “In-Order（按顺序）” 遍历数算法来遍历 ( #In-order ) 并且拥有小于 0 的 的值的节点是 “ left ” 子树（左子树） 所以拥有大于 0 的 的值得节点是 “ right ”子树（右子树）。

以上是cocos官方翻译，In-Order应该是指二叉树中序遍历，但在实际测试中并不是按左节点->父节点->右节点的顺序渲染，而是按父节点->左节点->右节点的顺序先序遍历的。

因此先渲染父节点，同一父节点下的子节点之间的渲染顺序遵循从小往大的顺序渲染。至此我们尽量保证相同材质球的节点紧挨着渲染，避免穿插渲染造成无法合并。

正确做法：

A B B B B C

错误做法：

A B B C B B

在处理排行榜等多Item UI时，我们通常把Item做成，然后顺序添加形成如下结构：

B B B B C C

B B B B C C

B B B B C C

以上共有两个材质B和C，因此我们希望只产生两个。由于中空的父节点也会参与排序，所以无法通过使不同父节点下的B合并成一个批次。曾尝试过使用然并卵，.d.ts中也无该接口导出，可能中已经废弃。所以上述三个Item至少产生六个。随着屏幕可显示Item数量增加而增加。

v1.x版本还需注意的是Color或不同无法批处理，和非共用同一贴图无法批处理，为0的节点仍占用，使用系统字体的Label无法批处理等。其中某些已在后续版本中修复

对于游戏中频繁创建销毁的物体使用进行管理

对于元素个数比较多的可参考引擎自带的例子，滑动过程中动态设置元素，实现元素资源重复使用。

系统字特别耗性能，使用内存占有小的TTF或者字体图集代替。

原生平台下避免频繁的本地存储。

性能分析