4、内存泄漏检测与优化归纳总结
内存泄漏，说白了就是该回收的对象没回收。在审计SDK里，这问题尤其要命——SDK常驻后台，泄漏一点，日积月累就把宿主App的内存挤爆了。我个人习惯把泄漏检测分成三步走：发现问题、定位根因、彻底修复。
4.1 泄漏的常见模式
先说说我在项目中遇到过哪些泄漏类型。你把它想成一个漏水的桶，漏点不同，修法也不一样。
| 泄漏类型 | 典型表现 | 根因 |
|---|---|---|
| 集合泄漏 | ArrayList、HashMap持续增长 | 对象放入集合后忘记移除 |
| 非静态内部类泄漏 | Handler、Thread持有Activity | 内部类隐式持有外部类引用 |
| 注册未解绑泄漏 | BroadcastReceiver、EventBus | register/unregister不成对 |
| 单例泄漏 | 静态变量引用Activity/Context | 单例生命周期变长 |
| 匿名回调泄漏 | Listener、Callback被长期持有 | 匿名内部类容易忘记清理 |
嗯，这里要特别注意集合泄漏。我记得有回查线上ANR，发现某个Map竟然存了上千个Fragment实例。原因就是页面关闭后，Map没做remove操作。
4.2 检测工具与手段
工具不用多，顺手最关键。我个人的工具箱就这几样：
- LeakCanary：自动化内存泄漏检测，发现泄漏自动dump hprof。开发期必开，集成测试也建议开启。
- Android Studio Profiler：手动分析用。我习惯先看Memory图表的锯齿曲线，曲线不回弹就有问题。
- MAT（Memory Analyzer Tool）：分析大堆快照。查GC Roots和引用链，找不可达对象最准。
- hprof-conv + jhat：命令行分析，适合自动化脚本集成。
小技巧：我会在SDK的关键生命周期里加手动GC触发点。比如 Activity.onDestroy() 后主动 System.gc()，然后看对象是否被回收。这个做法我在多个项目中验证过，简单直接。
4.3 定位泄漏的实战流程
真遇到泄漏了，怎么一步步找到根因？我给你画个流程图：
流程挺直白，但有个坑——千万别拿到第一个LeakCanary报告就直接改代码。我见过太多人看到个匿名内部类就加static，结果把业务逻辑写坏了。先确认引用链，再看是不是回调没清干净。
4.4 代码层面的优化策略
你想想看，内存泄漏归根结底是引用关系管理出了问题。那怎么优化？我总结了几条硬规矩：
- 弱引用/软引用替代强引用：像Handler、Runnable这类，可以用 WeakReference 包装外部对象。
- 生命周期成对管理：注册和反注册、open和close，必须成对出现。我习惯在Base类里统一做。
- 静态集合慎用：static List、static Map里只放生命周期长的对象，临时对象用完就remove。
- 匿名内部类转静态内部类：匿名类自动持有外部引用，改成静态内部类加WeakReference。
- Context用Application代替Activity：单例里存Context时，能用Application就别用Activity。
核心原则：谁创建谁销毁。你new出来的对象，一定得知道在哪个时机释放它。SDK代码尤其要遵守——宿主App不会帮你擦屁股。
4.5 案例复盘：一个定时器引发的泄漏
我讲个真实案例。有一次，我们SDK做日志上传功能，用了一个TimerTask来定时触发。测试跑了一整夜，第二天看内存涨了20MB。一看代码：
// 有问题的写法
public class LogUploadManager {
private Timer timer = new Timer();
public void startUpload() {
timer.schedule(new TimerTask() {
@Override
public void run() {
uploadLogs();
}
}, 0, 60000);
}
// 没有stopTimer()方法
}发现问题没？TimerTask是匿名内部类，持有LogUploadManager的引用。而LogUploadManager又被单例持有。 整个引用链就变成了：静态单例 → LogUploadManager → Timer → TimerTask。Activity都销毁了，timer还在跑，日志上传还在做，内存一直泄漏。
修复方式很简单，在destroy方法里调timer.cancel()，并把Manager里的集合清掉。我后来还加了个WeakHashMap来存所有注册的回调，避免类似问题。
⚠️ 避坑指南：我曾经在修复泄漏时犯过一个低级错误——把TimerTask改成静态内部类，但忘了把外部方法改成static或者通过弱引用调用。结果编译不过，修复了一上午。改代码时一定要同时调整引用关系，不要只改一半。
4.6 归纳总结
好了，做个总结。内存泄漏这东西，不复杂但容易疏忽。只要记住三点：
- 检测自动化：LeakCanary加Profiler，日常开发就跑起来。
- 根因追到底：找到最短GC Root引用链，别只看表象。
- 修复成体系：不光改一个点，要检查所有同类模式。
其实说白了，内存优化就是做好两件事：管理好对象的生命周期和控制好引用强度。你把这两件事做扎实了，80%的内存泄漏问题自然就绕开了。