内存泄漏诊断：用Profiler工具精准追踪对象创建
把Memory Profiler的分配记录功能打开，对象的创建时间、位置和调用栈就会一目了然——你不需要加日志，也不需要靠猜测来定位问题。这才是真正高效的排查手段。
开启分配记录前的关键准备
首先得确保应用在调试模式下运行——debuggable="true"是必须的，设备USB调试也要打开，这是基础操作。Android Studio 4.2及以上版本支持Ja va/Kotlin对象的实时分配捕获；如果涉及Native对象，需要额外配置NDK符号表，不过日常开发中还是优先聚焦Ja va层更实际。
- 去
AndroidManifest.xml里看一眼，application标签下有没有android:debuggable="true" - 录制期间尽量避免触发大量无关操作，比如切后台、弹系统通知，这些都会干扰数据聚焦
- 如果目标是分析某次点击或滑动行为，建议先冷启动应用，再开始录制，保证堆状态足够干净
定位对象创建的具体步骤
进入Memory Profiler后，点击右上角的Record memory allocations按钮（图标是两个重叠的方块），然后执行你想分析的操作——比如打开一个页面、快速滑动列表。10到20秒后停止，Profiler会生成一份按时间排序的对象分配列表。
- 默认按“Allocated Objects”降序排列，优先看数量多或单个尺寸大的类，比如
Bitmap、ArrayList、自定义ViewHolder - 双击任意对象行，展开调用栈（Call Stack），最底部是构造函数所在行，往上逐层就能看到是哪个方法、哪行代码触发了创建
- 右键可以选择“Filter by package”，快速排除系统或第三方库（如androidx.*、okhttp3.*），聚焦自己模块的代码路径
识别高风险创建模式
并不是所有频繁创建都算问题，但以下三种模式值得特别留意：
- 同一类对象在短时间反复new出来，且生命周期远短于Activity：比如每次RecyclerView滚动都new一个Bitmap或Parser实例
- 对象大小异常（超过100KB）且未复用：例如JSON解析结果直接转成大Map存在内存里，而不是流式处理
- 调用栈中间出现匿名内部类、Lambda表达式或Handler.postDelayed：这些容易隐式持有外部Activity引用，埋下泄漏隐患
结合堆转储交叉验证
如果分配记录发现某个类创建频繁，但不确定它是否滞留内存，可以立即做一次Heap Dump。点击Capture heap dump，等待几秒生成快照后，在左侧Class List中搜索该类名，查看“Instances”数量是否持续增长，是否有非预期的强引用链——比如被静态Map持有。
- 点开实例，查看References，切换到Dominator Tree视图，能看清谁在“挡路”阻止GC
- 重点观察Reference Type是否为Static field、Thread local或Finalizer reference，这些是泄漏的典型信号
