参考：
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、距离剔除：距离相机太远的物体不需要渲染。
