将Android Activity传入依赖是否会引发内存泄漏？相关疑问

1. 直接传Activity会不会引发内存泄漏？ #

得看DownloadQRHandler的内部实现：

• 如果它持有Activity的强引用，并且自身生命周期比Activity长（比如内部有未执行的延迟任务、异步回调，或者被单例这类长生命周期对象持有），那Activity销毁后会因为这个强引用无法被GC回收，必然导致内存泄漏。
• 你觉得“Activity销毁后downLoadQRHandler会自动置空”的逻辑不成立：downLoadQRHandler是Activity的成员变量，只要Activity实例还被其他地方引用，这个变量就不会自动置空；反过来，如果Activity没被外部引用，那即使downLoadQRHandler持有Activity，两者都会被GC回收，但如果DownloadQRHandler被其他长生命周期对象持有，Activity就会被连带泄漏。

2. 在onDestroy()中置空downLoadQRHandler的好处 #

• 切断Activity对DownloadQRHandler的强引用：如果DownloadQRHandler没有被外部对象持有，置空后Activity和它的引用链就断了，两者都能被GC正常回收。
• 配合任务终止更有效：单纯置空只是切断引用，如果DownloadQRHandler内部有异步任务、Handler消息在跑，最好先让它停止这些任务（比如调用handler.removeCallbacksAndMessages(null)、取消网络请求等），否则内部任务如果还持有Activity引用，泄漏依然存在。
• 避免潜在内存占用：主动清理成员变量引用，能减少GC延迟带来的内存占用，尤其在低内存设备上更有意义。

3. 排查Activity被标记泄漏的其他原因 #

如果已经处理了downLoadQRHandler的引用，还是被Memory Profiler和LeakCanary标记，从这些方向查：

• DownloadQRHandler内部的隐式引用：比如它内部的Handler用了Activity的Looper，还有未处理的延迟消息；或者启动的异步任务（协程、线程、网络回调）持有Activity强引用，且任务还在运行。
• 未清理的组件：
  • 注册的广播接收器、ContentObserver没在onDestroy注销；
  • 绑定的Service没解绑；
  • 静态变量持有Activity引用；
  • 第三方SDK的回调（图片加载、支付等）没释放Activity引用；
• View相关泄漏：Dialog、PopupWindow没在Activity销毁时关闭，导致持有Window引用；或者RecyclerView、ViewPager的Adapter持有Activity引用；
• 协程生命周期不匹配：用了GlobalScope或者错误的CoroutineScope，协程还在运行时持有Activity上下文引用。

内容的提问来源于stack exchange，提问作者Vikas Pandey