识别Memory Bloat的关键在于区分可回收、有边界、符合预期的缓存占用与不可逆、持续累积的内存泄漏：前者随业务操作周期性涨落，GC后显著回落；后者表现为单向爬升、基线逐轮抬高、对象无法归零且释放失效。
识别 Memory Bloat 的关键，在于判断内存增长是否“可回收、有边界、符合预期”。缓存过度占用是可控的、响应式的行为；内存泄漏则是不可逆的、持续累积的失控状态。二者在监控图表上可能都表现为内存上升，但背后机制和演化规律截然不同。
看增长模式：是否随使用节奏周期性回落
缓存类内存占用通常具有明显节奏感：用户打开某页面 → 加载资源并缓存 → 内存上升；切换页面或退后台 → 缓存主动清理或降级 → 内存回落。这种涨跌同步业务动作的曲线，属于有效占用。
而泄漏往往表现为单向爬升：即使长时间空闲、无新操作、反复触发GC，内存占用仍缓慢但稳定上涨，且不回落。尤其在重复进入/退出同一模块后，PSS 或 USS 每次都比前一次高，就是强泄漏信号。
- 建议在 DevEco Profiler 或 Android Studio 中录制 3–5 轮相同操作（如进详情页→返回→再进），观察 Memory 泳道中 USS 曲线的基线是否逐轮抬高
- 重点关注 ArkTS Allocation 或 Native Allocation 泳道中，对象实例数是否在操作结束后未归零（例如 ImageCache 实例始终多出 20 个）
看对象生命周期：是否与业务上下文解耦
缓存对象应绑定明确的生命周期管理策略，比如：
- 用 WeakReference / SoftReference 包裹图片缓存项，允许 GC 回收
- 监听 Activity/Stage 的 onDestroy 或 onDisappear，主动 clear() 缓存 Map
- 设置 LRU 最大容量，并在 put 时触发 trimToSize()
若发现大量 Bitmap、Handler、Callback、View 或 Context 实例长期驻留堆中，且其引用链最终指向一个早已不可达的 Activity（通过 MAT 或 DevEco 的堆快照分析），就说明存在逻辑缺陷——对象被静态集合、内部类隐式引用、广播未注销等意外持有，脱离了本该结束的生命周期。
看释放时机：是否响应主动触发的内存回收
在 Profiler 中点击“触发 GC”按钮（或调用 System.gc()），观察内存变化：
- 缓存类占用：GC 后 USS 显著下降（尤其配合 LRU 或弱引用时）
- 泄漏类占用：GC 后内存几乎不变，或仅微降；多次强制 GC 也无改善
- 特别注意 Graphic Memory 泳道：若纹理（Texture）、Surface 等资源在页面退出后仍持续占用显存，且无法被回收，大概率是 Native 层未调用 release() 或 destroy() 导致的泄漏
看分配源头：是否集中在非预期路径高频创建
启用 Allocation 泳道录制，按包名或类名筛选高频分配点：
- 合理缓存：分配集中在 initCache()、loadImage() 等明确缓存入口，且分配频次与用户操作频率匹配
- 可疑泄漏：在 onDraw()、onFrameAvailable()、TimerTask.run() 等循环路径中，反复 new 同一类对象（如 Path、Paint、ByteBuffer），却未复用或池化
- 典型线索：Allocation 列表中出现大量“
”调用，但对应类没有配套的 close()/destroy()/recycle() 调用记录
不复杂但容易忽略：真正的问题往往不在“有没有缓存”，而在“缓存有没有出口”。只要出口可控、边界清晰、可预测，再大的缓存也不叫 Bloat；一旦出口失效或根本不存在，再小的对象也会滚雪球成泄漏。
