手游优化方法汇总

1、减少重复计算

• 换高效的算法
• 避免多次运算， 例如减少循环中计算
• 利用空间换时间，将常用运算结果缓存

2、合理使用数据结构

不同数据结构的增删改查消耗得性能是不同的，合理利用数据结构，避免计算上的浪费。

3、减少复杂调用

• 将轮询方式修改为事件驱动，比如将在update中状态监听，改为事件触发
• 将节点递归更新修改为有效路径更新，例如UI树
• 不同对象和状态有不同的逻辑帧数，比如小兵的逻辑帧数有60帧，而建造中的建筑逻辑帧只有10帧
• 降低耗时运算，例如深度排序和视野计算都可以降低到一般人觉察不到的频率
• 预处理结果，比如在游戏启动阶段或者loading阶段预先计算
• 拆分运算量，比如加载200个建筑，可以拆分到多个帧去完成。接收到大量的服务器包也可以同样这样处理，防止卡顿。
• 按需加载，比如只加载一个建筑的某一方向的资源
• 异步运算，如多线程收发消息包，多线程加载资源，异步解压，异步渲染

4、丢弃部分效果

• 丢弃部分效果，减少战斗特效
• 自动动态调整FPS，以低帧率性能消耗表现高帧率效果

内存性能原因主要有这几点：内存碎片过多 、内存频繁创建销毁、内存加载慢、内存占用过高。

1、使用内存池，减少内存碎片

使用一个全局的内存池，所有对象的分配和回收都由内存池来控制。

2、采用对象池，减少频繁创建销毁

游戏在场景切换时，需要销毁和创建大量的建筑，因此，将创建出的建筑使用对象池来进行管理，创建建筑时会先从池子里面取，临时不使用的建筑会根据池子大小选择回池或者销毁。

对象池适用于频繁创建和销毁的对象，现在大部分游戏都有自己的对象缓存机制，例如打飞机游戏中的满屏的子弹和敌机，酷跑游戏中的金币。有关对象池的介绍请自行谷歌。

3、及时释放无效内存

• UI界面关闭时，场景切换时释放
• 采用LRU动态淘汰缓存

• 图片压缩，ios为pvr，android为etc1，考虑方形图和alhpa贴图，内存占用大概是原来的1/4左右。
• 表格压缩，非常用的表格数据使用lzma格式压缩，在使用时才进行解压缩，对字符串效果特别好
• 脚本压缩
• 九宫格图片
• 降低模型面数
• 减少帧动画帧数
• 没有Alpha通道的图片使用jpg替换

1、减少渲染批次

cocos 的 auto-batching 只会对render queue 相邻且同材质的 command 进行合并。因此在拼UI时尽量让相同的控件相邻。

2、使用render to texture

对UI这种不常更新的元素，可以将其渲染到一张贴图上，这样整个界面就只有一个drawcall，仅当UI发生变化时才重新生成。

• 压缩，pvr和etc可以直接被GPU读取
• 预加载，将用到的资源在loading阶段加载，坏处是有些资源可能极少被使用到，白白占用内存
• 异步加载，但当加载量过大时仍会造成卡顿
• 大文件支持按需部分读取
• 资源整合打包，避免过多小文件操作。现在大部分游戏的UI资源都采用打包成大图，一是可以减少IO，二是可以利用工具裁剪图片的空白区域
• 将解析复杂的数据转化成易于读取的二进制数据

手游网络存的问题是网络流量有限和是网络波动大，经常中断。

• 合并小包，减少发送请求频率。
• 合理的数据结构定义，尽量使用占用少的数据结构，能用bool、char就不要用int
• 网络包压缩
• 服务器网络包合并下发，客户端分帧解析，防止大量网络包解析时出现卡顿
• 手游网络不稳定，因此需要有自动重连与协议重发机制，提供较为顺畅的游戏体验
• 合理的交互方式设计（避免频繁交互的方案），比如客户端和服务器使用相同的算法进行展示，或者让客户端进行演算，而服务器只是做检验

• 丢弃部分效果，丢弃特效降帧
• 降低亮度