3. 匿名内部类隐式持有外部引用：Activity/Fragment泄漏根因

3.1 现象识别

当在 Activity 或 Fragment 中直接使用匿名内部类（或非静态内部类）作为 Retrofit Callback 时，即使界面已销毁，该 Activity/Fragment 实例仍无法被 GC 回收，导致内存泄漏。典型表现包括：

3.2 数据采集

采集泄漏证据时，推荐使用 LeakCanary 自动捕获，或手动导出 Heap Dump 后用 MAT 分析。核心步骤：

1. 启动 App，反复进入目标页面并返回，执行 3～5 次。
2. 观察 LeakCanary 是否弹出泄漏通知。若无 LeakCanary，则在最后一次退出页面后约 5s 点击 Profiler → Dump Java Heap。
3. 导出 .hprof 文件，用 Memory Analyzer (MAT) 打开。
4. 使用 “List objects → with incoming references” 查询 Activity 实例，查看 GC Root 路径。

# 使用 Android Studio Profiler 搜索
# 在 Dump 后的类列表里搜索 Activity 或 Fragment 的类名，如果看到多个实例且都“invisible”或“not needed”，则泄漏风险极高。

3.3 原因定位

3.3.1 引用链分析

非静态匿名内部类会隐式持有外部类的 this 引用。当 Retrofit 网络请求还未完成时，该回调对象生命周期长于 Activity，导致整个 Activity 无法被回收。

// 典型泄漏代码（错误示范）
public class MainActivity extends AppCompatActivity {
    private TextView mResultView;

    private void fetchData() {
        ApiService api = RetrofitClient.getInstance();
        Call call = api.getData();
        call.enqueue(new Callback<Data>() {      // 匿名内部类持有外部 Activity 引用
            @Override
            public void onResponse(Call<Data> call, Response<Data> response) {
                mResultView.setText(response.body().toString()); // 通过隐式引用操作 UI
            }
            @Override
            public void onFailure(Call<Data> call, Throwable t) { /* ... */ }
        });
    }
}

泄漏引用链：

• GC Root → 网络线程池 → 正在执行的 Call → Retrofit Callback 匿名内部类 → 外部 Activity

3.3.2 故障树定位

3.4 修复动作

3.4.1 方案一：使用静态内部类 + 弱引用

public class MainActivity extends AppCompatActivity {
    private static class MyCallback implements Callback<Data> {
        private WeakReference<MainActivity> activityRef;

        MyCallback(MainActivity activity) {
            activityRef = new WeakReference<>(activity);
        }

        @Override
        public void onResponse(Call<Data> call, Response<Data> response) {
            MainActivity activity = activityRef.get();
            if (activity != null && !activity.isFinishing()) {
                activity.mResultView.setText(response.body().toString());
            }
        }

        @Override
        public void onFailure(Call<Data> call, Throwable t) { /* 同样处理 */ }
    }

    private TextView mResultView;

    private void fetchData() {
        ApiService api = RetrofitClient.getInstance();
        Call<Data> call = api.getData();
        call.enqueue(new MyCallback(this)); // 传入弱引用
    }
}

3.4.2 方案二：使用 Lambda（接口为函数式接口时适用）

如果 Retrofit Callback 定义是函数式接口（如 Callback<T> 在 Kotlin 中），可直接使用 Lambda，但注意 Lambda 在 Java 中仍可能捕获外部引用，建议配合 WeakReference 组合。

3.4.3 方案三：销毁时取消 Call

// 在 Activity 中维护 Call 引用
private Call<Data> mCall;

private void fetchData() {
    mCall = api.getData();
    mCall.enqueue(new Callback<Data>() { ... });
}

@Override
protected void onDestroy() {
    super.onDestroy();
    if (mCall != null && !mCall.isCanceled()) {
        mCall.cancel(); // 取消请求，回调不再触发
    }
}

3.5 复测

修复后必须验证泄漏已被消除：

• LeakCanary 验证：重复进入退出页面 5 次，确认无泄漏通知。
• Profiler 内存观察：执行 GC 后，Activity 实例数归零，内存曲线平缓。
• 自动化回归：集成 ActivityScenarioRule 在 Instrumentation 测试中检测泄漏（例如使用 LeakAssert）。

D/LeakCanary: No leak detected.
D/ActivityManager: Process com.example.app (pid 12345) has no remaining instances of MainActivity after GC.

3.6 预防