在性能分析纬度上，以腾讯的TDR标准为例，在高中低三档机型上会有不同的标准，Cube在三档机型中做了自动的筛选和判定，便于开发人员能更加直观的发现问题。（如下图）
首先、在游戏场景内对于FPS、CPU、PSS的变化趋势是需要重点关注的；其次、对于mono这种只增不减的东西，当然也是关注的重点，mono堆内存的不断分配会直接导致PSS内存增长且不可逆；再次、对于和渲染有关的drawcall，也是手游需要关注的性能指标之一，drawcall太高会导致FPS陡降，造成视觉上的卡顿。
四．同类工具对比
MAT （Memory Analyzer Tool）的缺点：
需要导入HPROF文件再分析；
只能查看java层的内存情况，看不到native堆的详情；
xcode instrument 的缺点：
只能用于mac，ios；
只能查看C++ 或 object C 的情况，看不到mono堆的详情；
Unity Profiler 的缺点：
需要单独编译develop版本；
在PC上执行，没法捕获真机数据；
内存数据跟实际真机的数据差异很大、多的时候有几十M差距；
只能看到最近一段时间的数据，看不到总体的详情；
对于Unity大神和开发人员，你更关心的应该是详细的性能数据，都能满足你们。大神会说"我更喜欢看着Unity profiler直接调试啊"，那你还得腾出时间编译一个develop版本、还得重新跑一遍游戏、数据和真机还相差很多，关键是大神哪来那么多时间呢？
所以答案是肯定的，日常测试工作中加入了数据采集和数据分析功能，就可以提高很大的工作效率。
我们常见的产品质量改进流程无非是下面这四步：
1) 测试人员发现问题；
2) 提bug 给开发人员；
3) 开发人员编译develop版本；
4) 开发人员用Unity profiler 定位原因；
用Cube进行游戏测试能帮你省掉后面2个步骤，何乐而不为呢？
通常情况下，开发人员是间隔几个星期甚至几个月才会去做一次性能调优的工作，中间已经隔了N个版本，有很多问题会被埋的很深；基于"问题发现的越早修复成本越小"的硬道理，功能测试人员完全可以用Cube进行日常的版本功能测试，让Cube在后台默默的为你发现各种性能问题。
" 即插即用、无须编译无须嵌入SDK、真机运行数据；
" 提供mono内存分配信息和mono快照对比；
" 能看到整个测试流程中的所有数据，而不仅仅是某一段时间；
" 被误操作产生的对象拷贝数量；
" 函数开销排名；
" 关卡间保留的冗余资源；
五．性能优化的N种武器
作为一个以性能优化为己任的工具类产品，Cube不仅致力于问题的发现和定位，也希望为开发人员提供更多更实用的性能优化方法。
贴图：
控制贴图大小，尽量不要超过 1024 x 1024；
尽量使用2的n次幂大小的贴图，否则GfxDriver里会有2份贴图；
尽量使用压缩格式减小贴图大小；
若干种贴图合并技术；
去除多余的alpha通道；
不同设备使用不同的纹理贴图，分层显示；
模型：
尽量控制模型的面数，小于1500会比较合适；
不同设备使用不同的模型面数；
尽量保持在30根骨骼内；
一个网格不要超过3个material；
动画：
· N种动画压缩方法；
· 尽量减少骨骼数量；
声音：
· 采用压缩MP3 和 wav；
资源方面的优化：
使用 Resource.Load 方法在需要的时候再读取资源；
各种资源在使用完成后，尽快用Resource.UnloadAsset和UnloadUnusedAsset卸载掉；
灵活运用AssetBundle的Load和Unload方法动态加载资源，避免主要场景内的初始化内存占用过高；（实现起来真的很难…）
采用www加载了AssetBundle后，要用www.Dispose 及时释放；
在关卡内谨慎使用DontDestroyOnLoad，被标注的资源会常驻内存；
代码的优化：
尽量避免代码中的任何字符串连接，因为这会给GC带来太多垃圾；
用简单的"for"循环代替"foreach"循环；
为所有游戏内的动态物体使用内存对象池，可以减少系统开销和内存碎片，复用对象实例，构建自己的内存管理模式，减少Instantiate和Destory；
尽量不使用LINQ命令，因为它们一般会分配中间缓器，而这很容易生成垃圾内存；
将引用本地缓存到元件中会减少每次在一个游戏对象中使用 "GetComponent" 获取一个元件引用的需求；
减少角色控制器移动命令的调用。移动角色控制器会同步发生，每次调用都会耗损较大的性能；
最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息；
AI逻辑通常会生成大量物理查询， 建议让AI更新循环设置低于图像更新循环，以减少CPU负荷；
要尽量减少Unity回调函数，哪怕是空函数也不要留着；（例如空的Update、FixedUpdate函数）
尽量少使用FindObjectsOfType函数，这个函数非常慢，尽量少用且一定不要在Update里调用；
千万一定要控制mono堆内存的大小；
六．小结
性能优化就像海绵中的水，又或是内衣里的肉，挤一挤总会有的。同时，性能优化并不是一劳永逸的工作，而是一个漫长而具有挑战的任务；项目的各个阶段都会有性能上的问题，在用户体验的基础上持续进行打磨，持续保持产品的良好性能才能赢得好口碑。（和保持身体健康是一个道理）
Unity手游的性能优化过程更像是一门时空转换的艺术， 持续在CPU和内存之间取得一个平衡。空间不足时则需要释放一些无用数据，以获得更优的空间使用率；时间太长时就需要降低不必要的函数开销。例如在低端机上，为了节约有限的内存空间，静态加载的资源会相对较少，很大一部分资源通过动态加载和释放；而在高端机上则不用考虑空间的限制，可以一次性静态加载更多的资源，省去了不少loading和GC的工作，让游戏体验更加流畅。
版权声明：本文出自腾讯WeTest chunhe，51Testing软件测试网原创出品，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
