工作中遇到的Android内存优化问题(3)-leakcanary源码解析

今天我们来看一下一个内存泄漏检测神器 leakcanary(https://github.com/square/leakcanary)

首先我们来看一下leakcanary的使用说明



就这么多，只需要一行代码，太简单了，简单得都有点怀疑它了。

我们来看一下一个简单的例子，也是它官方源码中提供的一个例子，这个因为太小了我就截了个图



从例子中可以看到，AsyncTask执行了sleep操作，但是由于AsyncTask声明为了一个内部匿名类，此类持有外部类的对象，导致用户退出此Activity时,此Activity不能被gc回收，安装此例子到手机，点击START NEW ASYNCTASK,退出app，观察手机，会弹出一个内存泄漏通知如下图



很神奇吧，连泄漏的堆栈调用信息都能查到，比我们在前两篇用到的工具方便多了

leakcanary很神奇，就像魔术一样，我们很想知道它背后的运行机制，现在我们就来解析一下leakcanary的源码。首先从我们应用Application入手，因为leakcanary在使用中只有一行代码，我们就从这行代码慢慢跟踪一下源码。

public class ExampleApplication extends Application {

@Override public void onCreate() {
super.onCreate();
LeakCanary.install(this);
}
}

首先我们进入install方法，install方法调用了另一个install方法

public static RefWatcher install(Application application) {
return install(application, DisplayLeakService.class,
AndroidExcludedRefs.createAppDefaults().build());
}

/**
* Creates a {@link RefWatcher} that reports results to the provided service, and starts watching
* activity references (on ICS+).
*/
public static RefWatcher install(Application application,
Class<? extends AbstractAnalysisResultService> listenerServiceClass,
ExcludedRefs excludedRefs) {
if (isInAnalyzerProcess(application)) {
return RefWatcher.DISABLED;
}
enableDisplayLeakActivity(application);
//此Listener很重要，在后面会扮演重要角色
HeapDump.Listener heapDumpListener =
new ServiceHeapDumpListener(application, listenerServiceClass);
//从名字我们就可以看出它是监视内存泄漏对象的
RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);
//
ActivityRefWatcher.installOnIcsPlus(application, refWatcher);
return refWatcher;
}

接着进入installOnIcsPlus方法，此方法就到了关键的地方，能解开为什么我们只用一个方法，就能监听所有的内存泄漏

public static void installOnIcsPlus(Application application, RefWatcher refWatcher) {
if (SDK_INT < ICE_CREAM_SANDWICH) {
// If you need to support Android < ICS, override onDestroy() in your base activity.
return;
}
ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);
activityRefWatcher.watchActivities();
}

 ActivityRefWtacher提供了一个方法 watchActivitys()

public void watchActivities() {
// Make sure you don't get installed twice.
stopWatchingActivities();
application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
}

Android4.0以上的Application中提供了registerActivityLifecycleCallbacks方法，此方法从名字就可以看出是监听Activity生命周期的，我们再来看看参数lifecycleCallbacks的定义，

private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new Application.ActivityLifecycleCallbacks() {
@Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
}

@Override public void onActivityStarted(Activity activity) {
}

@Override public void onActivityResumed(Activity activity) {
}

@Override public void onActivityPaused(Activity activity) {
}

@Override public void onActivityStopped(Activity activity) {
}

@Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
}

@Override public void onActivityDestroyed(Activity activity) {
ActivityRefWatcher.this.onActivityDestroyed(activity);
}
};

看到了吧，所有Activity们只要调用了onDestroy方法，就会被回调方法onActivityDestroyed知道，然后传入 ActivityRefWatcher的方法 onActivityDestroyed中，此方法很简单

void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}

refWatcher就是我们上面install方法中创建的，进入watch方法

public void watch(Object watchedReference, String referenceName) {
checkNotNull(watchedReference, "watchedReference");
checkNotNull(referenceName, "referenceName");
if (debuggerControl.isDebuggerAttached()) {
return;
}
final long watchStartNanoTime = System.nanoTime();
//首先生成了一个id,此id是用来唯一标识这个检测对象的
String key = UUID.randomUUID().toString();
//将id存起来
retainedKeys.add(key);
//KeyWeakReference集成自 WeakReference(弱引用),WeakReference使用来跟踪这个对象的，
//弱引用大家都明白,它不会影响gc回收,构造WeakReference时,可以传入一个ReferenceQueue,
//这个ReferenceQueue的主要作用是当对象不可达时也就是可以被gc回收时,对象所对应的WeakReference就会被放入
//ReferenceQueue中,只要检测ReferenceQueue是否有我们的对象的WeakReference,就可以判断对象是否可能泄漏
final KeyedWeakReference reference =
new KeyedWeakReference(watchedReference, key, referenceName, queue);

watchExecutor.execute(new Runnable() {
@Override public void run() {
//此方法就是为了确认对象是否可回收
ensureGone(reference, watchStartNanoTime);
}
});
}

进入ensureGone方法

void ensureGone(KeyedWeakReference reference, long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();

long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
//此方法是循环ReferenceQueue,如果对象的ReferenceQueue在里面,就从retainedKeys中移除对象的key,
//因为此对象已经可回收,是安全的
removeWeaklyReachableReferences();
//判断我们要检测的reference是否还在retainedKeys中,如果不在说明已经被移除了,也就是可以被gc回收了
if (gone(reference) || debuggerControl.isDebuggerAttached()) {
return;
}
//执行垃圾回收,但是只是建议,并不是一定会执行
gcTrigger.runGc();
//再次从retainedKeys移除安全的key
removeWeaklyReachableReferences();
//如果此对象的WeakReference还是不能被回收,那么此对象就有可能泄漏了,只是可能,因为gc在上一步可能没有运行
if (!gone(reference)) {
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
//此方法获得内存Heap的hprof文件,LeakCanary之所以这么好用,主要是在这里,它分析了hprof文件,来确认内存泄漏,
//我们在上一篇也分析过hprof文件,原来LeakCanary也是分析这个文件,只是不需要人工分析了,LeakCanary用了一个自己
//的开源hprof分析库haha(https://github.com/square/haha)此库是基于google的perflib.
File heapDumpFile = heapDumper.dumpHeap();

if (heapDumpFile == HeapDumper.NO_DUMP) {
// Could not dump the heap, abort.
return;
}
long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
//heapdumpListener主要就是启动服务分析hprof文件
heapdumpListener.analyze(
new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
gcDurationMs, heapDumpDurationMs));
}
}

heapdumpListener在前面创建的时候是一个ServiceHeapDumpListener对象,进入此对象的analyze方法

@Override public void analyze(HeapDump heapDump) {
checkNotNull(heapDump, "heapDump");
HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);
}

public static void runAnalysis(Context context, HeapDump heapDump,
Class<? extends AbstractAnalysisResultService> listenerServiceClass) {
Intent intent = new Intent(context, HeapAnalyzerService.class);
intent.putExtra(LISTENER_CLASS_EXTRA, listenerServiceClass.getName());
intent.putExtra(HEAPDUMP_EXTRA, heapDump);
context.startService(intent);
}

启动服务分析hprof文件，接着我们来看看这个服务

@Override protected void onHandleIntent(Intent intent) {
if (intent == null) {
CanaryLog.d("HeapAnalyzerService received a null intent, ignoring.");
return;
}
String listenerClassName = intent.getStringExtra(LISTENER_CLASS_EXTRA);
HeapDump heapDump = (HeapDump) intent.getSerializableExtra(HEAPDUMP_EXTRA);

//分析hprof的核心类
HeapAnalyzer heapAnalyzer = new HeapAnalyzer(heapDump.excludedRefs);
//检查我们的对象是否内存泄漏
AnalysisResult result = heapAnalyzer.checkForLeak(heapDump.heapDumpFile, heapDump.referenceKey);
AbstractAnalysisResultService.sendResultToListener(this, listenerClassName, heapDump, result);
}

进入checkForLeak方法

public AnalysisResult checkForLeak(File heapDumpFile, String referenceKey) {
long analysisStartNanoTime = System.nanoTime();

if (!heapDumpFile.exists()) {
Exception exception = new IllegalArgumentException("File does not exist: " + heapDumpFile);
return failure(exception, since(analysisStartNanoTime));
}

try {
HprofBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile);
//解析器解析文件
HprofParser parser = new HprofParser(buffer);
//解析过程,是基于google的perflib库,根据hprof的格式进行解析，这里就不展开看了
Snapshot snapshot = parser.parse();
//分析结果进行去重
deduplicateGcRoots(snapshot);
//此方法就是根据我们需要检测的类的key,查询解析结果中是否有我们的对象，获取解析结果中我们检测的对象
Instance leakingRef = findLeakingReference(referenceKey, snapshot);
//此对象不存在表示已经被gc清除了,不存在泄露因此返回无泄漏
// False alarm, weak reference was cleared in between key check and heap dump.
if (leakingRef == null) {
return noLeak(since(analysisStartNanoTime));
}
//此对象存在也不能也不能确认它内存泄漏了，要检测此对象的gc root
return findLeakTrace(analysisStartNanoTime, snapshot, leakingRef);
} catch (Throwable e) {
return failure(e, since(analysisStartNanoTime));
}
}

我们重点看一下findLeakingReference方法

private Instance findLeakingReference(String key, Snapshot snapshot) {
//因为需要检测的类都构造了一个KeyedWeakReference,因此先找到KeyedWeakReference,就可以找到我们的对象
ClassObj refClass = snapshot.findClass(KeyedWeakReference.class.getName());
List<String> keysFound = new ArrayList<>();
//循环所有KeyedWeakReference实例
for (Instance instance : refClass.getInstancesList()) {
List<ClassInstance.FieldValue> values = classInstanceValues(instance);
//找到KeyedWeakReference里面的key值,此值在我们前面传入的对象唯一标示
String keyCandidate = asString(fieldValue(values, "key"));
//当key值相等时就表示是我们的检测对象
if (keyCandidate.equals(key)) {
return fieldValue(values, "referent");
}
keysFound.add(keyCandidate);
}
throw new IllegalStateException(
"Could not find weak reference with key " + key + " in " + keysFound);
}

最后一步，也是最核心的方法，确认是否内存泄漏,和我们手动分析hprof的方法几乎相同

private AnalysisResult findLeakTrace(long analysisStartNanoTime, Snapshot snapshot,
Instance leakingRef) {

//这两行代码是判断内存泄露的关键,我们在上篇中分析hprof文件,判断内存泄漏
//判断的依据是展开调用到gc root,所谓gc root,就是不能被gc回收的对象,
//gc root有很多类型,我们只要关注两种类型1.此对象是静态 2.此对象被其他线程使用,并且其他线程正在运行,没有结束
//pathFinder.findPath方法中也就是判断这两种情况
ShortestPathFinder pathFinder = new ShortestPathFinder(excludedRefs);
ShortestPathFinder.Result result = pathFinder.findPath(snapshot, leakingRef);
// 找不到引起内存泄漏的gc root,就表示此对象未泄漏
// False alarm, no strong reference path to GC Roots.
if (result.leakingNode == null) {
return noLeak(since(analysisStartNanoTime));
}

//生成泄漏的调用栈,为了在通知栏中显示
LeakTrace leakTrace = buildLeakTrace(result.leakingNode);

String className = leakingRef.getClassObj().getClassName();

// Side effect: computes retained size.
snapshot.computeDominators();

Instance leakingInstance = result.leakingNode.instance;

//计算泄漏的空间大小
long retainedSize = leakingInstance.getTotalRetainedSize();

retainedSize += computeIgnoredBitmapRetainedSize(snapshot, leakingInstance);

return leakDetected(result.excludingKnownLeaks, className, leakTrace, retainedSize,
since(analysisStartNanoTime));
}

核心的代码我们已经看完了，是不是有一种豁然开朗的感觉，这就是好的软件，将重复繁琐的工作封装起来，只给我们留下一个两行的使用说明