Android中ConnectivityManager Callback内存泄漏排查与修复求助

问题背景 #

项目中未直接使用android.net.ConnectivityManager，但LeakCanary检测到该类导致MainActivity内存泄漏，推测由第三方库引入导致。

泄漏日志详情 #

┬───
│ GC Root: System class
│
├─ android.net.ConnectivityManager class
│    Leaking: NO (a class is never leaking)
│    ↓ static ConnectivityManager.sCallbackHandler
│                                 ~~~~~~~~~~~~~~~~
├─ android.net.ConnectivityManager$CallbackHandler instance
│    Leaking: UNKNOWN
│    Retaining 32 B in 1 objects
│    ↓ ConnectivityManager$CallbackHandler.this$0
│                                          ~~~~~~
├─ android.net.ConnectivityManager instance
│    Leaking: UNKNOWN
│    Retaining 516.0 kB in 8048 objects
│    mContext instance of com.company.appname.MainActivity with mDestroyed =
│    true
│    ↓ ConnectivityManager.mContext
│                          ~~~~~~~~
╰→ com.company.appname.MainActivity instance
​     Leaking: YES (ObjectWatcher was watching this because com.company.
​     appname.MainActivity received Activity#onDestroy() callback and
​     Activity#mDestroyed is true)
​     Retaining 515.9 kB in 8043 objects
​     key = fb405ad1-a78b-4e8f-8d09-c1b937e1462c
​     watchDurationMillis = 8341
​     retainedDurationMillis = 3230
​     mApplication instance of android.app.Application
​     mBase instance of androidx.appcompat.view.ContextThemeWrapper

修复步骤 #

• 定位第三方库根源：用Android Studio的Analyze > Analyze Dependencies功能，查找间接引入ConnectivityManager调用的依赖库；重点排查网络监听、埋点、广告类SDK，这类库常涉及网络状态监听逻辑。
• 替换或升级问题库：找到嫌疑库后，优先查看官方文档或Issues，确认是否有已知泄漏修复版本，有则升级；无修复版本则替换为功能类似的替代库。
• 临时规避方案（无法替换库时）：
  • 强制传入Application Context：若能找到第三方库获取Context的入口，传入全局Application Context替代Activity Context，避免Activity被强引用。
  • 主动注销监听：若第三方库提供注销网络监听的API，在Activity的onDestroy()方法中调用该注销逻辑。
  • 用WeakReference包装Context：自定义Context包装类，用WeakReference持有Activity Context，降低泄漏风险（需确保第三方库不会强制强引用该包装类）。
• 验证修复效果：修复后重新运行LeakCanary，观察是否仍有泄漏告警；同时用Android Studio的Profiler > Memory Profiler生成内存快照，确认MainActivity销毁后可正常回收。

内容的提问来源于stack exchange，提问作者Lance Samaria