Android-LeakCanary原理解析

Posted 2023-02-22

参考技术A 在分析LeakCanary原理之前，首先需要了解ReferenceQueue在LeakCanary的作用。
WeakReference在创建时，如果指定一个ReferenceQueue对象，在垃圾回收检测到被引用的对象的可达性更改后，垃圾回收器会将已注册的引用对象添加到ReferenceQueue对象中，等待ReferenceQueue处理。但是如果当GC过后引用对象仍然不被加入ReferenceQueue中，就可能存在内存泄露问题。这里ReferenceQueue对象中，存的其实就是WeakReference对象，而不是WeakReference中引用的要被回收的对象。即GC过后，WeakReference引用的对象被回收了，那么WeakReference引用的对象就是null，那么该WeakReference对象就会被加入到ReferenceQueue队列中。
所以我们可以通过监听 Activity.onDestroy() 回调之后，通过弱引用（WeakReference）对象、ReferenceQueue和 GC来观测Activity引用的内存泄露情况，如果发现了未被回收的Activity对象，在找到该Activity对象是否被其他对象所引用，如果被其他对象引用，就进行 heap dump生成完整的内存引用链（最短引用链），并通过notification等方式展示出来。

LeakCanary2.+的启动，与LeakCanary1.+的不同，1.+版本的启动，需要在Application的onCreate中手动调用LeakCanary.install方法进行启动；而2.+版本的启动则不需要，而是依赖ContentProvider，因为ContentProvider会在Application之前被加载，所以ContentProvider的onCreate方法会在Application的onCreate方法之前被调用，所以在ContentProvider的onCreate方法中完成初始化工作。
在源码中leakcanary-leaksentry中有一个LeakSentryInstaller，LeakSentryInstaller其实就是ContentProvider的一个子类，在其onCreate方法中就会调用InternalLeakSentry.install(application)进行初始化工作。

然后在androidManifest.xml中注册该ContentProvider。在这里注册，那么打包项目时，会将每个库和library中的AndroidManifest.xml合并到最终的app的androidManifest中。

LeakCanary的初始化是在InternalLeakSentry的install方法，即在ContentProvider的onCreate中调用。

这里的listener是LeakSentryListener接口，而实现LeakSentryListener接口的类，其实就是InternalLeakCanary，InternalLeakCanary是在leakcanary-android-core下的，InternalLeakCanary是单例模式的，采用的是kotlin单例，即用object关键字修饰类。

这里使用的RefWatcher对象，是在InternalLeakSentry中进行初始化的，然后在调用ActivityDestroyWatcher和FragmentDestroyWatcher的install方法的时候，传入。

在监测Activity和Fragment的生命周期进行内存回收以及是否泄露的过程，就是调用RefWatcher.watch方法进行，该方法是使用Synchronized修饰的同步方法。RefWatcher.watch的方法，一般是在Activity和Fragment生命周期执行到onDestroy的时候调用。根据生命周期监听触发回调，然后调用RefWatcher.watch方法。

VisibilityTracker其实就是在InternalLeakCanary.onLeakSentryInstalled方法中通过调用application.registerVisibilityListener方法的时候，添加的Application.ActivityLifecycleCallbacks，这里采用适配器模式，使用适配器模式的目的，其实就是不需要重写所有方法，只在VisibilityTracker中重写需要使用的方法。
VisibilityTracker的目的其实就是监听Activity的生命周期变化，即是否是执行到了onStart和onStop，如果是onStop的时候，则做内存泄露监测工作。
VisibilityTracker与ActivityDestroyWatcher有点区别，ActivityDestroyWatcher是最终Activity执行onDestroy的时候进行内存泄露分析

本方法是在InternalLeakCanary.onLeakSentryInstalled给application添加生命周期回调的时候，根据onStart和onStop生命周期的变化来进行Heap Dump（heap dump文件(.hprof)）
当生命周期执行到onStop的时候，会向该Application的扩展函数registerVisibilityListener的参数listener这个高阶函数传入boolean参数为false
看InternalLeakCanary#onLeakSentryInstalled方法中对application添加的生命周期监听，这是调用了application的扩展函数，该扩展函数是在VisibilityTracker中定义的。

其实registerVisibilityListener方法内部调用的就是application的registerActivityLifecycleCallbacks方法，传入的是Application.ActivityLifecycleCallbacks对象，这里传入的是VisibilityTracker，其实VisibilityTracker就是Application.ActivityLifecycleCallbacks的子类实现。

HeapDumpTrigger.onApplicationVisibilityChanged方法的调用，就是根据上述传给VisibilityTracker的listener函数来回调调用的，listener接收的是false的时候，就会调用scheduleRetainedInstanceCheck，接收的是false的时候是生命周期执行到onStop的时候。

这里的delayMillis默认是5s，因为该参数接收的是LeakSentry.config.watchDurationMillis，这个值初始默认值是5s。