使用 UWA Gears 定位游戏内存问题

UWA Gears 是UWA最新发布的无SDK性能分析工具。针对移动平台，提供了实时监测和截帧分析功能，帮助您精准定位性能热点，提升应用的整体表现。

内存不足、内存泄漏和过度使用等问题，常常导致游戏出现卡顿、崩溃，甚至影响用户体验。本文将详细介绍Gears-Realtime模式中Memory Detail参数，并通过实例演示如何定位和解决游戏中的内存问题。

1. 深入分析内存细节：Memory Detail

要深入地理解内存问题，我们可以借助Memory Detail参数，查看应用内存的具体分布和使用情况。

总体内存使用情况

• PSS Total
  PSS Total（Proportional Set Size）是衡量进程实际占用物理内存的重要指标，它通过按比例分配共享内存来计算应用的物理内存占用情况。PSS Total通常在应用加载大量资源或数据时增长，如启动新场景或关卡。如果PSS Total持续增长，可能意味着存在内存泄漏或资源未及时释放的问题，长此以往可能导致设备内存耗尽，进而导致应用崩溃。

• Unknown
  Unknown内存表示未归类的内存使用，通常代表应用中没有明确分类的内存分配。当应用中某些资源或数据无法被现有分类系统识别时，Unknown内存可能会增长。持续的Unknown内存增长可能表明有资源未能及时释放，或某些内存分配没有被合理管理，这可能导致内存泄漏和资源浪费。

堆内存使用情况

• Native Heap
  Native Heap是由C/C++代码分配的堆内存，主要用于存储应用中的原生对象和数据。Native Heap通常在应用使用复杂的C/C++算法或加载大型原生资源（如音频、视频文件）时增长。如果Native Heap占用持续增加，可能意味着存在内存泄漏，或者分配的内存未能及时释放，这将导致内存碎片化和应用性能的下降。

• Dalvik Heap
  Dalvik Heap用于表示Dalvik虚拟机管理的Java对象的内存占用情况，是Java应用中内存使用的主要指标。Dalvik Heap会在创建大量Java对象或加载大量Java资源时增长，例如运行复杂逻辑或大量实例化对象时。如果Dalvik Heap增长过快，可能引发频繁的垃圾回收（GC），导致应用性能下降和用户体验不佳。

图形渲染内存使用情况

• GL mtrack
  GL mtrack监控与OpenGL图形渲染相关的内存使用，包括纹理和渲染缓冲区的内存分配。在加载高分辨率纹理、大型3D模型或在高负载的渲染场景中，GL mtrack的内存占用会显著增长。如果增长过快且未及时释放，可能导致GPU内存不足，引发帧率下降、渲染延迟甚至应用崩溃。

• EGL mtrack
  EGL mtrack与EGL（OpenGL ES的原生窗口系统接口）相关，监控EGL资源的内存使用。在应用中频繁创建和销毁EGL上下文时，EGL mtrack的内存占用会增长。如果这些资源未能及时释放，会导致内存浪费，并影响图形渲染的性能。

• Gfx Dev
  Gfx Dev表示与图形设备相关的内存使用，通常用于管理GPU的渲染资源。在进行复杂的图形操作或处理大量图形数据时，Gfx Dev的内存占用会增加。如果增长过快，可能导致GPU资源紧张，进而影响渲染性能。

内存映射使用情况

• SO mmap
  SO mmap用于表示共享库的内存映射，主要涉及.so文件的内存使用。在应用加载多个共享库或动态链接库时，SO mmap的内存占用会增长。如果共享库数量过多或未能及时卸载，可能导致内存占用增加，并影响应用的启动时间和运行性能。

• JAR mmap
  JAR mmap表示JAR（Java ARchive）文件的内存映射，主要用于管理Java类库的内存分配。在应用加载大量Java类库或资源时，JAR mmap的内存占用会增加。如果未能合理管理和释放这些资源，可能导致内存占用不断增加，影响应用的性能和响应速度。

• APK mmap
  APK mmap表示APK（Android应用程序包）文件的内存映射，主要涉及应用自身资源的内存使用。在加载应用的资源文件（如图片、音频、视频）时，APK mmap的内存占用会增加。如果这些资源未能高效管理，可能导致内存占用增加，影响应用的启动速度和运行效率。

• DEX mmap
  DEX mmap表示DEX（Dalvik Executable）文件的内存映射，包含应用经过编译的字节码。在应用加载多个DEX文件或扩展包时，DEX mmap的内存占用会增加。如果这些字节码未能有效管理，可能导致内存占用增加，影响应用的性能和稳定性。

• OAT mmap
  OAT mmap表示OAT（Optimized Android Runtime）文件的内存映射，包含优化后的应用程序代码。在应用运行时，加载优化的OAT文件会占用一定的内存。如果OAT文件过大或加载过程不够高效，可能导致内存占用增加，并影响应用的运行速度。

• ART mmap
  ART mmap表示ART（Android Runtime）虚拟机的内存映射，主要涉及ART虚拟机运行时的内存使用。在ART虚拟机处理Java字节码和优化操作时，ART mmap的内存占用会增加。如果ART内存管理不当，可能导致内存占用增加，影响应用的执行效率。

• Other mmap
  Other mmap表示其他类型的内存映射，未被归类到特定类型的内存使用。在应用加载非标准资源或使用特殊内存映射时，Other mmap的内存占用会增长。如果这些内存区域未能及时释放，可能导致内存占用增加，影响系统的整体性能。

其他内存使用情况

• Dalvik Other
  Dalvik Other表示Dalvik虚拟机的其他内存使用，涵盖了非堆内存的部分。通常在Dalvik虚拟机执行非堆内存操作时，这一参数的内存占用会增长。如果虚拟机内存管理不当，可能导致内存浪费，并影响应用的响应速度。

• Other Dev
  Other Dev表示与设备相关的其他内存使用，通常用于管理与设备特性相关的数据存储。在应用使用特殊硬件功能或与设备进行频繁交互时，Other Dev的内存占用可能增长。如果未能高效管理这些资源，可能导致设备性能下降或内存占用增加。

• Stack
  Stack表示堆栈内存的使用情况，主要用于存储线程的堆栈信息。在创建新线程或执行复杂操作时，Stack的内存占用会增长。如果线程管理不当或堆栈内存使用过多，可能导致应用的响应速度下降，甚至引发崩溃。

• Ashmem
  Ashmem（Anonymous Shared Memory）表示匿名共享内存的使用情况，主要用于跨进程共享内存数据。在应用需要在多个进程间共享数据时，Ashmem的内存占用会增加。如果共享内存未能及时释放或管理不当，可能导致内存浪费，并影响系统的稳定性。

通过分析这些细节数据，大家可以更准确地定位内存问题的根源，并采取相应的优化措施，如优化资源加载策略、及时释放不必要的对象等。

2. 实例分析

为帮助大家更好地通过Gears定位内存问题，我们来结合一个具体的游戏实例进行分析，并深入解读相关的性能参数。

背景信息
测试人员在游戏测试的过程中发现，游戏在特定的关卡游玩了10分钟后，出现了闪退现象，初步怀疑可能是因为内存问题导致。

首先，获取性能数据：
我们使用Realtime模式对该游戏进行一定时间的性能测试，获取部分性能数据，便于后续分析。

优化前的性能测试数据趋势图

优化前开始时的测试数据展示图

优化前结束时的测试数据展示图

接着，分析性能数据：
我们可以从上图中观察到，优化前的性能测试数据趋势线成阶梯形增长，而从具体数据来看：

• PSS Total内存占用在应用运行过程中显著增加，最终达到1.27GB。这表明应用存在严重的内存累积问题，可能是由于内存泄漏或资源未及时释放导致的。

• Unknown内存增长尤为显著，从135.32MB增长至577.89MB。Unknown内存通常代表未能被归类的内存分配，其大幅增长通常意味着应用中存在未被正确管理的资源或隐性的内存分配问题。这是内存管理的关键问题，可能导致系统内存紧张，从而影响应用的性能和稳定性。

• GL mtrack内存从163.55MB显著增长至630.84MB，这表明在应用的图形资源管理方面存在严重问题。内存的快速增长可能是由于图形资源未能及时释放或频繁加载大规模图形资源所致。这种内存的急剧增加可能会导致GPU内存压力增大，从而影响渲染性能，最终可能导致帧率下降、画面卡顿，甚至应用崩溃。

结合以上的数据，我们可以发现主要问题集中在PSS Total和Unknown内存的显著增长，以及GL mtrack内存的急剧上升。这些问题表明应用存在严重的内存管理不足，尤其是在图形资源管理方面，可能导致内存泄漏、资源未能及时释放，以及GPU内存过度消耗。这些问题如果不及时优化，可能会导致系统内存不足、应用性能下降，甚至导致应用崩溃。

然后，优化性能问题：
在分析了存在内存问题的性能数据后，我们发现Unknown内存的大幅增长是主要的内存问题之一。Unknown内存并不是某种特殊的内存，而是指无法明确分类的内存部分。大部分的性能分析工具都无法直接识别和定位Unknown内存的具体来源，那么我们该如何去定位并解决Unknown内存问题呢？

主要可以从以下几点来优化：

• 分析内存增长的时间点
  通过观察内存曲线，识别出内存问题开始的时间点，并回溯到该时段前后执行的代码段，初步判断可能导致内存问题的操作。

• 关联代码与测试场景
  对照测试场景的步骤，列出在内存增长明显的时间点所执行的操作，并将其与相关代码段对应，初步锁定可疑代码区域。

• 逐步禁用功能模块
  禁用初步锁定的可疑模块或功能特性，并重新运行测试，观察内存问题是否改善。通过这一过程，进一步缩小问题范围。

• 细化代码调试
  在可疑代码段内逐行或逐函数分析内存分配操作，特别是涉及到动态内存分配、对象创建等部分，加入日志记录，跟踪内存操作的细节。

• 内存快照对比
  在内存增长的关键时刻使用内存快照工具捕获内存状态，对比不同时间点的快照，识别出内存增长的具体对象或数据结构，以进一步锁定问题代码。

• 使用二分法进一步定位
  通过二分法调试将可疑代码区域逐步划分为更小的部分，逐步排查，直到找出具体导致内存问题的代码段，并进行针对性修复。

• 重复测试验证
  每次定位并修改代码后，重新运行测试场景，验证内存问题是否解决，逐步收窄问题范围，直到彻底消除内存问题。

最后，验证优化结果：

在对游戏进行优化后，我们需要重新进行性能测试来验证优化的结果。

优化后的性能测试数据图

通过查看优化后的数据趋势，我们可以发现优化措施显著改善了应用的内存管理，PSS Total和Unknown内存的稳定性验证了内存累积和泄漏问题得到了解决。同时，系统可用内存的增加进一步确保了应用在长时间运行后的性能和稳定性。

希望这篇文章能够帮助大家使用Gears-Realtime模式快速定位内存问题，在优化内存的道路上披荆斩棘。

---

如果您在使用过程中遇到任何问题，可以通过私信找到我们，或者前往问答社区进行提问，我们将竭诚为您提供支持。

问答社区链接：UWA问答 | 游戏开发者互动问答社区 | 侑虎科技