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

转:https://blog.csdn.net/appppppen/article/details/52618851

电脑端设置: 

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. 纹理             40M2. Mono          30M3. Animation  20M4. Mesh          10M5.ManagedHeap.UsedSize: 移动游戏建议不要超过20MB. 6. Font            10M7. Audio          5M8. GfxDriver    25M9. 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 DymiticBatch8. 粒子尽量不用 用的话 场景效果大的粒子加入 离屏不渲染9. 对 粒子加入 lodGPU优化一标准1. DrawCall 控制在 200以下2. 同屏面数控制在4W面以下二。评判瓶颈1. Unity Profile 出现 waitforPresent2. 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的堆内存.