【cocos creator】游戏优化，内存，性能，包体积大小，加载，drawcall优化

参考：

https://blog.csdn.net/qq_47012987/article/details/140169024

内存泄露排查

• 使用chrome测试cocos creator内存泄漏问题
• 手游内存优化
• cocos creator优化
• Creator资源自动释放逻辑：所有 cc.Asset 实例都拥有成员函数 addRef 和 decRef，分别用于增加和减少引用计数。一旦引用计数为零，Creator 会对资源进行自动释放(需要先通过释放检查)自动释放资源
• • 事件注册了在deatroy没取消注册
• • 闭包引用外部数据，未清理
• • 【loadAny】【loadRemote】【load】等方法加载的资源需要自己手动卸载
• • removeFromParent时候节点未销毁，只是从父节点移除
• • 节点池不用时候未清空
• • bundle加载后未卸载
• js
  – js内存回收机制，标记清除逻辑，在代码执行过程结束之后，把还在被上下文变量引用的变量标记去掉标记。在清除阶段再把具有标记的内存对象进行整体清除，从而释放内存空间。有引用时候不会自动清理
  -闭包里面如果有log引用了闭包外的变量，也会导致变量不会自动回收
  js垃圾回收机制，内存泄露处理

##包体积优化：
打包构建时候配置，没有使用的到模块可以去掉

性能优化

• 使用对象池，特别适用于需要频繁生成和回收对象的场景，不用了记得及时回收，控制对象池数量上限，防止内存占用过大
• 滑动列表复用
• log过多影响性能，不必要的log去掉

优化资源加载

• resources文件夹里的东西会提前加载，所以不要在resources里面放不必须的东西
• 非主要玩法的资源可以放在ab包里，使用时候再加载使用
• 分帧加载，多个物体加载，逐渐显示
• 延迟加载。使用资源时才进行加载，而不是在游戏启动时一次性加载所有资源。这样可以减少初始加载时间，提高游戏的启动速度。可以使用场景切换或事件触发时进行加载。
• scene场景里放的东西如果很多，可以拆分成多个预制体，分帧加载
• 在游戏加载阶段预先加载一些必要资源，以减少游戏运行时的卡顿。

美术资源方面：

非半透明背景使用jpg
图片资源压缩
单张图片大小不超过2048x2048，大小过大的可分成多张图切
切图能切成九宫格就切成九宫格

spine动画优化

减少骨骼数量和复杂度，去除不用的骨骼
少用预乘效果（drawcall会+1）

drawcall优化

• DrawCall 是什么：
  简单来讲 CPU 准备好渲染数据，提交给 GPU 进行绘制的这个过程就是一次 DrawCall。

• 为什么减少 DrawCall 能提升游戏性能：
  首先，GPU 渲染图像的速度非常非常快；而 CPU 的内存/显存读写、数据处理和渲染状态切换，相比 GPU 非常非常慢。大量的 DrawCall 会让 CPU 忙到焦头烂额，而 GPU 大部分时间都在摸鱼。
  因此，若一次性将更多渲染数据提交给 GPU，减少 CPU 的工作时间，就能提升游戏性能。

• 什么是合批：
  简单来说，组织更多渲染数据提交给 GPU 的过程，称之为「批量渲染」，简称「合批」。

动态合批被打断原因

cocos creator 动态合批逻辑：
能在项目运行时动态地将贴图合并到一张大贴图中。

• 深度优先，遍历每个节点字节点，相邻的渲染数据一致可以合批处理
• 影响合批因素：节点颜色，透明度，材质，不同图集，label，group分组不同
• mask不支持合批，且占用两个drawcall
• 支持动态合图的渲染组件：Sprite、Label ( BITMAP 模式)。
• 微信小游戏会默认关闭，需要手动开启
  cc.macro.CLEANUP_IMAGE_CACHE = false; cc.dynamicAtlasManager.enabled = true;
• 场景加载切换，动态合图系统会进行重置，SpriteFrame 贴图的引用和 uv 都会恢复到初始值。如果一直不切换场景，那么随着动态合图的数量增长，渲染效率可能会降低，适得其反。
• 动态合图最大张数为5张，使用完后会强制重建。
• 单张合图的大小为 2048*2048。(参与合图的图片单张任何一边不超过 512)
• 贴图的多个属性设置为非默认值会影响合批 (FilterMode,genMipmaps,premultiplyAlpha,flipY,wrapS,wrapT,pixelFormat等)

优化方法：

cocos处理：

• 使用自动图集：
  将同一界面的小图放在一个图集内
• 单个材质球最多支持6张贴图（手机普遍支持张数），如果单个场景东西较多，可分多个材质球，打包一同渲染
• 改变物体zIndex会触发重新绘制，可用setSiblingIndex代替
• https://blog.csdn.net/weixin_44053279/article/details/128946081
• spine之间可以合批，如果spine改变了图片属性（颜色透明度等），也会增加drawcall
• 无视层级多图渲染合批
• 江南百景图技术点一：MultiTexture实现
• 纹理合批
• 修改源码优化

label处理：
label 的Cache Mode有三种模式。

• NONE：每一个 Label 都会生成为一张单独的位图，且不会参与动态合图，所以每一个 Label 都会打断渲染合批。
• BITMAP：当 Label 组件开启 BITMAP 模式后，文本同样会生成为一张位图，只要符合动态合图要求就可以参与动态合图，和周围的精灵合并 DrawCall（注意 BITMAP 模式只适用于不频繁更改的文本）。
• CHAR：当 Label 组件开启 CHAR 模式后，引擎会将该 Label 中出现的所有字符缓存到一张全局共享的位图中，相当于是生成了一个 BMFont（适用于文本频繁更改的情况，对性能和内存最友好）。（整体不超过2048x2048）
  优化方法：
• label渲染模式为bitmap时，不会打断合批，需要为不常改变内容的文字
• 可用bmfont代替文字不多的字体（只需要数字，字母等特定文字的情况），bmfont也会参与动态合批
• char模式label之间相邻只产生1drawcall（所有的char模式label会被打包进一个单独的图集，场景切换时候销毁）

1、剔除
将不满足条件的对象整体移除，以下是实现算法：
I、视锥剔除：摄像机的位置和视角形成一个视锥体，只有位于视锥体内的对象才会被渲染。可以通过检查对象的包围盒（Bounding Box）是否与视锥体相交来判断对象是否需要渲染。
II、遮挡剔除：如果一个对象被其他对象完全遮挡，则该对象不需要被渲染。
III、背面剔除：对于封闭的几何体来说，朝向摄像机背面的面不需要被渲染。
IV、距离剔除：距离相机太远的物体不需要渲染。