6评论

【程序】Unity 性能 Review

韩宇飞 2018-01-21 1.5k浏览

想免费获取内部独家PPT资料库?观看行业大牛直播?点击加入腾讯GAD游戏开发行业精英群711501594

本文首发于知乎专栏:MACK的游戏开发笔记,欢迎各位关注。


年初的一次优化笔记,第一篇。每个版本一周,每个版本一篇已经6,7篇了。过早的优化可能并不是最好的,但是每个版本每个月都要上线测试。始终觉得对于实时多人竞技游戏来说,流畅的重要性超过画面。

使用Unity的Profile先简单分析

  • 角色更新过高,后面更详细的分析。
  • 屏幕边缘图标和Wifi过高。优化方案:频繁设置UI文字和贴了可以优化。
  • 放技能开销非常高,每个子弹有独立弹道逻辑,技能释放频率比价高。优化方案:类对象使用内存池,delegate优化减少gc,更完善的预加载机制,逻辑优化等等。CMT的timer使用内存池。
  • 部分非技能的CMT没有预加载。
  • 召唤物没有预加载。
  • 部分道具有些没有预加载。
  • 消息处理非常卡。解决方案:使用类对象内存池,优化序列化方式不使用protobuff的。
  • 帧操作增减人会卡。解决方案:推测玩家行为预加载。
  • 飞行道具开销很高,特别是Deactive上。解决方案:可见性使用layer,使用内存池
  • 地图脚本开销较高。
  • Camera.main直接调用开销较高。解决方案:因为Unity会遍历所有的Camera,是一个线性时间。在Update中调用的话,缓存一下main
    camera。


使用Unity的FrameDebugger简单分析

  • 俯视角开启了天空球渲染,其实没必要


使用Unity MemoryProfiler分析内存占用和内存泄漏

通过memoryprofile抓帧分析,内存占用不高,但是RenderTexture占用非常高63.5M

  • 大厅场景RenderTexture 63.5m。解决方案:因为使用了景深,扰动,屏幕校色,实时阴影,等后期处理效果所致,我们根据玩家手机配置做了自适应和限定,并且再图形配置选项允许玩家做一些调整。景深开销非常高因此关闭了实时景深效果使用其他方法代替。
  • 战斗场景Texture 33.7m Mesh 14.9m animationclip 3.7m Audiomanager 4.1M。解决方案:贴图压缩,使用shader减少换色贴图,修正一些贴图引用不释放导致的内存泄漏。
  • LockstepMnanager.FixedUpdate函数 每帧分配10kb以上内存。解决方案:各种GC相关的优化。
  • SceneLoader.update函数(315 bytes) MainLoop.Update函数(202bytes), NetManager.update函数(186bs) CharacterActor.LateUpdate函数(392 bytes)皆为每帧都分配。GC的分配每帧超过200b就算大了。解决方案:各种内存优化,消息使用内存池等等。
  • MainLoop.OnGUI函数每帧分配内存 300b。解决方案:删掉空函数。
  • 大厅场景Camera.Render cpu等待gnu渲染,造成时间帧率抖动 25ms-> 43ms 体现为Camera.Render self时间大幅变动 (优化方法 降低场景面数,拆分Gm_Cabin模型)
  • Loading贴图存在伪内存泄漏,因为图集和按钮放在一起了被按钮引用。
  • Unity技术支持提供了脚本插件可以分析代码中所有静态的引用。发现是lua的LuaScriptMgr中会对一些贴图有引用,需要注意使用Lua导致的内存问题。


使用XCode做详尽的性能优化

XCode也可以做GPU的性能分析。编译xcode工程需要Development版,启动,GUP的优化点需要在Run的面板里设置成metal否则有些堆栈看不到。点FPS,然后点相机Capture一帧,可以看到帧率,CPUGPU的占比,渲染时每个函数的开销。点Shader里面的看更详细堆栈,可以看到每个shader的每行代码的开销占比。

  • 这个版本大厅很简单但是非常非常卡,看到UI和景深开销占比比较高,UI占了25,景深占了30。看到UI费是采样一张贴图占了50但是这张贴图并不大,景深费是因为shader里lerp了很多次导致开销很高。在FrameDebugger里可以看到UI最后渲染了一个全屏的面,可以看到每次渲染了占用的时间比,这个面实际没用。关闭了这个UI的全屏面,关了景深和后处理,基本就没开销了,连UI的渲染也只有2ms了因为景深把总线带宽给占满了,其中最费的还是景深效果。
渲染线程开销也较高
  • 版本机出的版本在XCode中会报错APPLE MACH-O Linker Error,无法做性能分析。解决方法:改成il2cpp了。
  • 修复字符串拼接的量级,使用StringBuilder等。
  • OnGUI,FixedUpdate,Update等空函数也会有gc开销,因为会产生从C++到C#层调用的开销。最好都去掉。
  • FMOD音效模块开销过高。我们没使用官方的FMOD使用了FMODStudio,测试版资源为了效果和开发方便使用了一些事件内的效果器。优化后音效占用10-15%。
  • 动画开销较高,使用了动作融合,动画状态机较复杂。解决方案:不可见的角色不更新动画,一些顶点受骨骼影响数可以设置很小,小怪等简单角色使用Animation,动画的一些优化等。
  • UI,粒子,动作开销较高,并且多线程开销也高。
  • 可以看到每个模块开销比较平均,已经做了很多优化了没有明显瓶颈,只能一个模块一个模块的抠了


其他一些测试以及和Unity官方支持的问答:

  • Unity的物理比射线省,因为会优化做空间划分,只计算较小范围。Navmesh最优化。
  • 迷雾和可以性检测可见性预缓存,预缓存分块加载,迷雾进行分块划分优化,分担计算量到多帧执行等等
  • Resource目录资源多会导致Unity进游戏时间特别长,因为会把Resource下所有资源做一次检索,导致启动慢。建议使用Assertbundle,也支持压缩。另外提升进入游戏速度的就是,第一个场景足够简单足够小。解决方案:开发了热更的资源管理,每个资源有一个唯一ID,可以存在Resource下也可以存在Assertbundle中。
  • Assetbundle的新算法是按Chunk加载,不会把整个Assertbundle都加载进来但是压缩比小,压缩的时候要选择ChunkBase。如果bundle加载好之后资源的引用时放在bundle上,如果a界面打开bundle包读取贴图,a界面关闭则贴图会释放,如果a没关闭,b界面读取贴图b界面会对应到同一张贴图上。
  • 建议bundle放在StreamingAssets目录下。
  • Profile分析建议:Overhead,是Unity没统计到的时间,用总计时间减去剩余的时间,一般包括C++到C#层的调用开销,场景复杂度,垂直同步等。大厅因为Overhead卡是因为CPU在等GPU,建议用XCode看。
  • 通过Profile.BeginSample自己插代码对怀疑的代码进行内存和性能调试。
  • Unity5.3.5p8修改了Foreach装箱拆箱导致的内存开销。但是没有修改mono的gc。实际测试可以用Foreach了。
  • 部分Android设备总线太烂导致GC会特别卡
  • OnGUI,FixedUpdate,Update等空函数也会有gc开销,因为会产生从C++到C#层调用的开销。最好都去掉
  • 部分3G的Android设备,实际可用内存可能只有500M。Unity启动时最高能占到80M,一般在40-50M
  • unload切场景自动调,gc也会自动调
  • 编辑器下看到的资源引用计数不准确,得看真机。实际测试的时候老发现很多资源释放不掉,但是到真机测试发现实际已经释放掉了,因为编辑器模式会缓存一些资源,所有的测试都应该以真机为准。
  • lua导致gc太多,没有比较好的解决办法,把lua的代码放到C# 层
  • IOS上如果限45帧对IOS来说就是限30帧,低于30帧才是真实帧率
  • CPU优化:ulua的计时器开销很大。其中PreloadManager是Unity的各个模块的预加载。
  • GPU优化:Mask会很费。

想免费获取内部独家PPT资料库? 观看行业大牛直播?

立即扫码加群

本文作者

韩宇飞

热爱游戏热爱编程的游戏开发。对运动,读书,木工,音乐等也有浓厚的兴趣,爱好广泛,有好奇心,崇尚极简。立志开发一款让自己满意玩家喜欢的游戏。

腾讯GAD公众号

腾讯GAD 游戏开发者平台

正在为您生成个性化社区首页

已为您定制专属社区首页

选择关注标签

全新改版的GAD,想你所想,等你体验...
  • 策划{{selectCount.plan}}
  • 开发{{selectCount.program}}
  • 美术{{selectCount.art}}
  • VR/AR{{selectCount.vr}}
{{tab.name}}
跳过

选择关注用户

  • {{tab.user.NickName}} {{tab.introduction}}