UWA问答 | 博客 | 游戏及VR应用性能优化记录分享 | 侑虎科技 - 性能
type: channel
link: https://blog.uwa4d.com/tag/性能/
items: 特效优化2：效果与性能的博弈
items: Unity引擎模块分析—注重效率的你不妨这么做！
items: 2017年度大赏 | 最受欢迎的十个UWA问答
items: 技术分享连载（九十八）
items: UWA官方Demo新增《小米超神》，全面揭秘重度手游的性能表现！
items: 专业的优化服务，就是为你争取时间！
items: MOBA手游《小米超神》案例精讲
items: 如何实现更真实的软阴影效果
items: 技术分享连载（八十一）
items: 技术分享连载（八十）

特效优化2：效果与性能的博弈
type: item
date: 2020-12-30T04:50:00+02:00
description: 在上一期《特效优化：发现绚丽背后的质朴》中，我们主要针对UWA本地资源检测中和特效相关的知识点做了讲解。这些看似细小的知识点，很容易在大家的开发和学习过程中被疏忽，而长期的问题积累最终都会反映到项目的性能表现上。为此，我们将这些规则列出，并且以一个个知识点的形式向大家逐一解读。 本期，我们将主要面向粒子特效相关的检测规则：“特效运行时包含的ParticleSystem组件数量过多”、“特效播放时最大粒子数量过大”，“特效总贴图数量过大”，以及新增加的规则“开启各向异性过滤的纹理”。我们将力图以浅显易懂的表达，让职场萌新或优化萌新能够深入理解。 1、特效运行时包含的ParticleSystem组件数量过多 本条规则面向的核心其实是项目开发中最常见的一对矛盾：效果与性能。为了实现更为复杂、更为绚丽的展示效果，研发团队会添加各种粒子系统。在带来效果提升的同时，也会产生非常明显的性能消耗和渲染压力。所以我们需要科学地做减法，减少ParticleSystem组件数量，以降低部分特效效果的代价来达到和项目性能之间的平衡。 这里需要说明的是，规则给出的默认阈值是一个比较严苛的标准，研发团队可以根据自己项目的实际需求去设定符合现阶段性能承受范围的阈值。 2、播放特效时最大粒子数量过多 本条规则和我们之前在文章《【性能黑榜】掌握了这些规则，你已经战胜了80%的对手！》中提到的“粒子数上限超过30的粒子系统”的这条规则很相近。 合理的粒子数会使得特效的表现效果恰到好处，但过多的粒子数会给CPU和GPU的计算带来更大压力。在复杂的粒子特效下，由于大量各种粒子的存在，处理特效所带来的性能开销也会大幅度地增加。 天平的两端是特效总体效果和性能，所以我们的视角要提高到总粒子数上。在实际操作中，开发团队要尽可能精确地基于特效总体展示效果，对每一个粒子系统的最大粒子数都进行合理的规划与调整，这样才有可能在保证降低粒子特效更新开销的同时，依然能够接近或维持原有的特效效果。 3、特效总贴图数量过大 本条规则从另一个维度为开发团队提供特效相关的检测规范。贴图涉及的方面很多，在之前的文章《材质优化：如何正确处理纹理和材质的关系》和《粒子系统优化：Mesh模式下的优化策略》内我们曾简单介绍过，Shader对纹理的采样、材质对纹理的引用以及粒子系统对纹理的应用等，如果在使用时不细致，就会导致特效内的贴图资源上涨，从而带来内存和计算上的额外消耗。 所以本条规则从“贴图总数”的角度，为大家统计出这些包含贴图数过多的特效资源，以供开发团队对其进行进一步的优化，来为特效做瘦身。 4、开启各向异性过滤的纹理 在之前的文章《纹理优化：不仅仅是一张图片那么简单》中，我们对纹理的过滤模式有过介绍，简单来讲是为了降低纹理到模型表面的这个过程中发生的“失真”现象。 相比于之前提到的各种过滤模式，纹理“贴”到物体表面时，各向异性过滤多考虑了纹理贴合与视野观察角度的关系。在这个前提下，如果在U、V方向上，纹理像素对应到物体表面的关系不是1:1时，它会按比例在各方向上进行采样不同数量的点，并进行计算以得到最终的对应关系。 在纹理的过滤模式中选择Bilinear（双线性过滤）或者Trilinear（三线性过滤）时，我们就可以对Aniso Level进行调整，范围是从0到16。 当我们把摄像机调成与纹理表面成一定角度时，Aniso Level的作用就会显示出来。如下图是nisoLevel设置为0或1时的纹理的表现（即不进行各向异性过滤）： 下图是AnisoLevel设置为9时（这时候进行了各向异性过滤）的贴图情况。对比两张图就能很明显地发现视野远端的清晰程度是完全不一样的。 开启各向异性过滤，在这种要考虑视野角度的情况下，可以很显著地提升纹理的表现效果，但代价是更高的GPU性能开销。而且各向异性过滤主要适用于大面积的地面与地形设置，对场景内的物体来讲，开启相关纹理的各向异性过滤就有“杀鸡用牛刀”的浪费之嫌了，表现效果上的提升并不足以抵消或平衡由此带来的性能消耗和渲染压力。 所以本条规则筛选出这些纹理后，开发团队要根据实际情况，在充分考量使用场景、表现效果和性能消耗的多方平衡后，再去决定是否需要保留开启各向异性过滤。 希望以上这些知识点能在实际的开发过程中为大家带来帮助。需要说明的是，每一项检测规则的阈值都可以由开发团队依据自身项目的实际需求去设置合适的阈值范围，这也是本地资源检测的一大特点。同时，也欢迎大家来使用UWA推出的本地资源检测服务，可帮助大家尽早对项目建立科学的美术规范。 万行代码屹立不倒，全靠基础掌握得好！ 相关推荐 《UWA学堂训练营｜游戏自动化测试》 性能黑榜相关阅读 《那些年给性能埋过的坑，你跳了吗？》 《那些年给性能埋过的坑，你跳了吗？（第二弹）》 《掌握了这些规则，你已经战胜了…

Unity引擎模块分析—注重效率的你不妨这么做！
type: item
date: 2018-09-28T16:21:00+03:00
description: UWA GOT是UWA推出的本地性能优化工具，其Online功能限时免费中，并受到了大量开发者的试用和积极反馈。其中，它的总体性能分析模式主要便于研发团队直观地定位、验证和解决逻辑代码中的效率瓶颈。 然而我们知道，引擎模块的性能同样至关重要，仅仅逻辑代码的检测还无法实现系统、完整地定位瓶颈的目的。所以今天，我们在该工具中推出Unity引擎模块的检测。您只需要拥有一个UWA GOT，在本地真机上测试后即可把数据同步到官网，这些详细的数据就能立马呈现。 详细的引擎模块参数 目前，UWA GOT Online报告支持渲染、UI、粒子、动画、加载和物理这六大主流引擎模块的重要参数检测。如下图，在渲染模块页面中，我们可以查看不透明、半透明、视域裁剪CPU和相机后处理等CPU耗时的走势以及某一帧上的耗时。 我们也可以缩放某段测试区域，结合运行截图更直观地定位某些峰值处的表现。 对于引擎模块的重要参数，我们提供了UWA推荐值和相关的优化建议，便于研发团队进行有的放矢的排查和优化。 精准的逻辑代码堆栈 堆栈信息是我们定位性能瓶颈的鹰眼，这次版本的更新不仅丰富了引擎模块的重要参数检测，在逻辑代码中也可以查看更细致的引擎函数堆栈信息，并且通过总体、指定场景和指定帧来定位具体的调用详情。 特别的，在堆栈信息列表中，我们也提供了历史数据对比功能，针对于研发团队定制的性能或功能回归测试，我们可以直接在报告中查看指定重要参数的变化趋势，便于开发团队可以在第一时间验证测试结果。 这次的新功能小编就安利到这里啦！目前，该功能也在限免使用中，研发团队只需要拥有一个UWA GOT，就可以在总体性能分析模式中体验到该功能！还不快打开你的黑科技试一试呀^_^！ 关于UWA GOT Online UWA GOT 是UWA推出的本地性能测评工具，它方便研发团队在本地真机测试，并能在编辑器中搭建本地服务器查看性能数据。现在，在UWA GOT现有的本地测评模式上，我们增加了线上同步和分析功能，研发团队可以将本地测评的数据快速同步到UWA官网，生成在线测评报告，提供更高效的性能分析数据及有针对性的优化建议。同时，贴心的版本对比功能，方便研发团队轻松监测每次测试中的重要性能参数变化趋势，从质量管控上为项目的研发保驾护航。

2017年度大赏 | 最受欢迎的十个UWA问答
type: item
date: 2018-02-27T03:59:00+02:00
description: 新年伊始，随着大家紧锣密鼓地开始了工作，UWA每周推送的知识型栏目《厚积薄发 | 技术分享》已经伴随大家走过了100个工作周。回顾两年多来，我们分享了近500个和游戏开发、优化相关的精彩问答。这些问答不仅有具象明确的提问，也有详细周全的解答；既能供研发团队自身项目中即学即用，还能通过参与者的回答分析，帮助我们在解决问题的过程中触类旁通、鉴往知来。我们优选了10个开放性的精彩回答，分享给大家。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 1、如何在项目初期确定美术规范？ 在项目初期，没有任何正式美术资源的情况下，如何给出一个美术资源制作的规范给到美术呢？我明白，就上面的策划需求不能得出一个精确的制作规范，只是想要一个大概的推算方式，给出一些大概的参数，好让美术有规范可以参考。不知是否能给些指引？ 美术也可以按他们想要的精度先制作部分角色和场景，但只有有限种类的资源的情况下，有方法测算出这个精度在性能允许范围吗？也就是说这个精度满足策划需求，可以作为美术制作规范。例如只有一个角色（5000面，512贴图三张，80根骨骼），策划同屏要求20个，就在场景中摆20个一样的角色进去（因为只有一个），如果目标手机不崩溃，以后角色的制作就按这样做。这样可以验证这个精度吗？ 精彩回答1： 作为经历了一个新项目在大家都没经验的情况下做出一个刚小范围内测游戏的苦逼开发者，结合群里讨论，个人觉得以下经验可以参考： 1）选好对标游戏，扒资源来参考。比如畅销榜上的游戏，把资源解出来看，参考模型面数和贴图等游戏。这样最坏的情况下，参考别人能跑上线收到钱的游戏，收钱不保证，但是游戏性能的坑会少很多； 2）所有口头或文档的规范，都是无效的，不可能得到严格遵守，也就是说，不能用程序检测的规范都是空规范，全部做成Editor菜单检查校验； 3）用同一个英雄放20份测同屏的方法是不靠谱的； 4）从gfxbench.com上根据跑分选好基准机型，比如假设要兼容的机型是跑700帧的，那么基准机型得选6000帧的，预留好性能空间，性能别用得太满，否则没回旋余地: 5）贴图少用RGBA32，让美术在做图的时候，做出来一律以压缩模式的纹理来走Unity导真机包来看效果，千万别只是把美术图导手机相册里看效果，这会和真实的游戏效果有所偏差。建议规范只留两张2048*2048的纹理空间给美术发挥，其余全压缩，否则等美术在高画质模式作出效果后不肯降效果，逼程序优化，性能损耗非常大，程序会万分苦逼。 感谢李先生提供了以上回答。 精彩回答2： 这确实是个见仁见智并且取决于项目类型的问题，不过题主是在项目初期，想要快速迭代出策划的设计原型，并且要快速制作并且不用与程序产生过多沟通，在此前提下我觉得设定美术规范的首要目的是：不失控。制作出性能优秀的原型不是前期的目的，但毕竟是项目进展的一部分，如果美术资源制作没有标准规范参考，如果随便一个场景都是几十万面，DrawCall超过300，Overdraw可视化都红得发白，那到后面整个团队都要为此付出时间和精力，甚至返工。所以基本的制作规范也是十分必要的。 其次，在项目前期如何看待优化这个问题呢？我觉得过早的优化也是没有太大意义的，谈优化必须首先定位瓶颈，否则盲目优化除了降低资源质量和运算精度，对项目很难起到正面作用。这时项目处于快速变化中，不适合过早断定，所以在这个阶段依然是保证项目即使没有很优秀的性能，但是也没有很严重的问题，这就已经及格了。到了项目后期优化与效果的博弈，这又是另一个话题了。 在以上前提下，假设题主制作的是一个RPG游戏，主城+若干小副本推图，中端手机 iPhone 5，没有程序的太多干预，那么我的建议是： 1）大致规定好项目在 Unity 中的资源组织格式； 2）设定好 3dmax 导出模型的比例标尺，最好与 Unity 大小 1:1； 3）场景总面数均值5-6w左右（大部分），最高10w（少部分），单个模型300-1500面，摄像机可见部分2w以下，导出去除废点，多余的法线（如果没用的话），尽量单面； 4）场景总面数还要看同屏战斗人数多少做调整，Drawcall最好不超过50，一边给角色和特效留下空间，总 Drawcall 不要超过250这个尽量保证； 5）场景物体每个模型一个材质球，贴图256为主，正方形，pot(长宽2的倍数)； 6）严格限制场景中透明片的大小和重叠的个数，尽量少用，减少面积； 7）角色面数部分，主角1500以下；特殊boss2000以下；精英怪物1000面以下；普通怪物800面以下； 8）每个角色一个材质，除了特殊部件（翅膀等）一律不使用透明材质；贴图长宽相等，符合pot，128-256为主，最大不超过512； 9）去除 IK 节点和所有不必要的网格，对齐模型…

技术分享连载（九十八）
type: item
date: 2018-02-06T03:25:00+02:00
description: 本期聚集了这些话题：半透明渲染对性能的影响、PSS内存在部分机型上暴涨、Action函数的性能、ShaderVariantCollection生成设定...... 我们将从日常技术交流中精选若干个开发相关的问题，建议阅读时间15分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 渲染 Q1：在UWA性能优化报告中，有个专门针对半透明渲染的性能消耗说明，导致半透明渲染高开销的一般有UI、场景和粒子等，那么想知道，UI（好像大部分UI都是有带半透明的）对半透明的影响有多大？在制作UI上有没有什么注意事项？ 就现在的大多数移动项目而言，这个影响是很大的。在半透明渲染的CPU端，主要有两点需要注意： （1）UI Draw Call；（2）UI的重建。 UI Draw Call越高，其渲染耗时越大，所以，建议在题主在UWA测评报告中的CPU详细性能堆栈中，查看UI的Draw Call使用情况。一般移动游戏，都建议将其峰值控制在40以下。而如果降低UI Draw Call，主要还是图集打成Atlas、避免穿插等等，具体的可自行Google。 UI重建同样会造成开销过大，主要表现在主线程的self等待开销中，当UI重建的网格体量较大时，这种情况容易出现。所以，尽可能避免不必要的UI网格重建，也是研发团队在UI制作时需要特别注意的地方。 该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/5a731c34e3b569146eeaeb35 内存 Q2：最近我们发现游戏在魅族Pro5在运行时，PSS内存会暴涨，使用UWA GOT测试，发现资源内存并都没涨，而且这个问题目前只在魅族Pro5上出现，其它机型没有这个问题，请问该怎么解决呢？ 我找了一个简单工程，如下图NPC名字跟阴影不能同时显示，否则就会导致PSS内存暴涨。 如下图，GfxDriver内存一直在涨，一秒涨2MB左右，只增不减。运行久了，魅族Pro5会崩溃。 如果GfxDriver和PSS一起升高，那么说明GPU方面存在Bug的概率很高。只能建议如下： （1）尝试在特定机器上不加入“UI阴影”，从制作上进行规避； （2）尝试在更高Unity版本中运行Demo，查看其内存问题是否会修复。 后经题主再次反馈，把 Unity版本从5.4.5升级到5.5.6，然后把 auto graphics api勾选上后，内存爆涨的问题就解决了。如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/5a741b6fe3b569146eeaeb3a 其他 Q3：new Action(Function)和直接传入Function函数区别是什么？例如以下两个函数有啥区别？ void Method(Action action) { } void MethodCallBack() { } void Start() { //Method(new Action(MethodCallBack)) 和 Method(MethodCallBack) 有啥区别？ 哪个性能高？ } 两者理论上是一样的，因为Method(MethodCallBack)在编译时，编译器会自行给它包一层new Action。所以这两种写法从编译结果来看，是一致的。 这两种写法如果在项目中只是偶尔调用，是没有问题的，但如果被频繁调用，那么比较好的写法是在外部定义一个Action，然后将该Action传给Method来进行复用，即 Action act = New Action（MethodCallBack); void Start() { Method(act); } 该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/5a72f4dba69c4f5b6d1a9949 动画 Q4：我们使用的是老动画系统，动画是单独打包的，在运行时通过AddClip添加动画到模型上去，但是AddClip会触发RebuildInternalState导致波峰，那么大家是怎么解决这个RebuildInternalState触发的波峰呢，难道是只有老动画系统才会发生这个情况吗？ RebuildInteralState在Mecanim中也是有的，只是不叫这个名字了，而是变成了“Animator.Initialize”，两者的作用和触发时刻都差不多。 AddClip确实很耗时，这个在以前就是如此，所以建议如无特殊需求…

UWA官方Demo新增《小米超神》，全面揭秘重度手游的性能表现！
type: item
date: 2017-12-25T04:19:00+02:00
description: 还记得UWA【博观约取】专栏推荐的《小米超神》吗？作为一款重度的MOBA手游，它在不同配置的移动设备上，无论是画面表现力，还是性能开销都非常优秀。我们曾公布过该游戏的主要性能数据，当然其出色性能的背后和各方面的细节处理都有着千丝万缕的联系。为此，我们将该游戏的完整性能数据以UWA demo的形式公开，从而让大家更细致全面地感受其每个引擎模块的具体表现。 为什么重度游戏的性能如此小清新？不妨跟随小编的脚步一起到UWA官网上揭秘吧！ 再此特别感谢研发团队福州朱雀网络对UWA的认可和支持，也感谢他们乐于将项目性能数据与大家一起分享。 首先，我们登录UWA首页www.uwa4d.com，点击观看演示demo。 在性能诊断与优化的示例项目中选择《小米超神》。 同时我们也支持VR项目测评，大家可以点击下图右边的demo了解VR项目的性能报告。 下面我们来围观下《小米超神》的性能报告。下图为报告的性能总结页面。研发团队能从宏观上高效分析项目运行时的整体趋势，包括总体CPU性能、GC调用频率和引擎各模块性能等，同时也能根据同类型项目中的排名，对性能的薄弱环节一目了然，使得优化更加有的放矢。 UWA报告也可以协助开发团队从各个引擎模块（渲染模块、物理模块、粒子模块、动画模块、UI模块等）的微观处深入剖析项目的性能。下图即为UWA报告中渲染模块的耗时，可以看到该模块中有DrawCall、Triangle、半透明和不透明渲染耗时等参数的具体使用情况，条分缕析，疏而不漏。 UWA报告中能展现内存模块的详细使用情况，涵盖了几乎所有资源如纹理、网格、动画、音频等。不仅如此，各个资源的属性（如纹理的高度、宽度，数量峰值等）都一览无遗。在成百上千个资源文件中，即使再小的资源漏洞都无处遁形。 下图为《小米超神》的纹理资源具体使用情况。 90%的性能问题都和加载息息相关，而对于加载问题的定位这正是UWA性能测评的亮点之一，在《小米超神》报告中的资源管理界面中，对于加载/卸载的API调用使用情况，我们能一目了然。 我们可以看到资源加载和卸载的具体操作情况，不仅可以让用户看到整体加载耗时和加载次数，同时还可以通过图表来显示具体每次加载的位置和耗时。 下图为资源实例化功能，通过该功能，开发者能明确任何一个GameObject在实例化和销毁时的CPU占用情况：不仅可以看到最为耗时的GameObject，同时还能看到每次触发的时间点。 需要说明的是，上文提供的这些数据只是报告中的冰山一角，作为一支优秀团队精心打造的重度MOBA手游，我们强烈推荐大家多研究其报告中各个模块的性能细节以加深认知。同时，UWA真正想让大家看到的不仅是数据，更是数据背后我们研究问题的方式和厚积薄发的态度，这也是以后能切实帮到大家的东西。 温馨提示：PC上登录www.uwa4d.com即可以查看该游戏的完整性能数据。 UWA会员功能一览 简单优化，优化简单。这是UWA成立之初的愿景，我们希望UWA能帮到任何一个项目，哪怕是提速一毫秒。如果您的项目也存在运行卡顿、包体过大、资源冗余、内存泄漏、内存过大，代码效率低下、加载龟速等问题，不要犹豫了，时间不等你，让UWA为你助力！ 官网：www.uwa4d.com 官方技术博客：blog.uwa4d.com 官方问答社区：answer.uwa4d.com 官方技术QQ群：793972859（仅限技术交流）

专业的优化服务，就是为你争取时间！
type: item
date: 2017-12-13T11:48:00+02:00
description: 时间对于游戏研发团队的重要程度毋庸置疑，它不仅体现在研发成本上，还隐藏了另一个更重要的因素：机会成本，这从最近如火如荼的吃鸡大战即可窥见一斑。而性能优化作为研发过程中的必经之路，也逃不开这样的命题，这也是为什么UWA要反复强调时间的重要性：如果我们把项目的性能优化到极致，使得项目早一天上线，覆盖更多的用户群，则能把时间价值最大化地转换为可观的财富。 UWA的优化服务，就是在争取更多时间 在服务开发者的过程中，UWA的想法很简单，就是和时间赛跑：在最短的时间里，帮助研发团队找出最高效的优化方法，将性能优化的时间逐步缩短，从而为项目的顺利上线保驾护航。因此，UWA不仅能节省大笔研发开支，还能为项目的运营推波助澜。 在UWA优化过的项目中，项目的性能普遍都有明显的提升。下图为某一项目的性能提升变化，经过7～15天的密集优化，大于33ms的CPU耗时帧数占比从83.2%骤降至10.7%，不仅大幅度提升了游戏的运行流畅度，还很大程度上改善了游戏的发热情况。短时间内解决性能问题，这节省的不仅是大量可预估的研发成本，同样还有潜藏的机会成本。 性能优化不仅可以为你节省研发成本，还可以为整个项目的后期推广节省大量的运营成本。《一起来飞车》项目组反馈，游戏在经过优化后，用户留存率提升了10%。这是什么概念？我们不妨按照如下公式来做个计算： 假设导入的用户量为100万，由于性能的改善使得用户的留存率增加了10%，同时我们假设每个用户的平均获客成本为25元，那么游戏在优化后每导入100万用户，其运营成本就可以节省250万元。 目前，在UWA上优化的测评测试已达到上万次，UWA团队也有幸见证着不少品质精良的游戏的诞生，它们经过周而复始的匠心打磨，最终在漫如星斗的游戏市场熠熠生辉。 UWA性能测评报告的含金量有多高？ 在UWA主打的性能测评工具中，用户可以将其需要评测的项目上传至官网，在24小时内得到一份性能报告。这份报告既能从宏观上分析项目运行时的整体趋势，包括总体CPU性能、GC调用频率和引擎各模块性能等，也能从微观上深入剖析内存管理、资源使用以及逻辑代码在运行时的效率瓶颈。研发团队通过对报告提供的方案进行针对性的优化，能在短期内提升项目的运行效率。 以下为部分专业版功能介绍： 剖析资源的具体使用情况 详尽的资源信息展示，从多种维度（如资源名称、生存周期、内存占用、数量峰值、格式等）定位可能存在问题的资源，从而对“问题资源”快速定位、即刻优化。 轻松定位泄漏的资源 通过比较不同时刻同一场景（或不同场景）的资源信息，可以快速定位其资源使用的差异，只需判断这些“差异”资源的存在是否合理，即可快速判定是否存在资源泄漏，以及具体泄漏的资源。 AssetBundle驻留分析 不仅显示AssetBundle的具体使用情况，包括具体的AssetBundle名称，存放位置、加载方式、还能查看内存中的驻留时长和由该AssetBundle加载出的资源数量，查看是否存在AssetBundle泄漏，并判断使用是否合理的情况。 资源Resource加载/卸载定位 不仅可以让用户看到整体加载耗时和加载次数，同时还可以通过图表来显示具体每次加载的位置和耗时。 GameObject Instantiate/Destroy分析 让开发者明确任何一个GameObject在实例化和销毁时的CPU占用情况：不仅可以看到最为耗时的GameObject，同时还能看到每次触发的时间点。 GameObject Active/ Deactive 分析 某些GameObject的Active/ Deactive的频繁切换会导致大量的CPU耗时，该功能可对这些资源进行详细检测，查看是否有进一步优化的空间（比如纹理可检查其分辨率、格式等）；当研发团队明确了加载或者实例化的瓶颈后，可针对具体资源、GameObject进行缓存，从而降低其CPU耗时。 重要参数解析 深度剖析影响性能的重要参数，从CPU开销、堆内存分配、调用次数和调用路径等多个维度让用户的优化更加有的放矢。 定制化的分析建议，解决“你”的问题，方为优化 在用户得到的性能测评报告中，UWA结合丰富的项目优化经验，不仅能对每一个测试模块的数据给出合理的评定，同时对于超出正常范围的“异常”，UWA也能快速定位瓶颈的来源，即可提供有针对性的方案。 同时，所有UWA的专业会员，都能享有定制化的技术指导，以协助用户更深入地了解项目本身的性能问题，以及如何更合理地使用报告的高级优化功能进行针对性的改善，全程为项目的性能保驾护航。 简单优化，优化简单。这是UWA成立之初的愿景，我们希望UWA能帮到任何一个项目，哪怕是提速一毫秒。如果您的项目也存在运行卡顿、包体过大、资源冗余、内存泄漏、内存过大，代码效率低下、加载龟速等问题，不要犹豫了，时间不等你，让UWA为你…

MOBA手游《小米超神》案例精讲
type: item
date: 2017-11-21T10:33:00+02:00
description: 今天我们为大家带来由福州朱雀网络研发的MOBA手游《小米超神》的UWA测评报告分析。该游戏在不同配置的移动终端设备上，无论是画面表现力，还是性能开销都非常优异。在此，我们将对该款游戏的性能数据进行深度剖析，希望通过这篇文章可以让大家对移动游戏各个模块的运行效率有更为深刻的认知，并对大家的项目研发有所帮助。 一、CPU性能 该游戏在CPU占用方面的性能非常不错，下图为该游戏在红米Note2设备上进行一场5V5战斗时的性能数据。 可以看出，在红米Note2上运行的19876帧中，超过33ms的帧数占比为13.9%，超过50ms的帧数占比为1.7%，并且从图中可以看出，其CPU耗时较高处主要集中在5V5场景的资源加载阶段。因此，该游戏在战斗时的性能可以说是非常优秀，绝大多数时刻游戏运行非常流畅。 同时，通过进一步统计，该游戏的CPU性能超过了64%的同设备（红米Note2）上测试的其他游戏，其能耗更是低于86%的同设备测试游戏。由于目前国内的MOBA游戏较少，所以上述排名并不是在MOBA类型中的排名，而是在所有类型游戏中的排名。对于一款超重度的MOBA移动游戏来说，该CPU性能和能耗排名可以说是相当出色。 其整体CPU性能的优秀表现与其各个模块的合理使用是分不开的。下面，我们就详细讲解其CPU性能方面的亮点之处。 1、渲染模块 通过UWA性能测评报告，我们可以看到该游戏详尽的渲染模块性能开销。该游戏在红米Note2设备上运行时的渲染模块CPU开销如下图所示。通过统计，半透明物体渲染的CPU消耗均值为1.7 ms，主要集中在0.8~3.0 ms范围内（5%~95%）。不透明物体渲染的CPU消耗均值为1.0 ms，主要集中在0.2~1.7 ms范围内（5%~95%）。可以看出，在整个5V5战斗过程中，无论是移动、Farm、Gank还是团战，甚至上高地时，其渲染耗时都稳定在一个较低的耗时区间。这得益于研发团队对于场景模型、蒙皮网格和UI的控制十分得当。 Draw Call峰值为167，且主要集中在 45~130范围内（5%~95%），渲染三角形面片单帧峰值为64900，以上数值均处于合理范围之内。 2、UI模块 该游戏在红米Note2设备上运行时的UI模块CPU开销如下图所示。该游戏使用UGUI作为UI界面的解决方案。经过统计，UI模块总体的CPU占用均值为1.5 ms，主要集中在0.1~3.5 ms（5%~95%），属于合理范围之内。堆内存累积分配为16000帧 2.4MB，平均每帧分配堆内存155.4B，这说明该游戏UI界面的制作及UI重建的影响范围非常合理。目前，UWA推荐UGUI模块中，平均每帧堆内存分配尽可能控制在200B以下。 战斗场景中，UI系统的性能耗时主要是由UI元素的状态变化而导致的，比如血条、飘字等HUD的移动、消隐等。这种操作稍不注意，就会带来较高的UI网格重建开销。所以，UI界面的研发看似直观、简单，但是其对于制作时的层层考究和运行时的耐心调优，则是一款产品是否“匠心”的试金石。以下则为《小米超神》这款产品在经过几轮优化后的UI性能对比图。 3、动画模块 在UWA测评报告中，该游戏运行时的动画模块CPU开销如下图所示。可以看出，除进入场景时出现CPU高值外，其在战斗副本中的CPU开销均控制在较低水平。Animator.Update的CPU均值为2.0 ms，主要集中在0.1~4.3ms区间内，对于MOBA项目5V5场景来说，基本上每帧均有90-130个物体在进行运动（除英雄、小兵之外，还有信使宠物、野怪、塔、插眼等等），由于玩家可以随意查看地图上任何一个角落的特点，其每帧的动画系统压力要比常规的MMO游戏大上数倍。因此，《小米超神》可以将其控制在均值2.0ms的水平线上，已经是非常优秀的数据了。 同时，经过进一步检测发现，动画模块的耗时主要由Animators.ProcessAnimationsJob和Animators.FireAnimationEventsAndBehaviours导致，前者主要是持续的累积耗时，而后者则是非连续的“尖刺”开销。前者是动画系统对于AnimationClip的读取和计算耗时所致，其耗时大小与当前帧参与计算的骨骼节点数、动画曲线数、动画执行状态和Animator Controller的具体设置相关，其具体说明可参见《Unity中动画系统性能优化方案回顾》；后者则是动画事件的具体耗时，主要是项目逻辑代码的性能开销，此处研发团队可以通过性能堆栈来进一步查看其逻辑代码的开销是否有进一步的优化空间。 4、GC 调用 该研发团队对于GC调用频率控制得非常出众，游戏在运行过程中，GC调用频率为1656帧/次，优于目前93%的行业内游戏。一般来说，我们建议一款项目的GC调用频率可以控制在1000…

如何实现更真实的软阴影效果
type: item
date: 2017-11-17T05:41:00+02:00
description: 现实中，在地面上的人影往往因为被投射的物体是粗糙不光滑的，所以影子的轮廓也是有些模模糊糊，没那么棱角分明。在最新的游戏项目中，美术提出我们应该也做一个更柔和、更真实的实时阴影（本文中提到的阴影都是投射在其他物体上的影子，区分于自身的阴影）。 对于这个需求，并没有自造车轮，而是找了一个很好的轮子让它转了起来，我们可以先看一下目前我们项目中影子的效果： PK沙滩1中主角与小怪带着柔和的实时影子 其实Unity本身自带了Soft Shadow的选项，但是有些缺点（下文会具体比较说明）。 在我们的工程里，选用的是NyanHoon Games的「Dynamic Shadow Projector」 官网：http://nyahoon.com/products/dynamic-shadow-projector，在Asset Store就有，免费下载。 这里将这个插件的软阴影与Unity自带的软阴影做一些比较。本篇文章所有测试的条件如下：手机为OPPO A37m（CPU：1.5Hz，内存：2GB，GPU：Mali-T860），目前是一款中低档的手机；场景中放置共13个人物模型；使用白色Directional Light；如无特殊说明，截图和数据皆来自手机。 一、Unity自带Soft Shadow的情况 参数： 参考我们现在的项目，Directional Light，选择Soft Shadow，Quality Settings中的Shadow设置为High Resolution， 70 ～20， Two Cascades。 有一个选项，Shadow Projection，它对于影子的质量影响很大（官方说明：平行光投射阴影有2种方式：Close Fit渲染较高分辨率的阴影，但是如果相机移动时，有时阴影会轻微摆动。Stable Fit渲染的阴影分辨率较低，不过相机移动时不会发生摆动。） 真机情况： 左侧为Unity自带Stable Fit真机表现，右侧为Close Fit真机表现 最开始我尝试的是Stable Fit选项，出来的效果不忍直视（左图）。换成Close Fit后，锯齿问题相当明显的被改善了，但这样造成的问题是性能开销上大幅度的上升。仅从SnapGragon的CPU利用率来看，从比较稳定的40%，增长到了60%左右，而且十分不稳定，有时甚至会跳到70%。 Stable Fit的SnapGragon截图 Close Fit的SnapGragon截图 二、使用Dynamic Shadow Projector 且不开启任何Blur或重采样选项的情况 左侧为插件512分辨率，右侧为1024分辨率 第二组以及下面的第三组测试，都是同时处理区域范围内所有的人物（13个模型），将其渲染到同一张Texture上进行处理。本组实验使用了插件，但是并没有开启附加功能，例如Blur或Mipmap。 上图左侧是分辨率512，右侧是1024，我们目前的项目里用的就是1024的分辨率。可以看到锯齿情况有所改善，但如图所见，依旧有着明显的锯齿，因此个人认为单纯提高分辨率意义不大。不过性能上，真机的CPU利用率，512的为44%左右，1024为53%左右，增长都不多。下图是1024的SnapDragon截图。 插件1024分辨率的SnapGragon截图 三、Dynamic Shadow Projector开Blur的情况 第一张手机截图是512分辨率开Blur，第二张为1024的Blur效果。1024的情况下，影子会多很多细节，但是若追求的是比较模糊的软边影子。其实512的就足够好了。对比第一组的Unity自带软阴影可以感觉到，Unity的Soft Shadow真的是一点都不Soft。 再比较一下性能。可以看到512的时候开了Blur，CPU占用率也是44%左右没什么太多。但是1024的时候CPU性能一下子升到了70%，不过跟Unity的SoftShadow的Close Fit形态比，也就多了10%。 分别为插件512分辨率开Blur，和1024分辨率开Blur的真机效果 插件512分辨率开Blur的SnapGragon截图 插件1024分辨率开Blur的SnapGragon截图 这个插件的Blur选项主要是多做了一步Graphics.Blit。针对这个函数，在Profiler上查看了一下手机GPU的情况。可以注意到从10%占用率，4ms左右增长到了24%占用率，13ms左右。 上下两张分别为插件在512分辨率和1024分辨率开Blur时，Blit函数的真机GPU使用情况 这里附上一下改变了光照颜色后的效果： 左右图分别为Unity自带软阴影与插件512分辨率开Blur时，在黄色Directional Light下的效果。可以感觉到，右侧插件带着Blur的效果，软边…

技术分享连载（八十一）
type: item
date: 2017-10-10T04:37:00+03:00
description: 本期话题：打开界面GC过高、动态字体的性能耗时、AssetBundle卸载方法对比、把字体文件裁剪之后对内存和效率的影响是什么、如何优化背包问题... 今天是节后首个工作日，小编又安利了5个营养丰富的技术答疑，让这股知识的清流来缓解下工作上的鸭梨吧！建议阅读时间10分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 资源管理 Q1：我们知道，卸载AssetBundle有两种方式，Unload(true)和Unload(false)，一开始我用的是Unload(false)，好处有以下几点： 1）开销比Unload(true)小，不太影响体验； 2）对于场景自己的AssetBundle，通常文件本身比较大，可以加载完地图之后直接调用Unload(false)； 3）不会销毁正在使用的资源； 4）可以一边加载某些AssetBundle一边销毁另一些AssetBundle，并行处理。 但是实际上用下来，发现会产生资源泄漏问题。虽然代码已经很仔细的检查过了，但还是难免会发生有C#代码引用到某些资源，从而造成AssetBundle释放之后，这些资源释放不掉(UnloadUnusedAssets没用，除非UnloadUnusedAssetsIgnoreManagedReferences) 这个时候我想到了Unload(true)，虽然确实可以解决资源泄漏的问题，但产生的问题正好和上面相反： 1）开销大； 2）场景不能加载完之后直接卸载，一边加载一边卸载可能会有崩溃； 3）比较暴力，可能会出现删除正常资源的风险。 请教下大家是如何考虑这个问题的呢？ 正如题主所说，两种方法都有各自的优缺点，但就从目前的统计来说，使用Unload(false)的项目占据绝大多数。 就UWA而言，我们比较推荐Unload(false)这种卸载方式，因为Unload(true)过于粗暴，可能会增大删除正常资源的风险。 对于Unload(false)会带来资源泄露的问题，需要研发团队进行更为谨慎的控制。但这种泄露是有方法避免的，题主可以定期定时（如每周）通过UWA GOT或线上性能检测来对项目版本进行定制测试，通过场景之间或不同帧之间的资源增量信息来规避资源泄露问题，这种问题越早发现，越容易解决。 该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/59cca2a4430dd9a1336b8b7c UI 制作 Q2：我们项目中在做UI的时候，需要对选择出来的图片路径加个判断，只有某个路径下的图片才可以选上。通过[CustomEditor(typeof(UnityEngine.UI.Image))]无效。不知道还有没其他的接口可以修改图片的Inspector？ 建议题主试试扩展下 Image 组件，比如创建一个 XImage 组件来继承 Image，然后通过 [CustomEditor(typeof(XImage))] 来修改 XImage 的 Inspector。 该问题来自UWA 社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/59d9ca49268e715701c74f37 动画 Q3：一个Scroll Rect内有Grid，而Grid下有多个子对象，每个子对象状态使用Animator控制。这个控制在资源工程本地处理无问题，但是在打包加载后出现了刷新问题。具体情况如下：Animator对象在加载并切换状态后，引起了不间断的Layoutrebuild操作，从而引起UI较大的卡顿。这一操作在Disable了对象的Animator脚本后就停止，再开启就继续出现。不知是否有什么解决方案呢？ 动作播放停止后，相当于是持续地赋值同一个值，而Recttransform的Scale只要被赋值就会被认为是Dirty的，从而就Rebuild了。所以这种情况只能禁用Animator了。 该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/59cc726a430dd9a1336b8b7a 字体 Q4：我在Unity文档里看到，如果要渲染的字不在字体数据里，Unity最终会去访问当前平台的系统文字。我想问下，把字体文件裁剪之后对内存和效率的影响是什么？ 内存： 这时候Unity是会加载系统文字，还是系统文字本身就在系统内存里了呢？这部分系统文字的内存是怎么算的？还是说无法避免呢？ 效率： 这边时间消耗是怎么样的…

技术分享连载（八十）
type: item
date: 2017-09-26T11:17:00+03:00
description: 本期聚集话题：LightingDataAsset Delete后Lightmap展开问题、Gamma和Linear颜色空间问题、AlphaTest和Alpha Blend的性能差异... 我们将从日常技术交流中精选若干个开发相关的问题，建议阅读时间15分钟，认真读完必有收获。如果您有任何独到的见解或者发现也欢迎联系我们，一起探讨。 UWA QQ群：793972859 UWA 问答社区：answer.uwa4d.com 制作 Q1：我这边做了个测试，把场景中的物件进行StaticBatch，用Lightmap烘焙，并且在烘焙完记录每个物件Renderer的lightmapindex and offset，然后在运行中，我删除了生成的LightingData.Asset，自己设置了Lightmapsetting，并且恢复了每个物体Renderer的Lightmapindex and offset, 结果我发现烘焙出来的场景Lightmap还是不对的。我怀疑是不是LightingData.Asset 还记录了别的东西，想问问看UWA有没有什么经验呢？ 我在answer.uwa4d.com上打包一个测试用例，打开Scene/LightMapTest.unity 这个场景即可。 这个问题还是出在Static Batching上。经过测试我们发现如果去掉场景中物件的“Static Batching”标记，换成手动Batching，即采用StaticBatchingUtility.Combine的方式结果就正确了。 同时，我们发现使用LightingData.Asset时，开启Static Batching与不开启都正确，因此我们认为LightingData.Asset可能记录了与CombinedMesh有关的数据，导致如果仅仅使用gameobject的LightMap参数无法正确读取CombinedMesh的LightMap UV。另外一种可能是Unity的一个Bug。 最后，我们建议采用上述手动Batching的方式，即可解决此问题。 该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/59c0d16c5cd7219d3bbfb3b3 制作 Q2：我们场景中有两种Unlit物体，一种是在脚本中通过Mesh顶点色（Mesh.colors）赋颜色值，一种是用Shader属性传递颜色值，在Gamma颜色空间时两种物体的渲染颜色是一致的： 但是切换到Linear空间发现不一样了，如下图，左边是顶点色，右边是Shader属性颜色： 顶点颜色和属性都没改过，只是切换了颜色空间，请问是什么情况？ 我能想到的有两种可能性： 1）顶点色的颜色值在Shader中没有被正确处理； 2）右边使用贴图的导入设置中sRGB的选项有错误。 看上去左边的在线性空间下变亮了，而右侧的方块颜色在两种Space下差别不大，因此推测第一种的可能性比较大，顶点色在很多情况下并不被当作颜色处理，而作为值来存储，所以有可能这里处理有问题。至于为什么变亮了，感觉是值经过了伽马校正变大了。 Unity有接口在两种颜色空间下转换，建议题主可以查一下，在Shader中修改代码来排查下是哪里的问题。 该问题来自UWA 社区，感谢贾伟昊提供了回答，如您对该问题仍有疑问，可以转至社区进行进一步交流。 https://answer.uwa4d.com/question/59c387de79a00b1e16da7414 UI 制作 Q3：当使用Linear设置时，UI上图片透明度等也跟着变化，出来的效果与美术人员的需求不一样。请问有什么办法可以让UI不使用Linear或者让UI可以在Linear影响下也正常呢？ 推荐题主可以看下这个帖子 https://forum.unity.com/threads/bug-with-bypass-srgb-sampling.282469 “When switching to linear mode it (greatly) changes how blending works, this is because when sampling only the rgb channels are linearised as it is assumed the alpha is a linear scale representation already.” 简单说，这是正常现象，里面有三种解决方法： 1）改资源的 alpha 通道： Reauthor the content for linear blending (this is supported in photoshop). …