unity3d移动端优化方法_unity3d 移动端人物移动 - CSDN
  • 项目进入了中期之后,就需要对程序在移动设备上的表现做分析评估和针对性的优化了,首先前期做优化,很多瓶颈没表现出来,能做的东西不多,而且很多指标会凭预想,如果太后期做优化又会太晚,到时发现一些问题改起来...

    项目进入了中期之后,就需要对程序在移动设备上的表现做分析评估和针对性的优化了,首先前期做优化,很多瓶颈没表现出来,能做的东西不多,而且很多指标会凭预想,如果太后期做优化又会太晚,到时发现一些问题改起来返工量就有太大。前一阵子花了大量时间从 cpu gpu 内存 启动时间 到发热量对项目做了一翻大规模的体检和优化,效果还是显著的,在这里做个笔记,以后开发项目时可以作为经验和提前关注

          1.项目情况:笔者所在项目是一个非常重度的手游,甚至开始就是瞄着端游做的,3D世界,2.5D视角,RPG,即使战斗,美术品质要求极高(模型 贴图精度高 ,超过目前市场同类产品)。对于目前大多数移动设备来看,挑战不小,对手机的各种硬件都是挑战。、

         2.目标机型:偏中高端,尽量兼容低端,android至少sumsung S3能流畅,ios至少iphone4s流畅。

         3.性能指标:内存占用250M以下(这样大量512的机器不会挂掉),初始包100m之内(太多运营不干,太少实在是装不下。。)


    用于分析和测试性能的一些利器:

     1.首先是unity在编辑器下的statics窗口:提供了dc和顶点数这两个重要指标的查看。缺点在设备看不到,但是对于dc数和顶点数来说,设备和编辑器差不多,用它可以大体看出渲染的压力。

     2.unity自带的profiler:可以连接设备看到设备上cpu gpu mem的信息,使用的时候需要勾选development模式。有点是cpu的占用在脚本的层面看的非常仔细,哪个函数占用了太多时间一眼就能看出,基本是分析脚本效率的最佳工具,但是gpu大部分设备不支持看不到,显示的mem信息不太准确,基本上偏离实际占用的内存

    3.unity的internal profiler:在playersetting上可以勾选这个选项,勾选后,连接设备,在android的adb或者mac的xcode里会每隔几秒打印出很多关键指标,这个其实非常有用,不过这个功能直到很后期才发现,详细文档见http://docs.unity3d.com/Manual/iphone-InternalProfiler.html

    4.android上的adb:adb提供了一组非常强大的分离android程序的工具,http://developer.android.com/tools/help/adb.html

    而最常用的是用adb的dumpsys 指令,https://source.android.com/devices/tech/input/dumpsys.html

    最常见的包括: adb shell dumpsys meminfo appname  查看实时的内存占用,android的内存分为ps rs,我们一般看ps为准,关于ps rs这些概念可参看http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android

    adb shell dumpsys cpuinfo appname 查看实时的cpu占用,注意这里的cpu可能过百,这是因为多核的原因

    adb shell dumpsys gpuinfo appname 查看实时的gpu情况

    5.android  的monitor

    安装adt后,在sdk\tools\monitor.bat下面有个monitor,是我认为android看性能最好的工具之一,因为它是图形化的,而且基本集成了adb的功能,从内存到cpu到gpu,还有很有用的网络流量使用情况,它的cpu占用是c++层面的统计,看不到脚本,这需要突破那个profilor结合。

    6.android上的mongkey测试:它可以模拟随机的用户输入,用来验证你的程序的强壮性吧

    adb shell monkey -p -v packname 1000
    随机模拟1000条用户事件

    7.ios:ios上的工具则显得更加专业更加统一一些,ios就用xcode自带的instruments了

    这里有个详细的文档https://developer.apple.com/library/mac/documentation/developertools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html

    看来这么多工具,其实很多是要配合使用的,做u3d开发,其实不只是学会U3D的事情,要让U3D在手机上运行的好,还需要对各个平台有较深的了解。


     利用这些工具法线了一些瓶颈,同时也采取了各种策略来提高性能,反正目标就是cpu占用降低,内存占用减少,启动快,发热小,帧率高,GPU占用少,发现的一些问题和做出的具体的一些努力列举如下:

    1.使用assetbundle,实现资源分离和共享,将内存控制到200m之内,同时也可以实现资源的在线更新

    2.顶点数对渲染无论是cpu还是gpu都是压力最大的贡献者,降低顶点数到8万以下,fps稳定到了30帧左右

    3.只使用一盏动态光,不是用阴影,不使用光照探头

    粒子系统是cpu上的大头

    4.剪裁粒子系统
    5.合并同时出现的粒子系统
    6.自己实现轻量级的粒子系统
    animator也是一个效率奇差的地方
    7.把不需要跟骨骼动画和动作过渡的地方全部使用animation,控制骨骼数量在30根以下
    8.animator出视野不更新
    9.删除无意义的animator
    10.animator的初始化很耗时(粒子上能不能尽量不用animator)
    11.除主角外都不要跟骨骼运动apply root motion
    12.绝对禁止掉那些不带刚体带包围盒的物体(static collider )运动
    NUGI的代码效率很差,基本上runtime的时候对cpu的贡献和render不相上下
    13每帧递归的计算finalalpha改为只有初始化和变动时计算
    14去掉法线计算
    15不要每帧计算viewsize 和windowsize
    16filldrawcall时构建顶点缓存使用array.copy
    17.代码剪裁:使用strip level ,使用.net2.0 subset
    18.尽量减少smooth group
    19.给美术定一个严格的经过科学验证的美术标准,并在U3D里面配以相应的检查工具

    后面的文章会对这些点做以更详细的讨论


    展开全文
  • 猴子原创,欢迎转载。...今天去CGDC听了刘钢先生的Unity移动端优化处理,记录刘钢先生的优化建议。   一、关于性能优化的几大误区   误区1:性能优化只是程序员的责任,与美术和策划无关。 -技

    猴子原创,欢迎转载。转载请注明: 转载自Cocos2D开发网--Cocos2Dev.com,谢谢!

    原文地址: http://www.cocos2dev.com/?p=285

    今天去CGDC听了刘钢先生的Unity在移动端的优化处理,记录刘钢先生的优化建议。

     

    一、关于性能优化的几大误区

     

    误区1:性能优化只是程序员的责任,与美术和策划无关。

    -技术美术和关卡设计师对于游戏性能承担着非常重要的责任

    -程序员往往无法补救由于滥用美术资源而造成的性能问题

     

    误区2:在制定了严格的美术规范之后,美术师就应该对一切美术问题负责,程序员不再与此有关

    -程序员应该为美术师实现完整的美术资源合法性检查工具

    -Tools speak louder than rules!

     

    误区3:对于程序而言,性能优化应该从GPU/Shader的执行效率入手

    -针对CPU端/游戏逻辑的性能优化往往能够取得更大的作用

    -GPU/Shader的性能优化应该放在最后进行

     

    未完.......待续.....

    展开全文
  • 主要是围绕资源加载效率的优化,文本文件加载,比如xml序列化读取,protobuf文件序列化,以及消息事件封装及应用,shader的优化及运用,移动端实时阴影的绘制。
  • Unity移动端性能优化

    2017-12-16 16:24:47
    1.渲染 利用reflect probe代替反射、折射,尽量不用RTT、GrabPass、RenderWithShader、CommandBuffer.Blit (BuiltinRenderTextureType.CurrentActive...)建立统一后处理框架(bloom、hdr、DOF等)代替多后处理,...
    1.渲染
    • 利用reflect probe代替反射、折射,尽量不用RTT、GrabPass、RenderWithShader、CommandBuffer.Blit (BuiltinRenderTextureType.CurrentActive...)
    • 建立统一后处理框架(bloom、hdr、DOF等)代替多后处理,可以共用模糊函数,减少多次blit;另外要注意RTT的尺寸。
    • 空气折射、热浪扭曲等使用GrabPass不是所有硬件都支持,改为RTT或者后处理来优化。
    • 建立统一shader材质代替单一shader,充分利用shader_feature、multi_compile,并将宏开关显示于界面。
    • 图像混合代替多通道纹理,阴影投射、阴影接收、MetaPass、forwardadd 等pass不需要时要剔除。
    • 少用alpha test、discard、clip、Alpha Converage等,因为会影响Early-Z Culling、HSR的优化。
    • 避免Alpha Blend穿透问题(权重混合、深度剥离等透明排序方法代价太大了)。
    • 光照贴图代替动态阴影、尽量不用实时光;阴影贴图、环境贴图用16位代替32位;利用projector+rtt或者光圈代替实时阴影。
    • 将环境参数(风、雨、太阳)等shader全局参数统一管理。
    • 非主角可以用matcap代替pbr、无金属不一定要用pbr,仔细选择物理渲染所用的FDG(F:schlick、cook-torrance、lerp、要求不高用4次方,D:blinn-phong、beckmann、GGX、GGX Anisotropic,G:neumann、cook-torrance、Kelemen、SmithGGX;standard shader要注意选择BRDF1-BRDF3),渲染要求不高时不用GGX;可以用LH来优化GGX。
    • 用fixed、half代替float,建立shader统一类型(fixed效率是float的4倍,half是float的2倍),小心选择shader变量的修饰(uniform、static、全局),选择Mobile或Unlit目录下shader
    • 使用高低配渲染,内存足够时可以考虑开启mipmap
    • 使用surface shader注意关掉不用的功能,比如:noshadow、noambient、novertexlights、nolightmap、nodynlightmap、nodirlightmap、nofog、nometa、noforwardadd等
    • standard shader的变体太多(3万多),导致编译时间较长,内存占用也很惊人(接近1G),如果使用要关掉没用的shader_feature,比如:_PARALLAXMAP、SHADOWS_SOFT、DIRLIGHTMAP_COMBINED DIRLIGHTMAP_SEPARATE、_DETAIL_MULX2、_ALPHAPREMULTIPLY_ON;另外要去掉多余的pass
    • shaderforge、Amplify Shader Editor生成的shader有多余代码要程序专门优化,Amplify Shader Editor功能更强大一些,而且开源,建议学习。
    • 不要用unity自带terrian,因为即使只用3张splat图,shader也是对应4个的,建议T4M或者转为mesh。
    • 模型和材质相同且数量巨大时用Instance来优化,比如草。
    • 利用查找纹理(LUT)来优化复杂的光照渲染,比如:皮肤、头发、喷漆等。
    • 尽量不要使用Procedural Sky,计算瑞丽散射和米氏散射效率比较低。
    • 尽量不要使用speedtree,改为模型加简单树叶动画,不过SpeedTreeWind.cginc里面的动画函数很丰富,TerrianEngine中的SmoothTriangleWave很好用。
    • 多用调试工具检查shader性能,常用工具有:FrameDebug、Nsight、RenderDoc 、AMD GPU ShaderAnalyzer / PVRShaderEditor、Adreno Profiler 、腾讯Cube、UWA等;另外可以内置GM界面,比如开关阴影,批量替换shader等方便真机调试。
    2.脚本
    • 减少GetComponent、find等查找函数在Update等循环函数中的调用、go.CompareTag代替go.tag 、
    • 减少SendMessage等同步函数调用;减少字符串连接;for代替foreach,5.5以后版本foreach已经优化过了;少用linq;
    • 大资源改为异步加载
    • 合理处理协程调用
    • 将AI、网络等放在单独线程
    • 发布优化:关闭log、剔除代码
    • 伪随机
    • 脚本挂载类改为Manager等全局类实现
    • lua中尽量不实现update、fixedupdate等循环函数,lua和csharp互调用的效率比较低。
    3.内存管理
    • 池子管理粒子、float UI等小资源,频繁地GC会造成卡顿
    • 必要时主动调用GC.Collect()
    • 按照不同资源、不同设备管理资源生命周期,Resources.Load和Assetbundle统一接口,利用引用计数来管理生命周期,并打印和观察生命周期。保证资源随场景而卸载,不常驻内存,确定哪些是预加载,哪些泄漏。
    • 内存泄漏(减少驻留内存):Container内资源不remove掉用Resources.UnloadUnusedAssets是卸载不掉的;对于这种情况,建议直接通过Profiler Memory中的Take Sample来对其进行检测,通过直接查看WebStream或SerializedFile中的AssetBundle名称,即可判断是否存在“泄露”情况;通过Android PSS/iOS Instrument反馈的App线程内存来查看;
    • 堆内存过大:避免一次性堆内存的过大分配,Mono的堆内存一旦分配,就不会返还给系统,这意味着Mono的堆内存是只升不降的。常见:高频调用new;log输出;
    • CPU占用高:NGui的重建网格导致UIPanel.LateUpdate(按照静止、移动、高频移动来切分);NGUI锚点自身的更新逻辑也会消耗不少CPU开销。即使是在控件静止不动的情况下,控件的锚点也会每帧更新(见UIWidget.OnUpdate函数),而且它的更新是递归式的,使CPU占用率更高。因此我们修改了NGUI的内部代码,使锚点只在必要时更新。一般只在控件初始化和屏幕大小发生变化时更新即可。不过这个优化的代价是控件的顶点位置发生变化的时候(比如控件在运动,或控件大小改变等),上层逻辑需要自己负责更新锚点。 加载用协程; 控制同一个UIPanel中动态UI元素的数量,数量越多,所创建的Mesh越大,从而使得重构的开销显著增加。比如,战斗过程中的HUD血条可能会大量出现,此时,建议研发团队将运动血条分离成不同的UIPanel,每组UIPanel下5~10个动态UI为宜。这种做法,其本质是从概率上尽可能降低单帧中UIPanel的重建开销。
    • 资源冗余:AssetBundle打包打到多份中;动态修改资源导致的Instance拷贝多份(比如动态修改材质,Renderer.meterial,Animation.AddClip)。
    • 磁盘空间换内存:对于占用WebStream较大的AssetBundle文件(如UI Atlas相关的AssetBundle文件等),建议使用LoadFromCacheOrDownLoad或CreateFromFile来进行替换,即将解压后的AssetBundle数据存储于本地Cache中进行使用。这种做法非常适合于内存特别吃紧的项目,即通过本地的磁盘空间来换取内存空间
    4.美术
    • 建立资源审查规范和审查工具:PBR材质贴图制作规范、场景制作资源控制规范、角色制作规范、特效制作规范;利用AssetPostprocessor建立审查工具。
    • 压缩纹理、优化精灵填充率、压缩动画、压缩声音、压缩UI(九宫格优于拉伸);严格控制模型面数、纹理数、角色骨骼数。
    • 粒子:录制动画代替粒子、减少粒子数量、粒子不要碰撞
    • 角色:启用Optimize Game Objects减少节点,使用(SimpleLOD、Cruncher)优化面数。
    • 模型:导入检查Read/Write only、Optimize Mesh、法线切线、color、禁用Mipmap
    • 压缩纹理问题:压缩可能导致色阶不足;无透明通道用ETC1,现在安卓不支持ETC2已不足5%,建议放弃分离通道办法。
    • UI:尽可能将动态UI元素和静态UI元素分离到不同的UIPanel中(UI的重建以UIPanel为单位),从而尽可能将因为变动的UI元素引起的重构控制在较小的范围内; 尽可能让动态UI元素按照同步性进行划分,即运动频率不同的UI元素尽可能分离放在不同的UIPanel中; 尽可能让动态UI元素按照同步性进行划分,即运动频率不同的UI元素尽可能分离放在不同的UIPanel中;
    • ugui:可以充分利用canvas来切分不同元素。
    • 大贴图会导致卡顿,可以切分为多个加载。
    • iOS使用mp3压缩、Android使用Vorbis压缩
    5.批次
    • 开启static batch
    • 开启dynamic batch:要求模型小于900顶点,用法线小于300,用切线小于180,缩放不一致、使用lightmap、多通道材质等会使dynamic batch无效。
    • 减少GameObject,场景模型数量对fps影响巨大。
    • 批次不是越少越好,过大的渲染数据会给总线传输带来压力。
    6.物理
    • 不需要移动的物体设为Static
    • 不要用Mesh碰撞,角色不用碰撞体
    • 触发器逻辑优化
    • 寻路频率、AI逻辑频率 、Fixed Timestep、降帧到30
    • 出现卡顿的复杂计算,例如寻路、大量资源加载 可以用分帧或者协成异步来处理
    展开全文
  • 主要是围绕资源加载效率的优化,文本文件加载,比如xml序列化读取,protobuf文件序列化,以及消息事件封装及应用,shader的优化及运用,移动端实时阴影的绘制。...

    立即学习:https://edu.csdn.net/course/play/7046/141240

    给后面影响的属性加clear属性

    清除左右浮动造成的影响

    right left both 但是没解决高度自适应和margin失效

    展开全文
  • 在知乎上看到一篇不错的性能优化文章,进行了比较系统的概括,下面分享一下,原文地址: https://zhuanlan.zhihu.com/p/26030252 1.渲染 利用reflect probe代替反射、折射,尽量不用RTT、GrabPass、...
  • Unity3D移动端实战经验分享 网名:海洋,CSDN社区讲师,3D游戏引擎...
  • 移动端实时阴影绘制的实现方式,首先需要一个3D摄像机,将这个摄像机设置成正交摄像机,并将其放置到角色的头顶上,它主要的作用是在每一帧渲染需要加阴影的物体,渲染物体时需要一个接收面,用于接收实时阴影,为了...
  • 从菜单栏查看播放器设置,选择 Edit->Project Settings->Player Global Settings that apply to any project you create. 将应用于所有项目的全局设置 Cross-Platform Properties ...
  • Unity3D游戏优化方案

    2017-04-06 06:23:31
    作为一个入行不足三年的攻城狮来讲,讲引擎中的优化,经验确实不足,unity3D引擎作为一款侧重移动端游戏开发引擎来讲,优化游戏是确实有必要的,毕竟他要适配所有机型的前提下又要保证游戏画面的清晰度,特效的绚丽...
  • 本文作者主要对Unity移动端动态阴影进行了一些总结。对各种不同阴影的构建作了简单的介绍。欢迎大家共同讨论。
  • Unity3D引擎技术交流QQ群:【21568554】 做3d移动端内存一直是人们头疼的问题,载入的资源释放了,还有其它的须要释放,比方ngui释放。事实上主要是NGUI的Texture和Sprite释放。假设你脚本程序没用到NGUI组建的...
  • UNITY3d在移动设备上的一些优化资源的方法1.使用assetbundle,实现资源分离和共享,将内存控制到200m之内,同时也可以实现资源的在线更新2.顶点数对渲染无论是cpu还是gpu都是压力最大的贡献者,降低顶点数到8万以下...
  • Unity3D性能优化--- 收集整理的一堆 官方优化文档--优化图像性能 http://docs.unity3d.com/Documentation/Manual/OptimizingGraphicsPerformance.html Unity3D性能优化专题 性能优化是一个异常繁琐而又涉及到...
  • Unity移动端优化总结

    2016-08-30 10:19:18
    Unity这边没办法控制. 就需要和做三维的同事交流好 脚本 新建的脚本默认会创建出Update函数.,在不需要用到的情况下可以删掉 尽量不要在Update函数中做复杂运算,尽量不要在Update函数中使用Find, ...
  • 版本:unity 5.4.1 语言:C#   参考实战核心技术的第八章。一般移动端受到机能的限制,最多只在脚下绘制一团小黑影来代表影子,实时渲染是基本不可能的。   不过书中提供了一种方法来实现影子,乍看之下决然...
1 2 3 4 5 ... 20
收藏数 1,185
精华内容 474
关键字:

unity3d移动端优化方法