今天给大家带来的案例分享来自于一款使用了UWA GPM 2.0的二次元共斗ARPG手游。该项目以其精美的角色立绘、炫酷的技能特效和爽快的战斗节奏，在测试阶段便吸引了大量玩家的目光。当然，更好的画面品质同样也意味着会带来更大的性能挑战，只有玩家真的“玩爽了”，才能真的放下心来。以下我们将着重描述通过GPM 2.0发现的高功耗引发的GPU瓶颈，以及UWA建议的优化方案。
功耗
通过GPM 2.0的截帧功能发现，在游戏的一些主要场景中，当画面内出现一些比较华丽的特效或大面积的阴影时，通常会出现一些较高的功耗均值与峰值，某些情况下甚至会出现10000mW以上的极高值。
10000mW高功耗处截帧显示在大场景中进行战斗
8000mW高功耗处截帧显示正在释放某个特效
功耗作为一个和耗电量、温度直接相关的性能参数，其优劣表现也很容易为玩家所感知。在功耗均值较高的时候，我们发现有玩家的设备上8分钟内就耗电6%；而在一些集中出现技能特效的设备温度持续上升达到了60℃以上，并最终导致了CPU的降频从而造成FPS掉帧的情况。
针对这些情况，UWA建议项目组结合UWA GOT Online工具，验证和定位导致高功率的原因和其性能影响。
举例来说，在小米12（SOC为骁龙8 Gen1）这一高端设备上测试，复现了游戏运行过程中功率过高的现象。根据UWA结合大量项目经验和定量测试给出的推荐值来看，当前硬件设备和对应画质分级下的功率开销远超合理水平，这必然地会造成严重发热。
同时，报告中还有一些参数曲线和该性能问题强相关。首先，可以看到进入主要游戏场景后，温度峰值确实飙升到80°C；紧接着，发现温度和帧率曲线都存在随着测试时间增加而大幅波动的现象，甚至紧接着大幅下降。这种变化趋势和CPU大核（CPU 8）的频率变化趋势非常相近。可见，高功率不但可能导致玩家体验时手感发烫，更多时候则是会因高温触发硬件的保护机制产生降频，使得芯片算力下降，从而导致掉帧。
那么，已知发热问题严重的前提下，如何定位问题呢？在UWA GOT Online Overview模式报告的模块耗时统计中，在发生降频、各个模块耗时都有所上升的前提下，多数模块的耗时都仍在推荐值范围内或超出推荐值不多，尽管逻辑、物理等模块可能仍有进一步改进的空间，但基本可以推断CPU端压力并非功率过高和发热的主因，此时可考虑关注GPU端的压力。
在设备OPPO Reno9 Pro（SOC为天玑8100-Max）的GOT Online GPU模式的专报告中发现全程GPU Clocks偏高，符合UWA定义的GPU Bound概念，即游戏运行时渲染画面所需要的GPU算力，总是迫使GPU以最高频率运作，此时功耗发热显然远比低压空闲时严重，并可能导致掉帧。
该项目和众多近两三年来UWA发现的存在GPU压力的项目存在一个共同点，即GPU压力的主要来源大概率为片元阶段的计算开销。由下图参数可知，GPU在每帧中所要执行的Fragment Shader次数过多、也即每帧绘制的像素过多，这说明项目的渲染分辨率（即GPU画一遍屏幕的像素数量）和Overdraw（即绘制多少遍屏幕）两个因素过高，乘积导致了GPU渲染压力。当然，有的项目的片元计算高压的主要瓶颈来源于复杂的Fragment Shader计算，同样需要引起关注。
其中，结合开启“Resource”采集后获取的Render Texture资源列表是分析片元计算压力的重要手段之一。如图例，该项目中使用了默认的真机分辨率进行渲染；使用了SMAA、Bloom等常见开销较大的后处理等。这些渲染策略都可能对功耗发热问题产生巨大贡献。UWA推荐的一种方式是使用开关对比测试评估这些方案和优化策略对自身项目的实际影响幅度，通过上述GPU和硬件的一系列参数的变化体现出来。
而在Overdraw层面，GOT Online GPU模式还提供了Overdraw快照功能定位高压场景中导致过高Overdraw的渲染对象，常见的如技能特效、场景特效、UI元素等。定位后，再针对相应美术资源进行优化以大幅提升性能。
在GPU模式中，除了上述GPU Clocks相关的参数需要排查外，还有一个重要参数直接影响GPU端的功耗发热问题，即GPU带宽。在示例项目中的主要玩法内，带宽持续在7-9GB/s，远超常见移动项目水平，已经达到了会显著导致发热的问题。针对带宽，则可结合页面下的相关参数，排查纹理采样方式、渲染策略使用、顶点数量等常见导致高带宽的问题。
通过以上流程，便定位了这样一个功率严重过高、发热已经导致降频的项目的性能瓶颈，并获得了相应的执行优化工作和验证优化结果的方法论。
内存
GPM 2.0报告显示，有36.97%的Session报告中PSS内存峰值均超过了2000MB，部分设备的峰值甚至达到了4000MB以上。由于玩家所使用设备中，目前玩家设备中6GB RAM和4GB RAM的设备占比各占5%（共10%），而目前项目的高内存占用已直接威胁到这些设备的稳定性，极可能引发OOM崩溃。
例如游戏中的内存占用随时间持续增长且无释放趋势，这是一种非常明显的、疑似PSS内存泄漏的内存走势表现。在80分钟的时长中，内存从1GB增长至约4GB。
针对内存泄露问题，UWA建议进行较长的测试流程，或重复进出关键玩法场景的专项测试以复现泄露问题，使用GOT Online “资源对象快照”功能，对比场景切换前后的内存分配差异，定位未释放资源。
但这种适用于很多常见存在内存泄漏问题项目的思路对于当前示例项目而言并不完全适用。如图为在20分钟内反复进入切出游戏的主要玩法场景后，项目的纹理资源内存曲线。该项目的各种资源内存基本都类似纹理资源，即在反复的场景切换过程中能够及时释放和卸载，呈现“城墙式”有升有降的曲线，应认为相关的资源加载卸载的管理策略是较为合理的。当然，这些资源的内存基数仍然超过推荐值较多，具有结合资源列表进一步排查优化的价值。
那么泄露的原因是什么呢？在报告中另一种类的内存曲线中可窥一斑。Mono堆内存（即C#托管堆内存）在测试过程中呈现了大幅度的持续上升趋势，泄露现象明显。此时可结合GOT Online Mono模式测试，进一步定位存在泄露的函数堆栈或堆内存对象，从而回到代码中进行优化。
不过，根据UWA近年的经验，随着移动端项目体量整体增大，本身资源和代码量持续上升、使用的各类引擎功能和外部插件也越来越多，很多项目的内存性能分析变得更为复杂。上述资源、Mono这两种仅是多种多样内存问题中相对较常见的两种。
随着越来越多的项目团队开始注重玩家实际游玩过程中的体验，线上项目的质量监控正在逐渐流行。 UWA GOT Online和GPM 2.0作为分别对应测试包与线上包的性能检测与监控工具，已在多个项目团队身上证实了他们可以形成的高效闭环。 GPM 2.0的宏观数据让我们看清问题的全貌，而GOT Online的微观分析则让我们精准切入每一个性能瓶颈。 从内存泄漏的排查到GPU瓶颈的优化，从低配设备的适配到高功耗场景的调优，两者的无缝配合让性能优化不再是“盲人摸象”，而是有据可依、有法可循的科学实践。
关于GPM 2.0
GPM 2.0 是一款专为上线或测试阶段的游戏项目打造的高效性能监测工具。它不仅深入捕捉宏观性能数据，还通过其独特的性能无损截图功能，让开发者在不影响玩家体验的前提下，全面掌握玩家运行时的关键细节，从多个维度优化游戏的性能表现，提升整体用户体验。
如果您的项目也希望体验GPM 2.0的强大功能，欢迎随时与UWA取得联系。我们将为您提供免费试用机会，并在试用期间全程支持服务搭建、数据分析与反馈，确保您能够充分体验GPM 2.0带来的价值。
联系UWA：
邮件：sales@uwa4d.com
微信号：17502188376
