3. 引用链分析：理解注册后 Receiver 与 Context、Activity/Service 的强引用关系

动态注册 BroadcastReceiver 导致的内存泄漏，本质是一条从 GC Roots 到 Activity/Service 实例的 强引用链 未被断开。本章从排查视角拆解这条链的构成，帮助你在堆转储中快速定位泄漏源头。

3.1 现象识别：内存泄漏的早期信号

当 Activity/Service 因 Receiver 注册发生泄漏时，通常表现出以下可观测特征：

3.2 数据采集：捕获引用链证据

使用以下工具链采集泄漏证据，每一层输出都是下一层的输入：

步骤 3 的具体命令和典型输出示例：

# 查看当前进程所有已注册的动态广播接收器
adb shell dumpsys activity broadcasts | grep -A 5 "Registered Receivers"

# 典型输出（泄漏场景）：
Registered Receivers:
  ReceiverList{...  type:dynamic  pid:12345  uid:10001}
    Filter{...}
    Receiver: com.example.MyActivity$1@0x12a34b56
    Context: com.example.MyActivity@0x56b78c90

3.3 原因定位：引用链深度解析

动态注册泄漏的引用链由 4 个关键节点 串联而成。以下 SVG 对比了泄漏场景与修复场景的引用路径：

从 SVG 可以看出，泄漏的充分必要条件：

1. GC Roots 可达：系统服务（AMS）通过注册表持有 Receiver 对象；
2. 隐式外部引用：Receiver 是匿名 / 非静态内部类，自动持有外部 Activity 的 this 引用；
3. 未执行断链操作：onDestroy() 中未调用 unregisterReceiver()。

3.4 修复动作：断链操作

修复的核心是 确保 Receiver 的生命周期与宿主对称。以下对比展示泄漏代码与修复代码：

标准修复代码示例：

public class MainActivity extends AppCompatActivity {

    private BroadcastReceiver mReceiver;  // 成员变量，避免匿名内部类隐式持有

    @Override
    protected void onStart() {
        super.onStart();
        mReceiver = new BroadcastReceiver() {
            @Override
            public void onReceive(Context context, Intent intent) {
                // 处理广播
            }
        };
        registerReceiver(mReceiver, new IntentFilter("com.example.MY_ACTION"));
    }

    @Override
    protected void onStop() {
        super.onStop();
        if (mReceiver != null) {
            unregisterReceiver(mReceiver);   // 断链操作
            mReceiver = null;                // 辅助 GC
        }
    }
}

3.5 复测：验证修复效果

修复后，按以下步骤执行验证：

3.6 预防：长效机制

将以下检查项纳入团队的代码审查和静态分析流程：