泄漏现象识别：内存增长、GC频繁、OOM预警、界面卡顿表现

当 Activity 实例被 ViewModel 通过匿名内部类、回调或非静态内部类等方式持有时，GC Root 到达 Activity 对象的引用链无法被切断，Activity 及其关联的大量视图资源（Bitmap、Drawable、View树）无法被回收，从而引发一系列连锁性能劣化现象。本章归纳了四种典型的外在表现，帮助工程师在第一时间嗅探到泄漏的存在。

四种核心表象与判断规则

现象关联：从内存泄漏到用户可感知的性能裂化

泄漏的 Activity 并非立刻导致崩溃，而是先通过 内存增长 让 Heap 失去稳态。当 Heap 逼近阈值，系统启动更激进的 GC 策略，触发 GC 频繁；GC 本身会暂停 ART 线程（STW），直接导致 界面卡顿；若 Heap 耗尽且无法再分配，则触发 OOM 预警 直至进程被杀。

各现象的详细识别方法

1. 内存增长（Heap 阶梯式上涨）

• 观测工具： Android Studio Memory Profiler / adb shell dumpsys meminfo
• 脚本化采集：

  # 连续采集 5 次，每次间隔 2 秒，观察 Total PSS 趋势
  for i in 1 2 3 4 5; do
    adb shell dumpsys meminfo com.example.app | grep "Total PSS"
    sleep 2
  done

• 判断规则： 执行 N 次 Activity 跳转（推荐 5 次），每次返回后 Heap 残留量 > 2MB 且不回落到首次基线，即可判定为泄漏性增长。

2. GC 频繁（Alloc/Concurrent GC 爆发）

• 观测工具： Logcat 过滤 I/art 或 I/GcReason
• 典型日志：

  I/art: Background partial concurrent mark sweep GC freed 5231(512KB) AllocSpace objects, 12(240KB) LOS objects, 25% free, 8MB/12MB, paused 3.346ms total 68.945ms
  I/art: WaitForGcToComplete blocked for 8.415ms for cause Alloc

• 判断规则： 一次用户操作（如旋转屏幕）触发超过 3 条连续的 GC 日志，且每两条间隔 < 1 秒，定义 GC 频繁。

3. OOM 预警（常伴随 Crash 堆栈）

• 观测工具： Firebase Crashlytics / Bugly / Logcat
• 关键堆栈特征：

  java.lang.OutOfMemoryError: Failed to allocate a 12500012 byte allocation with 4194304 free bytes and 4MB until OOM, target footprint 24009184, growth limit 268435456
    at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
    at ...

• 判断规则： 若 OOM 堆栈中频繁出现 Activity.onCreate / View.onDraw 等与页面相关的帧，且 Heap 在崩溃前呈阶梯上升趋势，则 OOM 由泄漏引发。

4. 界面卡顿（帧率骤降）

• 观测工具： Profile GPU Rendering / SysTrace / dumpsys gfxinfo
• dumpsys 采样：

  # 采样 120 帧后输出帧时间
  adb shell dumpsys gfxinfo com.example.app framestats

• 判断规则： 页面转场或旋转动画期间，连续帧绘制时间 > 16ms 且掉帧率 > 30%，同时伴随上述 GC 日志，可确认为 GC 卡顿。