大家知道Android系统对app的内存有一个上限，如果代码风格不好，业务庞大，时间紧没有代码评审来约束，是很容易引起OOM异常的，通常我们碰到这种问题，需要用profile工具去仔细的分析和排查，才能找到可能的原因。现在向大家介绍LeakCanary，是一款监测内存泄露的工具，由大名鼎鼎的Square公司开发并开源。
基本用法
参见LeakCanary官方的介绍，一步搞定！
官网介绍的方法非常简单，可以自动监测Activity泄露，原理很直接，就是用application的ActivityLifeCycleCallback，在onActivityDestroyed时去watch。那我们遵循这个套路，自己构建一个RefWatcher，就可以做到监听任何一个实例，只需要在该实例理论上应该销毁的时候watch一下就可以了。此处说销毁并不是真的要销毁，而是没有引用，也就是所谓的jvm内存管理的不可达状态。
原理
jvm内存管理
我们知道，java相对C++有一个巨大的好处就是可以不用做复杂且容易出错的内存管理，jvm有一个内存回收器会周期性的回收不用的内存，细节性的东西很多，也不影响我们理解LeakCanary的原理，我们暂且跳过。只需知道jvm会自动帮我们回收不需要的内存，但是还是有内存泄露的可能。
总体设计图
详细设计图
核心类介绍
LeakCanary
入口类。接口很简单，简单到只有一个install函数就可以运行，默认配置已经可以应对绝大部分场景，除非你想定制一些行为。
/**
* Creates a {@link RefWatcher} that works out of the box, and starts watching activity
* references (on ICS+).
*/
public static RefWatcher install(Application application) {
return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
.excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
.buildAndInstall();
}
/** Builder to create a customized {@link RefWatcher} with appropriate Android defaults. */
public static AndroidRefWatcherBuilder refWatcher(Context context) {
return new AndroidRefWatcherBuilder(context);
}
对设计模式有了解，或者看过一些开源框架的代码，可能知道这块使用了Builder模式，这个Builder其实很好理解，个人认为主要的使用场景，就是在构建一个实例时，有太多参数可以配置，如果都放到构造函数去做，那就显得太罗嗦，接口不简洁。使用setter，好像也不太好，我们希望实例构建后直接是可用状态。关于AndroidRefWatcherBuilder和RefWatcherBuilder后面会有介绍。install方法返回RefWatcher，接下来我们就看看这个RefWatcher。
RefWatcher
顾名思义，引用监控，它可以说是一个调度类，从判断泄漏，内存堆日志分析，结果展示，这些功能都在RefWatcher里面串起来
/**
* Watches references that should become weakly reachable. When the {@link RefWatcher} detects that
* a reference might not be weakly reachable when it should, it triggers the {@link HeapDumper}.
*
* <p>This class is thread-safe: you can call {@link #watch(Object)} from any thread.
*/
public final class RefWatcher {
private final WatchExecutor watchExecutor;
private final DebuggerControl debuggerControl;
private final GcTrigger gcTrigger;
private final HeapDumper heapDumper;
private final Set<String> retainedKeys;
private final ReferenceQueue<Object> queue;
private final HeapDump.Listener heapdumpListener;
private final ExcludedRefs excludedRefs;
}
先了解这里的每一个成员：
- WatchExecutor 提供后台线程支持以及重试的机制
- DebuggerControl 提供debug状态的判断，调试时有可能持有引用，规避误报泄漏
- GcTrigger 触发gc，尽量避免dump heap
- HeapDumper
- retainedKeys 存储所有监控的引用key，key是在watch时UUID生成的
- ReferenceQueue<Object> 监控系统gc的结果
- HeapDump.Listener dump完成的回调，可以认为是analysis的入口
- ExcludedRefs 预置的忽略引用，Android系统的已知内存泄漏，就可以不用管了
AndroidRefWatcherBuilder
这个类就是通常的Builder写法，只是多了一个RefWatcherBuilder基类，看整个包结构就知道LeakCanary的设计不只是用于Android，而是在java的外面再包一层android实现，这样扩展性好，watcher层定义行为和流程，android层对应具体的实现。
主流程
前面已经把主要的准备工作都介绍了，现在我们开始看看到底是如何监听泄漏的。
RefWatcher.java
/**
* Watches the provided references and checks if it can be GCed. This method is non blocking,
* the check is done on the {@link WatchExecutor} this {@link RefWatcher} has been constructed
* with.
*
* @param referenceName An logical identifier for the watched object.
*/
public void watch(Object watchedReference, String referenceName) {
if (this == DISABLED) {
return;
}
checkNotNull(watchedReference, "watchedReference");
checkNotNull(referenceName, "referenceName");
final long watchStartNanoTime = System.nanoTime();
String key = UUID.randomUUID().toString();
retainedKeys.add(key);
final KeyedWeakReference reference =
new KeyedWeakReference(watchedReference, key, referenceName, queue);
ensureGoneAsync(watchStartNanoTime, reference);
}
- 记录当前时间
- 生成key，生成KeyedWeakReference，记录弱引用和key
private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
watchExecutor.execute(new Retryable() {
@Override public Retryable.Result run() {
return ensureGone(reference, watchStartNanoTime);
}
});
}
@SuppressWarnings("ReferenceEquality") // Explicitly checking for named null.
Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
removeWeaklyReachableReferences();
if (debuggerControl.isDebuggerAttached()) {
// The debugger can create false leaks.
return RETRY;
}
if (gone(reference)) {
return DONE;
}
gcTrigger.runGc();
removeWeaklyReachableReferences();
if (!gone(reference)) {
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
File heapDumpFile = heapDumper.dumpHeap();
if (heapDumpFile == RETRY_LATER) {
// Could not dump the heap.
return RETRY;
}
long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
heapdumpListener.analyze(
new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
gcDurationMs, heapDumpDurationMs));
}
return DONE;
}
常见泄露场景
- 匿名内部类和非静态内部类 隐式持有外部类的引用
- 注册了引用，没有解注册
