非静态内部类导致内存泄漏的根源是隐式持有外部类引用，预防需控制其生命周期、用静态/顶层类替代、显式传参、避免存入长生命周期容器、及时解绑清理、关键场景用weakreference兜底，并借助profiler/leakcanary/mat验证。
非静态内部类本身不是问题，问题出在它隐式持有的外部类引用被意外延长了生命周期。预防的关键不是“禁用”非静态内部类，而是控制它的存活时间、切断不必要的强引用链，并在必要时主动清理。
明确内部类的使用边界
只在真正需要访问外部类非静态成员时才用非静态内部类。如果只是封装逻辑、不依赖外部实例状态，优先改用静态内部类或顶层独立类。
- 比如一个仅做数据解析的工具类，不要写成 非静态 内部类；它不需要 Activity 或 Fragment 的上下文
- 若内部类需调用外部类方法但又可能长期存活（如后台任务），应显式传入所需参数，而非依赖 this 引用
- 避免把非静态内部类实例存入静态集合、单例、全局缓存等长生命周期容器中
及时解绑与手动清理
当外部类（如 Activity、Fragment）进入销毁流程时，必须确保所有非静态内部类对象不再持有其有效引用。
- 在 onDestroy() 或 onCleared() 中，将内部类持有的 Handler、Runnable、Thread 等设为 null
- 调用 removeCallbacksAndMessages(null) 清空 Handler 消息队列
- 对正在运行的线程，调用 interrupt() 并检查中断状态，避免死循环持引用
用弱引用兜底关键场景
对于无法完全避免非静态内部类且存在异步回调的场景（如网络请求回调、定时任务），可结合 WeakReference 主动规避强引用滞留。
- 在内部类构造时接收 WeakReference
，每次使用前判空再调用 - 注意：WeakReference 不能用于需要保证对象一定存活的逻辑（如 UI 更新前未判空会 crash）
- 适合场景：后台计算完成后再安全更新 UI，或日志上报等非关键路径
借助工具验证是否生效
光靠代码逻辑不够，上线前必须通过工具确认无泄漏残留。
- Android Studio Profiler 中观察 Activity 实例数量，反复进出后是否持续增长
- 使用 LeakCanary 自动捕获 Activity/Fragment 泄漏快照，定位具体哪行代码持有了引用
- 用 MAT（Memory Analyzer Tool）分析 hprof 文件，查看 GC Roots 到 Activity 的引用链，确认是否还有非静态内部类在链路上
