匿名内部类是安卓内存泄露高频源头，因其隐式持有外部Activity/Fragment强引用；当其生命周期超宿主（如后台线程、延迟Handler、未注销回调），导致Context泄露。
匿名内部类是安卓开发中内存泄露的高频源头，核心问题在于它会隐式持有外部 Activity 或 Fragment 的强引用。一旦该内部类对象生命周期超出宿主组件（比如启动了后台线程、设置了延迟 Handler 任务、注册了未注销的回调），宿主就无法被 GC 回收，造成 Context 泄露。
识别典型泄露模式
以下代码看似正常，实则埋下隐患：
- 在 Activity 中定义非静态 Handler、Runnable、Thread 或 AsyncTask 子类
- 使用
new Thread(() -> { ... }).start()启动线程，且线程内访问了 Activity 成员变量或调用了 UI 方法 - 给 View 设置点击监听时，用 lambda 表达式直接引用
this或成员方法（如view.setOnClickListener { updateUI() }），而该 lambda 在 Activity 销毁后仍可能被回调
实战排查三步法
第一步：复现 + LeakCanary 快速捕获
集成 LeakCanary（debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.12'），运行 App，执行目标操作（如跳转到某页 → 点击触发异步任务 → 返回上一页）。几秒后若出现通知，点开即见泄漏路径 —— 通常显示类似 LeakedInstance: MainActivity instance，引用链中会出现 MyActivity$1（匿名类编号）→ threadLocal 或 handler → target 持有 Activity。
第二步：Android Studio Profiler 验证
打开 Memory Profiler，反复执行「进入 Activity → 触发匿名类逻辑 → 返回」，多次点击 Force GC。观察堆内存曲线是否回落；若不回落，点击 Dump Java Heap，导出 .hprof 文件，在分析器中筛选该 Activity 类名 —— 若实例数 >1 或存在“Retained Size”异常偏高，基本确认泄露。
第三步：手动检查引用链
在 LeakCanary 报告或 MAT 分析中，重点看「Shallow Heap」低但「Retained Heap」高的对象。顺着引用链向上查，找到那个匿名内部类实例，再确认它是否通过 this$0 字段持有了外部 Activity —— 这是 Java 编译器为非静态内部类自动生成的隐式字段，无法绕过。
修复方案与安全写法
原则是：切断匿名类对 Activity 的强引用，同时确保业务逻辑可继续执行。
- 将匿名类改为 静态内部类，并在内部用 WeakReference<Activity> 持有宿主引用；使用前判空，避免 NPE
- 对于 Handler，务必在 Activity
onDestroy()中调用mHandler.removeCallbacksAndMessages(null) - 对 Runnable/Thread，可在销毁时设置标志位（如
isDestroyed = true），在线程体中定期检查并提前退出 - 避免在 lambda 中直接调用 Activity 方法；改用弱引用包装，或把逻辑抽离到 ViewModel / Repository 等生命周期无关组件中
预防性编码习惯
不依赖“我这次不会泄露”，而要建立防御性结构：
- 所有涉及后台执行、延迟操作、回调注册的场景，第一反应是：这个对象会不会活过 Activity？它有没有持我的引用？
- 新建内部类前，先敲
static；需要访问外部状态时，明确传入 WeakReference - 在 BaseActivity 或 BaseFragment 中统一提供
safeRun { ... }封装方法，自动处理弱引用和生命周期校验 - CI 流程中接入 StrictMode，开启
detectActivityLeaks()和detectLeakedClosableObjects()，让问题在测试阶段暴露
