联机Unity Profile技巧--mac

这里暂且讨论使用Mac对iOS设备进行调试的方法。至于Android平台，会有细节但不是非常重要的不同。

为什么需要联机Profile？

大部分情况，直接在工作机（PC、Mac）用Unity针对工程进行Profile就能查出性能的瓶颈。

但在不同的设备会有不同的性能表现、甚至一些设备由于硬件设计的原因，导致一些性能瓶颈只有在特定设备上才会表现出来。

针对这些设备相关的性能问题，需要进行联机Profile。

Profile的手段概述

iOS设备通过USB连接Mac后，对其进行Profile手段有三种：

Unity进行Profile



XCode进行Profile



XCode在debug模式时的“GPU Report”

3种Profile手段的特点

上面的3种Profile有以下特点：

Unity或者XCode的profile能准确地显示各项功能/函数消耗。

但这两种方式本身会引起大量的profile overhead，会引起设备上的“虚卡”，所以它俩的所描述的更多是功能/函数间的相对大小关系。
建议优先使用Unity的Profile，因为它的显示信息比XCode的Profile更加实用。

XCode的“GPU Report”开销较小，数据能真实地反应设备运行情况，所以能收集绝对的整体消耗大小。

3中Profile手段的具体步骤

Unity进行Profile准备步骤

通过USB连接调试设备和Mac
在Build Settings里如下图选择“Development Build”和“Autoconnect Profiler”，然后点击“Build”或者“Build And Run”



构建中途，Unity会调用XCode自动进行编译、自动进行运行。
设备运行我们的app了之后，在Unity打开Profiler面板，并且如下图选择“iOS profiler over USB”，也就开始进行profile了。



Unity进行Profile准备步骤结束。

XCode进行Profile

通过USB连接调试设备和Mac。

确保调试设备能够进行调试你的app

关于Apple Developer和Provisioning Profiles

一个apple developer有一个apple id
这个apple id下有不同的证书（certificates）。证书证明了这个apple id有能力进行软件的开发、分发。
这个apple id下有不同的app，每个app对应一个app id（也称bundle id）。表明这个apple id正在开发、分发哪些app。
这个apple id下有不同的设备，每个设备对应一个设备id。表明这个apple id关联了哪些设备。
这个apple id下有不同的Provisioning Profiles。一个证书id、一个app id和一个设备id列表，组成了一个Provisioning Profiles。意思是，“因为有了这个Provisioning Profiles，我可以用这些设备来调试这个app”。

所以，要成功让XCode连上你的设备并调试你的app，你必须拥有正确的Provisioning Profile。

更多可以参考Apple Developer官网里的“Member Center”。

在Unity进行Build了之后

在XCode打开相应的工程，如下图点击Product>Profile



XCode编译完了之后，会打开“Instruments”正式开始Profile调试

可以通过“Instruments”里面的“Library“来选择不同维度的Profile，比如“Activity Monitor”可以监控设备的各个进程情况、“Core Animation”可以监控帧数、“OpenGL ES Analyzer”可以监控图形API层面的调度情况。

XCode进行Profile准备步骤结束。

XCode进行“GPU Report”

大体的准备规则和上面的“XCode进行Profile”差不多，主要差别在后面几步：

Unity输出XCode工程后，在XCode打开相应的工程，直接点击“播放键”三角形；
当设备自动运行app后，点击下图左部的

按钮



XCode进行“GPU Report”准备步骤结束。

Profile的方法论

如何找到性能瓶颈

项目乃至人生，都是一个选择、试错、总结，再选择、再试错、再总结的循环过程。这个过程并非白费，而是提高自己的经验和能力，减少之后选择错误的几率。

通过Profile找出性能瓶颈的通用步骤如下：

通过功能Profile统计列表，找出占用CPU时间/GPU时间最多的“瓶颈功能”。注意一帧所消耗的时间=Max(CPU时间, GPU时间），而并非它们的和；
如果这个“瓶颈功能”是脚本函数等具体的、熟悉的功能，则已经确切找到性能瓶颈，步骤结束。
如果这个“瓶颈功能”是不具体的（比如“引擎渲染透明物体”、“引擎渲染cull预处理”就是不具体的），则继续执行以下“广度遍历尝试”步骤:
对游戏以不同维度进行拆分，以达到不同功能维度之间可以不相干地切换“ON/OFF”状态。注意，选择哪一种维度进行拆分是关键的；
进行多次尝试，每次尝试只有一个维度在“ON”状态、其他维度在“OFF”状态；
统计众多尝试中，最影响性能的维度A；
将维度A进行子划分，重复第4步，直到找到确切性能瓶颈。
如果维度A优化掉后效果依然不达标，则重复到第1步。

找到性能瓶颈后该怎么处理

处理方法可以有以下方法：

无损处理：进行优化，让性能瓶颈优化成在任何情况下都不出现。比如算法优化、内存访问优化等。
有损处理：可能受限于运行环境，无损处理不可能完成，这需要有损地进行处理，让性能瓶颈在特定情况下才不出现。比如Camera距离LOD、设备功能LOD等。

具体Profile案例（Killer Project）

2014-08-10

问题

策划要求敌人批量刷出至少15个，但在iPhone4上，15个敌人已经很卡。

目标

出现瓶颈的设备：iPhone4。目标帧率30fps，所以目标帧时间为33.33ms。考虑到iPhone4是低端机型，允许偶尔降到20fps，所以允许帧时间偶尔达到50ms。

Profile步骤

使用Unity进行联机Profile，发现渲染透明物体是性能瓶颈。



尝试过把场景里的透明物体都去掉，效果不明显



所以依次进行了以下“ON/OFF”的尝试。除了寻找真正瓶颈透明渲染之外，中间还输出了其他的结论点

特性	帧数	CPU时间	GPU时间	结论	可能美术解决方案	可能程序解决方案
场景OFF、15小兵	12	80ms	39.7ms	CPU瓶颈：小兵占用过多CPU；小兵刷出时依然占用较大CPU	减少小兵骨骼；减少小兵动画帧数；	减少小兵trigger节点；场景加载后进入场景前，进行小兵在SpawnPool里的预创建
小兵OFF、场景	29	29.8ms	33.5ms	无瓶颈：madfinger的天空盒效率甚高；	无	无
小兵OFF、场景 去除所有shadow cast	30	23ms	32ms	去除shadow cast/receive可以较好提高CPU效率	需要给mesh都去掉shaodw cast/receive	无
场景、15小兵	6	180ms；	176ms	最初情况。场景单独OFF没问题、小兵单独OFF问题不大，但他们同时出现却有大问题。	见下面比较方案	见下面比较方案
场景、15小兵（无阴影）	15	64ms	43ms	一当加上场景就卡的原因是，小兵需要投影圆形阴影到场景	无	程序进行设备LOD，当是低端机的时候，需要去掉所有blob shadow projector

结论，敌人脚下的Blob shadow projector阴影是真正的透明渲染瓶颈所在，可以采取设备LOD，在iPhone4上直接去除掉这个功能。

可以发现尽管去掉阴影后，效率还是无法达标，所以需要再重投进行一次profile。

原文地址：http://www.jianshu.com/p/5ef7557245f1