unity直连android真机在Profiler性能分析测试

电脑端设置： 
1.Unity打开你要测试的项目 
File–Build Settings

如上图点1，再点2，这一步本应该是在项目刚建立时做的，如果做过了，2就是灰色的，不能被点击。转换完之后点3，Inspector面板会如下图所示

上图红圈中名字要记好，后面要用

 

2.确保手机连接电脑，USB调试已打开

找到你的Android SDK 目录，进入platform-tools，我的是E:\Program Files\android-sdk-windows\platform-tools，确认这个目录下存在adb.exe。 
按下shift键，右击鼠标，选择 在此处打开命令窗口

接下来输入adb forward tcp:54999 localabstract:Unity-宝石迷阵，宝石迷阵替换成你的项目名字，前文中playersetting 那张图中红圈圈出来项目名字。 输入完回车

这张图上第一次报错是因为没有连手机，第二次手机连接模式没有选（我的手机连接模式要选USB大容量存储设备），回车后应该后有成功提示，我这个是第N次运行，没有给提示。 
Cmd 部分完成，可以X掉cmd窗口了。

3.回到unity 
打开Profile

按下图点击

这一步没有提示，只要不报错就OK 
不要关闭Profile面板，点击File–Build&Run

等待，然后你的项目就会在手机上运行了。

这样只要保证Profile面板不关闭并且手机不断开，改动项目后执行File–Build&Run就可以重新在真机测试了

Unity的Profiler性能分析

A. WaitForTargetFPS: 
      Vsync(垂直同步)功能所，即显示当前帧的CPU等待时间 
   B. Overhead： 
      Profiler总体时间-所有单项的记录时间总和。用于记录尚不明确的时间消耗，以帮助进一步完善Profiler的统计。 
        C. Physics.Simulate： 
      当前帧物理模拟的CPU占用时间。 
   D. Camera.Render： 
      相机渲染准备工作的CPU占用量 
   E. RenderTexture.SetActive： 
      设置RenderTexture操作. 
      底层实现：1.比对当前帧与前一帧的ColorSurface和DepthSurface. 
               2.如果这两个Buffer一致则不生成新的RT，否则则生成新的RT，并设置与之相对应的Viewport和空间转换矩阵. 
   F. Monobehaviour.OnMouse_ ： 
      用于检测鼠标的输入消息接收和反馈，主要包括：SendMouseEvents和DoSendMouseEvents。（只要Edtor开起来，这个就会存在） 
   G. HandleUtility.SetViewInfo： 
      仅用于Editor中，作用是将GUI和Editor中的显示看起来与发布版本的显示一致。 
H. GUI.Repaint： 
      GUI的重绘(说明在有使用原生的OnGUI) 
   I. Event.Internal_MakeMasterEventCurrent： 
      负责GUI的消息传送 
   J. Cleanup Unused Cached Data： 
      清空无用的缓存数据，主要包括RenderBuffer的垃圾回收和TextRendering的垃圾回收。 
         1.RenderTexture.GarbageCollectTemporary:存在于RenderBuffer的垃圾回收中，清除临时的FreeTexture. 
         2.TextRendering.Cleanup:TextMesh的垃圾回收操作 
   K. Application.Integrate Assets in Background： 
      遍历预加载的线程队列并完成加载，同时，完成纹理的加载、Substance的Update等. 
   L. Application.LoadLevelAsync Integrate： 
      加载场景的CPU占用，通常如果此项时间长的话70%的可能是Texture过长导致. 
   M. UnloadScene： 
      卸载场景中的GameObjects、Component和GameManager，一般用在切换场景时. 
   N. CollectGameObjectObjects： 
      执行上面M项的同时，会将场景中的GameObject和Component聚集到一个Array中.然后执行下面的Destroy. 
   O. Destroy： 
      删除GameObject和Component的CPU占用. 
   P. AssetBundle.LoadAsync Integrate： 
      多线程加载AwakeQueue中的内容，即多线程执行资源的AwakeFromLoad函数. 
   Q. Loading.AwakeFromLoad： 
      在资源被加载后调用，对每种资源进行与其对应用处理. 
2. CPU Usage 
   A. Device.Present: 
      device.PresentFrame的耗时显示，该选项出现在发布版本中. 
   B. Graphics.PresentAndSync： 
      GPU上的显示和垂直同步耗时.该选项出现在发布版本中. 
   C. Mesh.DrawVBO： 
      GPU中关于Mesh的Vertex Buffer Object的渲染耗时. 
   D. Shader.Parse： 
      资源加入后引擎对Shader的解析过程. 
   E. Shader.CreateGPUProgram： 
      根据当前设备支持的图形库来建立GPU工程. 
3. Memory Profiler 

   A. Used Total: 
      当前帧的Unity内存、Mono内存、GfxDriver内存、Profiler内存的总和. 
   B. Reserved Total: 
      系统在当前帧的申请内存. 
   C. Total System Memory Usage: 
      当前帧的虚拟内存使用量.（通常是我们当前使用内存的1.5~3倍) 
   D. GameObjects in Scene: 
      当前帧场景中的GameObject数量. 
   E. Total Objects in Scene: 
      当前帧场景中的Object数量(除GameObject外，还有Component等). 
   F. Total Object Count: 
      Object数据 + Asset数量. 

4. Detail Memory Profiler 
   A. Assets: 
      Texture2d:记录当前帧内存中所使用的纹理资源情况，包括各种GameObject的纹理、天空盒纹理以及场景中所用的Lightmap资源. 
   B. Scene Memory: 
      记录当前场景中各个方面的内存占用情况，包括GameObject、所用资源、各种组件以及GameManager等（天般情况通过AssetBundle加载的不会显示在这里). 
   A. Other: 
      ManagedHeap.UseSize:代码在运行时造成的堆内存分配，表示上次GC到目前为止所分配的堆内存量. 
      SerializedFile(3): 
      WebStream:这个是由WWW来进行加载的内存占用. 
      System.ExecutableAndDlls:不同平台和不同硬件得到的值会不一样。 

一 内存优化


一 大概标准
1. 纹理             40M
2. Mono          30M
3. Animation  20M
4. Mesh          10M
5.ManagedHeap.UsedSize: 移动游戏建议不要超过20MB. 
6. Font            10M
7. Audio          5M
8. GfxDriver    25M
9. ResourceManager 视情况而定（跟 你ResourceManager里放了多少文件）
（该标准是我做 MMO 和 FPS时的标准值 不同项目会有不同程度的降低）
10.CPU-GC Allow: 关注原则：1.检测任何一次性内存分配大于2KB的选项 2.检测每帧都具有20B以上内存分配的选项. 
内存安全线 android unity在170M左右 pss在260M  （1G内存手机上不会因为内存不足crash）
ios的在280M左右（均指峰值）
二 注意点
一. 内存基本存在3种问题 
1 内存泄露
2 资源冗余 
3 Mono无效内存
一 内存泄露 主要是资源管理 注意AssetBundle Asset对象的卸载与缓存。小心处理挂在DonotDestroy的节点下面的东西。小心static变量持有资源问题。所有场景均有一个空场景进入，空场景负责进行堆内存的清空。
保证每次进入空场景的内存是一样的。
二 资源冗余 保证资源不会被带入多个场景，可勤看Profiler即可。注意不要在内存中出现同一份的多份复制。
例如 纹理开启了 read/write enable. 
调用 material mesh属性而不是 shareMaterial shareMesh属性。
动画进行分割。
例如场景只需要idle动画，则可以做一个prefrab只有idle动画，无需加载其他动画。
三 Mono无效内存 
保证mono峰值不要太高。主要是配置文件加载，序列化。
四 降低内存 纹理是最好的方式。 更改纹理格式，降低纹理尺寸。检查是否有冗余纹理。
CPU优化
一 标准
渲染 15ms 左右
脚本 10ms 左右
其他（主要是物理，动画） 8ms   左右
二 评判瓶颈
查看主要通过unity的profile工具。如果瓶颈在GPU上，profile上会有 waitforpresent 占比 或者通过 Adreno屏蔽掉openGl 来查看帧率是否有提升。
然后在看占比最高的一项是什么引起的。进行相对应的优化。
三 常用手段
1. 开启多线程渲染。
2. 减少GC。NGUI是贡献GC大户，可以通过profile进行逐一排查，优化。减少GetComponent AddComponent次数。对象多进行复用。能用struct就用struct(项目推广比较困难)
3. 去掉无用log。
4. 多进行缓存， 减少文件IO次数
5. update函数 最好只在基础层面出现。外围逻辑不要有update 函数，需要也用Invoke 或者自己实现的timer。
6. 减少 skinmesh的数量 尽量用meshRenderer 同屏数过多 通过骨骼序列帧代替skinmesh实现
7. 合并drawcall StaticBatch DymiticBatch
8. 粒子尽量不用 用的话 场景效果大的粒子加入 离屏不渲染
9. 对 粒子加入 lod
GPU优化
一标准
1. DrawCall 控制在 200以下
2. 同屏面数控制在4W面以下
二。评判瓶颈
1. Unity Profile 出现 waitforPresent
2. IOS的 FrameDebugger 可以看到CPU跟GPU分别耗时 同时也能看到某步的具体耗时
3.Adreno 也可给出每次pass消耗的clock数以及传输数量数。
三。常用手段
1. 纹理采用GPU支持格式 尽量减少纹理大小
2. camera的远裁剪面设置近一些
3. 看情况开启遮挡剔除
4. 减少透明片 overdraw在低端机会有很严重的性能问题
5. 减少shader复杂度。利用好 mask通道
6. 降低分辨率
7. 善用欺骗 很多效果可以通过巧妙的办法进行仿制。需要多跟美术沟通https://simonschreibt.de/gat/fallout-3-edges/
8. GPU基本三大瓶颈 1.带宽 2.Vertex  3. Pixel 找出瓶颈分别优化


注意：.项目中可能遇到的问题 
   A. Device.Present: 
      1.GPU的presentdevice确实非常耗时，一般出现在使用了非常复杂的shader. 
      2.GPU运行的非常快，而由于Vsync的原因，使得它需要等待较长的时间. 
      3.同样是Vsync的原因，但其他线程非常耗时，所以导致该等待时间很长，比如：过量AssetBundle加载时容易出现该问题. 
      4.Shader.CreateGPUProgram:Shader在runtime阶段（非预加载）会出现卡顿(华为K3V2芯片). 
   B. StackTraceUtility.PostprocessStacktrace()和StackTraceUtility.ExtractStackTrace(): 
      1.一般是由Debug.Log或类似API造成. 
      2.游戏发布后需将Debug API进行屏蔽. 
   C. Overhead: 
      1.一般情况为Vsync所致. 
      2.通常出现在Android设备上. 
   D. GC.Collect: 
      原因: 1.代码分配内存过量(恶性的) 2.一定时间间隔由系统调用(良性的). 
      占用时间：1.与现有Garbage size相关 2.与剩余内存使用颗粒相关（比如场景物件过多，利用率低的情况下，GC释放后需要做内存重排) 
   E. GarbageCollectAssetsProfile: 
      1.引擎在执行UnloadUnusedAssets操作(该操作是比较耗时的,建议在切场景的时候进行). 
      2.尽可能地避免使用Unity内建GUI，避免GUI.Repaint过渡GC Allow. 
      3.if(other.tag == GearParent.MogoPlayerTag)改为other.CompareTag(GearParent.MogoPlayerTag).因为other.tag为产生180B的GC Allow. 
   F. 少用foreach，因为每次foreach为产生一个enumerator(约16B的内存分配)，尽量改为for. 
   G. Lambda表达式，使用不当会产生内存泄漏. 
   H. 尽量少用LINQ： 
      1.部分功能无法在某些平台使用. 
      2.会分配大量GC Allow. 
   I. 控制StartCoroutine的次数： 
      1.开启一个Coroutine(协程)，至少分配37B的内存. 
      2.Coroutine类的实例 — 21B. 
      3.Enumerator — 16B. 
   J. 使用StringBuilder替代字符串直接连接. 
   K. 缓存组件: 
      1.每次GetComponent均会分配一定的GC Allow. 
      2.每次Object.name都会分配39B的堆内存.