联机Unity Profile技巧

这里暂且讨论使用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准备步骤

1. 通过USB连接调试设备和Mac
2. 在Build Settings里如下图选择“Development Build”和“Autoconnect Profiler”，然后点击“Build”或者“Build And Run”
   
3. 构建中途，Unity会调用XCode自动进行编译、自动进行运行。
4. 设备运行我们的app了之后，在Unity打开Profiler面板，并且如下图选择“iOS profiler over USB”，也就开始进行profile了。
   
5. Unity进行Profile准备步骤结束。

XCode进行Profile

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

2. 确保调试设备能够进行调试你的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”。

3. 在Unity进行Build了之后

4. 在XCode打开相应的工程，如下图点击Product>Profile
   
5. XCode编译完了之后，会打开“Instruments”正式开始Profile调试
   • 可以通过“Instruments”里面的“Library“来选择不同维度的Profile，比如“Activity Monitor”可以监控设备的各个进程情况、“Core Animation”可以监控帧数、“OpenGL ES Analyzer”可以监控图形API层面的调度情况。
6. XCode进行Profile准备步骤结束。

XCode进行“GPU Report”

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

1. Unity输出XCode工程后，在XCode打开相应的工程，直接点击“播放键”三角形；
2. 当设备自动运行app后，点击下图左部的按钮
   
3. XCode进行“GPU Report”准备步骤结束。

Profile的方法论

如何找到性能瓶颈

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

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

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