Unity手游的性能问题一直是被业内视为诟病，腾讯公司内部的TDR评审就是一个专门针对技术细节进行专家团评估的环节；早期的TDR评审关注的是内存是否超标、CPU是否饱和、网络流量是否过大等数据，经过近几年手游浪潮的洗礼，现在评审过程中会更加注重细分问题的研究和排查。
如果说左边是玩家经常会遭遇到的表面现象，那右边则是基于Unity引擎深挖后的问题本质。 它们对游戏的具体影响是什么呢？就拿最近比较火的《王者荣耀》来举例，我们有幸参与了它上线前后的几个优化版本的分析，先后遇到过的问题和优化方法主要有下面几个：
1.由于实时对战游戏的数据包数量巨大，早期版本的帧同步策略会导致比较明显的卡顿，通过进行数据包的合并与优化逐渐解决了卡顿问题；
2.频繁创建和销毁的小兵对象让CPU爆表了，大量的小兵如果采用实时内存的分配和回收，会产生大量的内存碎片和系统开销，解决方法之一就是采用高效的对象池进行优化，对每个内存对象的状态进行操作即可；
3.性能分析过程中，发现单人同屏和多人同屏时的开销都很大，通过视野裁剪技术，使得玩家视野外的不必要的特效和渲染可以全部关闭，极大降低了CPU、GPU和内存的开销；
4.在高中低三档机型上玩游戏时，分别加载不同层次的特效包，这也有助于降低CPU和内存的开销；
5.游戏内界面采用了UGUI的方式实现，但大量的实时UI变化使得副本内每帧会有230以上的drawcall，导致中低端机型感受到明显卡顿，最终采用UGUI+自研究UI的组合拳，重写了一套紧密结合游戏自身特性的UI来实现战斗血条和浮动文字的效果。
性能优化的N种武器作为一个以性能优化为己任的工具类产品，Cube不仅致力于问题的发现和定位，也希望为开发人员提供更多更实用的性能优化方法。
贴图：
l 控制贴图大小，尽量不要超过 1024 x1024；
l 尽量使用2的n次幂大小的贴图，否则GfxDriver里会有2份贴图；
l 尽量使用压缩格式减小贴图大小；
l 若干种贴图合并技术；
l 去除多余的alpha通道；
l 不同设备使用不同的纹理贴图，分层显示；
模型：
l 尽量控制模型的面数，小于1500会比较合适；
l 不同设备使用不同的模型面数；
l 尽量保持在30根骨骼内；
l 一个网格不要超过3个material；
动画：
l N种动画压缩方法；
l 尽量减少骨骼数量；
声音：
l 采用压缩MP3 和 wav；资源方面的优化：
l 使用 Resource.Load 方法在需要的时候再读取资源；
l 各种资源在使用完成后，尽快用Resource.UnloadAsset和UnloadUnusedAsset卸载掉；
l 灵活运用AssetBundle的Load和Unload方法动态加载资源，避免主要场景内的初始化内存占用过高；（实现起来真的很难…）
l 采用www加载了AssetBundle后，要用www.Dispose 及时释放；
l 在关卡内谨慎使用DontDestroyOnLoad，被标注的资源会常驻内存；
代码的优化：
l 尽量避免代码中的任何字符串连接，因为这会给GC带来太多垃圾；
l 用简单的“for”循环代替“foreach”循环；
l 为所有游戏内的动态物体使用内存对象池，可以减少系统开销和内存碎片，复用对象实例，构建自己的内存管理模式，减少Instantiate和Destory；
l 尽量不使用LINQ命令，因为它们一般会分配中间缓器，而这很容易生成垃圾内存；
l 将引用本地缓存到元件中会减少每次在一个游戏对象中使用 “GetComponent” 获取一个元件引用的需求；
l 减少角色控制器移动命令的调用。移动角色控制器会同步发生，每次调用都会耗损较大的性能；
l 最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息；
l AI逻辑通常会生成大量物理查询，建议让AI更新循环设置低于图像更新循环，以减少CPU负荷；
l 要尽量减少Unity回调函数，哪怕是空函数也不要留着；（例如空的Update、FixedUpdate函数）
l 尽量少使用FindObjectsOfType函数，这个函数非常慢，尽量少用且一定不要在Update里调用；
l 千万一定要控制mono堆内存的大小；
更多unity2018的功能介绍请到paws3d爪爪学院查找。链接https://www.paws3d.com/learn/，也可以加入unity学习讨论群935714213
近期更有资深开发人士直播分享unity开发经验，详情请进入官网或加入QQ群了解