这里暂且讨论使用Mac对iOS设备进行调试的方法。至于Android平台，会有细节但不是非常重要的不同。
为什么需要联机Profile？
大部分情况，直接在工作机（PC、Mac）用Unity针对工程进行Profile就能查出性能的瓶颈。
但在不同的设备会有不同的性能表现、甚至一些设备由于硬件设计的原因，导致一些性能瓶颈只有在特定设备上才会表现出来。
针对这些设备相关的性能问题，需要进行联机Profile。
Profile的手段概述
iOS设备通过USB连接Mac后，对其进行Profile手段有三种：
-
Unity进行Profile
unity_profile -
XCode进行Profile
xcode_profile -
XCode在debug模式时的“GPU Report”
xcode_fps
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 - 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_profile_png - 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后，点击下图左部的debug_navigator
按钮
xcode_fps - 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。
