游戏客户端性能测试总结

 性能测试是一名高级工程师必备的技能之一，也许你在工作中用不到，但至少需要对相关内容进行了解。结合我的实际工作，对性能测试进行阶段性总结。性能测试需求，我将它分成两大模块，一部分是产品迭代过程中对性能优化（逆化）判断，从而为开发提供性能瓶颈和优化方向；另一部分是产品对比，一般是竞品之间的性能对比，找到与竞品之间的差距，通过技术定向优化赶超竞品，优化体验。

在性能测试过程中如何判断性能优化或逆化，需要选定对应比较版本，在数据采集过程中，至少有两组数据，实验组和对照组。简单点说就是实验组数据与对照组数据进行对比，看性能变化。实验组和对照组采集数据，在操作中我们需要严格控制好变量，确保收集的数据是有效的。还有一种是根据性能标准来看获取的性能数据是否符合标准，具体标准需要结合不同场景和设备硬件给出相应标准。

性能优化的结果其实也可以细分为整体性和局部性能。游戏中场景多，优化和逆化有时候从宏观的角度是很难说明性能差异的，因此，整体性能有时候并不能反馈出游戏中某些卡点。比如多人在线竞技场景，对手机性能要求更高，在测试过程中，如果性能波动会比较大且性能数据采集过程中，这部分采集不充分。而其他性能指标良好的情况下，采集时长充分，该性能在整体性能数据下是可接受的（性能不好的部分被平均，看起来就比较好）。但是，并不意味着不存在性能卡点问题，因此，我们在做性能测试过程中需要对局部性能，特别是容易出现性能问题的场景进行单独的性能数据收集，以确保最终的性能报告是客观完整的。

需求：性能测试优化点是什么？

需求获取方式可能是文档，我们可以通过对文档内容进行理解，但是文档内容于实际已经开发是否一致需要与对应开发进行确认。确认目前已经完成的性能测试优化点需求。

1. 通过与开发交流，了解优化的实现方法，前端的具体表现是什么。
2. 通过与开发交流，了解优化覆盖范围，或者在哪些特定场景上容易触发该优化方案。
3. 通过与开发交流，了解开发对性能指标变化的预期，如FPS，内存消耗，网络消耗等性能指标变化预期。
4. 通过与开发交流，了解开发自测方法。一般开发的自测方案基本上集中了优化点变化，可基于此在后续的分析和用例设计上进行补充。

分析：如何才能将优化点通过工具将性能指标获取到？

分析在性能测试过程中很重要，决定了测试策略和具体步骤，是否能够获得有效性能指标的关键。在着手测试前，需要结合经验和对需求的理解，制定测试策略和测试步骤。

1. 结合需求分析，固定测试场景和路径，尽可能保证每次执行都是可重复，且独立的。
2. 整体性和拆分性，优化需求可以从整体和拆分性维度进行设计。在实际的优化方案中，从整体的性能提高上存在较大瓶颈也很难做到一次性对整体性能的大幅提高。这个时候我们就需要对优化方案进行拆分，对于游戏某些节点或操作的关键帧进行测试分析。
   1. 整体性测试：整体性能差异，尽可能还原玩家角度和操作习惯。
   2. 拆分性测试：优化点测试，优化前后某几帧的性能变化。通过该数据可以有效说明优化是有效的。

通过分析，我们可以得出测试策略以及测试方法。为后续收集数据和分析打下基础。

场景：在测试过中如何选取测试场景？

测试场景其实依赖于需求，需求优化场景是我们主要关注的对象。在实际测试中测试场景主要是集中在主要的玩法上。我们需要收集主要玩法在游戏过程中的性能变化曲线。还需要额外收集一些特殊场景的内存进行分析，例如PvP战斗结束，公共场景待机，战斗中等。

主要玩法：关注的性能指标如FPS，内存，CPU，GPU，流量等相关指标。该部分是游戏的主体卖点，性能各项指标决定了玩家的游戏体验。

其他玩法：如待机，公共场景待机，休闲，结算等也需要对内存进行关注，避免长时间待机内存过大导致内存溢出而崩溃的问题。以及在战斗场景结束后，大量的堆栈内存释放。因此，需要对结算界面进行关注，避免内存释放导致消耗。loading 时间，场景loading时间长短对于玩家的体验至关重要，可以同类型游戏横向对比loading时长。

操作：在测试过程中，如何避免无效数据收集？减少测试成本？

操作也是整个性能测试的关键，如何控制变量？这里的变量是多维度的，硬件状态（如温度），程序状态（如不确定算法或场景随机性）都会导致每次执行的结果均有一定偏差。

1. 硬件状态在有条件和时间的情况下，可以测试完一组数据后放置几分钟。
2. 需要连续在同一台设备上采集实验组和对照组数据，不具备测试完放置一段时间的情况。这时候，我们可以通过ABA的方式进行数据采集，让设备状态和数据通过间隔执行的方式减小累积多次全A或全B导致的设备状态差异。
3. 合理利用冷启动，减少app本身状态差异带来的影响。在使用GM指令构建测试环境后，即时游戏本身在GM生效过程中重启游戏，也需要在确保环境构建成功后对其冷起，尽可能减少变量。
4. 数据可靠性，在采集数据时出现异常（非计划内路径或其他）这类数据是不可靠的，可以直接舍弃减少数据分析时带来的干扰。
5. 数据采集符合预期，采集方式有效，如果采集的数据不符合预期，不要急于下结论，需要考虑是否是设备本身导致，需要替换设备验证。如果验证是设备问题，该台设备大概率存在兼容性问题。如果验证非设备问题，大概率是优化代码造成的非预期的逆化现象需要程序针对性定位修复。

数据分析：如何在采样数据中有效甄别有效数据？

数据分析是基于需求本身的性能优化点针对性分析，比如任务【无尽模式无阴影优化】主要优化手段是对拖拽处理逻辑。我们在设计好数据采样场景后（尽可能保持一致的操作路径，减少变量），采样需要只针对于拖拽场景。如下图分析时应该分为前后两端去验证数据，中间非拖拽导致的帧率变化需要排除。

从前半段为新手流程的拖拽可以看出，开启特性的形况下平均PFS明显高于关闭的时候：

从后半段为非新手流程的首次拖拽分析得出的结论依旧，开启特性的形况下平均PFS明显高于关闭的时候：

总结两次采样控制非常好，从图形上看走势基本保持一致。这样的情况从整体的平均数也能一定程度反应拖拽优化的性能优化，但说服性相对于只分析拖拽带来的变化更弱，且想在实际的操作中做到如此接近的场景所消耗的测试采样时间更久，更困难。因此，在数据采样和分析中学会有效分析和选取数据是提高效率的核心手段。该案例是在原来设计的测试用例下对已收集数据进行的数据有效性分析。可以适当增加对该优化方案更直接针对测试，设计只拖拽场景（不进行放置块），控制被拖拽的块一致，时间上可以适当增加如30s或60s。然后对期进行数据分析。另外，还可以结合特殊场景，合理利用冷启动的边界场景覆盖全面。测试点如下：

用例模板：

性能指标：

性能指标都有哪些，从何而来？如何判断这些指标是准确的？性能指标及其标准定义需要结合用户体验、硬件限制和行业标准白皮书。

• 性能指标标准的定义方法：

  • 行业参考与竞品分析
  • 用户场景与设备限制
  • 量化分级标准

• 核心性能指标

  • 流畅性指标
    • 帧率（FPS）：每秒渲染帧数，直接影响画面的流畅度。
      • 标准：静态画面≥24FPS(电影帧，人眼连贯性阈值)，动态操作≥60FPS(理想值)核心玩法90%要达到这个标准，复杂场景不低于30FPS
      • 补充：游戏中有静态页面，一般情况下游戏内部FPS值保持在60PFS是最稳定的，低端设备也需要达到最低的30PFS以上。特殊场景如动画/剧情，电影级内容通常采用24-30FPS（电影标准），若性能允许也可以升至60FPS。
    • 卡顿率：卡顿帧占比（单帧耗时超平均2倍且>16.66ms）
      • 标准：高端机≤2%，低端机≤10%
  • 资源消耗指标
    • CPU占用率：逻辑计算与渲染人物消耗的CPU百分比
      • 标准：空闲状态接近0%（后台挂机），中等负载≤30%（常规操作），高负载（如战斗）≤50%。
      • 补充：空闲状态指将应用切换至后台，停止所有用户交互，进入待机状态，测试时收集30s以上数据。中等负载，执行操作操作如点击、页面切换，持续5到10分钟，监控CPU波动。高负载，触发游戏核心玩法或极限操作（战斗或复杂的特效场景），一般CPU占用需要≤50%，部分高帧率游戏可接受小于等于80%。测试时连续运行高资源消耗功能，记录峰值CPU使用率及稳定性。
    • 内存占用：物理内存（PSS）与内存泄露
      • 标准：PSS不超过系统总内存的30%，内存泄露需通过工具（如LeakCanary）实时监测
      • 补充：VSS虚拟内存总量（含未分配物理内存）包括所有虚拟地址空间，通常远大于实际物理占用，用途有限。RSS实际物理内存（含全部共享内存）可能高估进程内存，因共享内存重复计算。USS进程独占物理内存仅统计私有内存，用于检测内存泄漏。PSS表示进程实际使用的物理内存，其中共享内存（如共享库）按比例分摊到所有使用该内存的进程。PSS通过比例分配共享内存，解决了RSS的重复计算问题，是评估进程实际内存占用和系统整体内存压力的核心指标。但在分析内存泄漏时，需结合USS（独占内存）进行精准定位。
    • GPU负载：渲染管线压力（如DrawCall、三角形数）
      • 标准：DrawCall ≤500，三角形数≤50万/帧
      • 补充：GPU利用率低但帧率不足，CPU瓶颈或数据传输延迟 ，增加分辨率以平衡负载，关闭后台进程  ；Overdraw过高 ，半透明物体过多 ，减少粒子数量，合并UI图层；GPU带宽持续高位，纹理未压缩或分辨率过高，使用ETC2/Astc压缩，优化Mipmap层级；片元处理单元过载，复杂Shader或UI密集，简化Shader计算，减少全屏后处理效果。

  • 稳定性指标

    • ANR（无响应）：主线程阻塞超过5秒（Android）
    • 崩溃率：崩溃次数
      • 标准：通用目标≤0.1%，金融类app需≤0.01%

  • 启动与加载效率

    • 页面加载时间：用户到内容完全展示
      • 标准：核心功能（如支付）≤1秒
    • 冷启动时间：从点击图标到首帧渲染完成
      • 标准：≤1.5秒（行业通用）

  • 能耗与发热

    • 功耗：单位时间电量消耗  
      • 标准：视频类App≤15%/小时，王者（5%-10%）/小时，原神（8%-18%）/小时、和平（5%-18%）
      • 补充：功耗与硬件性能，画质和后台活动均有关系。可以根据游戏类型参考以上功耗数据。优质游戏App≤10%（中画质）

  • 网络性能

    • 流量消耗：单位时间流量消耗
      • 标准：王者（50-200MB）/小时，原神（80-200MB）/小时，和平（50-150MB）/小时。
      • 补充：开启语音功能会增加约20%的流量。画质降低，帧率降低也可以减少流量的消耗。云游戏流量消耗较高，约2-4GB/小时
    • 延迟与丢包：弱网环境（2G/3G）下，核心功能可用

  • 性能指标示例：

其他：不同的测试需要需要不同的设置和关注点

性能测试指标不同，测试方法本身也会存在差异。

1. 如针对能耗（电量）的测试，在使用测试工具时需要使用wifi链接状态。需要测试工具和待测试设备使用同一个网络。
2. 无线连接，一开始需要物理连接，在物理连接状态下完成wifi连接，工具会提示断开物理连接。
3. 如针对FPS的测试，就不能使用wifi链接状态，需要使用物理链接方式。不同的链接方式会导致指标存在非常大的差异。

补充知识：冷启动和GM命令生效重启的差异？

冷启动是游戏从关闭状态切换到活跃状态的过程，整个过程有资源加载，程序初始化，编译等。

GM重启，可能是针对性的activity或者进行的重启，重启过程中，会跳过冷启动的编译和部分程序初始化过程，存在数据残留风险。

因此，我们在测试游戏启动耗时时，不能使用GM指令进行重启，这种重启与冷启动是存在差异的，收集的数据不能准确体现现阶段的性能情况。