内存用量(匿名 RSS + 交换空间)

内存用量(匿名 RSS + 交换空间)是 Android Vitals 中的一项指标,用于反映应用的内存用量。

匿名内存是指没有存储器中的文件支持的内存,例如堆分配和 mmap 分配的内存。这会捕获应用的动态内存分配,包括 Java 或 Kotlin 堆、非托管原生堆分配(在 Android 8.0 [API 级别 26] 及更高版本中,位图像素数据位于此处)和线程执行堆栈。虽然操作系统可以在内存压力过大时丢弃有文件支持的内存,但无法丢弃匿名内存。

常驻内存大小 (RSS) 是进程使用的(共享和非共享)内存页面的总数,这些页面保存在物理 RAM 中。如果某个内存页被多个进程(例如访问同一库的应用)访问,则该内存页被视为“共享”。

对于匿名内存,当内存面临压力时,系统可以将页面写入交换空间(或 Android 上的 zRAM)。如果需要,系统可以从交换区读回这些页面。

总而言之,内存用量(匿名 RSS + 交换空间)衡量的是您的应用在存储空间中没有文件支持的内存页总数,包括系统在交换空间中保留的任何内存。跟踪匿名 RSS + 交换可确保您看到应用的真实、不可逐出的内存占用。

如果应用的内存用量较高,请使用本页中的指南进一步调查并解决问题。

识别高内存用量

Android Vitals

Android Vitals 会按以下进程状态细分应用的内存用量:

  • 前台:应用进程可见。较高的 P99 通常会影响用户感知到的性能(卡顿或 OOM 崩溃),并且很大程度上是由保留不再需要的界面组件或 activity 造成的。
  • 用户可感知服务:应用进程正在可感知状态下运行。这包括前台服务、加急作业和由用户发起的数据传输作业。它还可以扩展到系统绑定的服务或其他应用绑定的服务。由于这些服务是为长时间运行的任务而设计的,因此因泄漏而保留内存或未能释放资源可能会随着时间的推移而增加 P99 尾部。
  • 后台:应用正在运行后台服务,或最近已转入后台,但尚未缓存。在这种情况下,后台处理泄漏和未释放的资源可能会加剧。由于此进程状态不如前台进程或可感知进程重要,因此请尽量避免在此状态下保留大量内存。
  • 已缓存:应用处于已缓存状态。此状态对系统内存压力(例如 LMK)高度敏感。由于操作系统可以随意逐出此进程状态,因此仅出于调试目的提供此状态。

如需了解这些进程状态与 onTrimMemory 回调之间的关联,请参阅有关响应事件释放内存的指南。

Android Vitals 还会按 RAM 桶细分应用的内存用量。内存用量指标以每日百分位数值的时间轴形式显示,同时还显示第 50 和第 90 个百分位的最新每日值。

确定内存基准后,请按照相关指南诊断改进过高的内存使用量。

使用尾部偏度识别内存泄漏

为帮助您找出内存泄漏,请在 Android Vitals 中查看典型用户(P50)和尾端用户(P90)之间的差异。虽然一般资源膨胀会使所有百分位的内存均匀增加,但内存泄漏会随着时间的推移而加剧,从而严重扭曲尾端数据。

您应按进程名称将 P90 和 P99 指标与 P50 基准进行比较。如果 P90 与 P50 的比率超过 3.5 倍,则表示长时间会话期间可能存在内存泄漏。在某些使用情形下,较高的比率并不一定表示存在内存泄漏,但您应评估具体的工作流程,以确定内存使用率升高是否属于预期行为。

资源

在本地诊断内存用量过高的问题

如需开始诊断内存用量过多的来源,您可以使用开发者设置中的记录堆转储Android StudioPerfetto 捕获堆转储。建议您先测试应用的核心用户体验历程,然后在本地捕获堆转储。

我们尤其建议您测试以下用户历程:

  • WebView 和应用内浏览器会话
  • 包含大量媒体内容的无限滚动
  • 素材资源创建和修改流程

如需调查潜在的内存泄漏问题,请先使用 Android Vitals 内存用量信息中心内的进程名称表来确定内存消耗最高的进程。接下来,在本地运行相应的用户历程,并在不同的进程状态(可见、前台服务和缓存)下收集堆转储,以验证应用在转到后台后是否会释放内存。

如果您使用 Android Studio 性能分析器调试内存问题,还可以使用 LeakCanary 集成来简化泄漏和重复位图检测,从而优化图片使用情况

收集堆转储后,建议使用 Perfetto AI 技能来分析堆转储,并找出可能导致内存用量过高的来源。

以下是 AI 技能可能会给出的回答示例:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

有关解读堆转储的其他资源

以下资源提供了有关解读堆转储和调试内存用量的更多信息:

提高内存用量

请参阅以下部分,详细了解如何改进应用的内存用量:

如需有关修复内存问题的详细指导,请参阅管理应用内存指南。