前提：LeakCanary 版本v2.4; Android 8.0
LeakCanary相信很多开发者都用过，也是目前为止我看到的一款最简单方便的简单内存泄漏的工具了，使用之后，会有以下几个问题：
1：LeakCanary的初始化在哪里？
较早之前使用leankCanary时，在Application中，会有一个初始化的代码，但在后来2.0版本之后，初始化的代码没了，但确不影响我们使用。难道是后续不需要初始化了？
其实初始化还是有的，只是后续的版本，利用了Android app的启动流程中的机制，将自身的初始化放入的provider中。在app启动时，会优先初始化app中的provider，正是利用这一特性，所以才不用我们写初始化的代码
image.png
2：初始化的provider在哪里？干了什么事情？
我们可以去github中找一下相关的provider或者在Android Studio引入的leakcanary包中，在相应的mainfest中找一下provider
image.png
从上图已标出初始化的provider为 AppWatchInstaller$MainProcess
注意:在有的文章中,会说初始化的工程是leakcanar-leaksentry下面的LeakSentryInstaller,我也被这些文章弄的差点错了，后来翻看LeakCanary的github各版本修改日志发现，确实以前初始化的provider是LeakSentryInstall,但仅限于在2.0 Alpha各版本中，在2.0 Beta版之后，就统一改了。
image.png
这个大家要注意一些了。
那究竟初始化都做了些什么。
fun install(application: Application) {
checkMainThread()
if (this::application.isInitialized) {
return
}
SharkLog.logger = DefaultCanaryLog()
InternalAppWatcher.application = application
val configProvider = { AppWatcher.config }
ActivityDestroyWatcher.install(application, objectWatcher, configProvider)
FragmentDestroyWatcher.install(application, objectWatcher, configProvider)
onAppWatcherInstalled(application)
}
跟进代码可以发现，这里做了最关键的一步，xxxDestroyWatcher的注册。在xxxDestroyWatcher中，对Activity,Fragment做了相应的保存，并监听它他的生命周期。
3：检查内存泄漏的原理是什么？
我们在使用WeakReference或PhantomReference时，会发现他们有一个构造方法是这样的：
public class WeakReference<T> extends Reference<T> {
public WeakReference(T referent) {
super(referent);
}
public WeakReference(T referent, ReferenceQueue<? super T> q) {
super(referent, q);
}
}
我们发现，第二个构造方法中，需要传入一个ReferenceQueue的构造方法。这个RefereneQueue就是检查内存泄漏用的。当对象被回收之后，就会把对象放到这个ReferenceQueue中来，所以如果Activity在onDestroy后，如果没有被回收，由在队列中就没有该Activity，那么就可以认为存在内存泄漏。
4：LeakCanary是如何检测的？
ActivityDestroyWatcher
private val lifecycleCallbacks =
object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
override fun onActivityDestroyed(activity: Activity) {
if (configProvider().watchActivities) {
objectWatcher.watch(
activity, "${activity::class.java.name} received Activity#onDestroy() callback"
)
}
}
}
从代码中可以看到，当监听到activity的destroy后，就会执行相应的objectWatch.watch来做一些处理，但真正判断内存泄漏的地方却不在这里。
在InternalAppWatcher.install方法中，除了调用xxxDestroyWatch外，还有一段代码onAppWatcherInstalled(application)，看代码其实就是InternalLeakCanary的invoke。
override fun invoke(application: Application) {
_application = application
checkRunningInDebuggableBuild()
AppWatcher.objectWatcher.addOnObjectRetainedListener(this)
val heapDumper = AndroidHeapDumper(application, createLeakDirectoryProvider(application))
val gcTrigger = GcTrigger.Default
val configProvider = { LeakCanary.config }
val handlerThread = HandlerThread(LEAK_CANARY_THREAD_NAME)
handlerThread.start()
val backgroundHandler = Handler(handlerThread.looper)
heapDumpTrigger = HeapDumpTrigger(
application, backgroundHandler, AppWatcher.objectWatcher, gcTrigger, heapDumper,
configProvider
)
application.registerVisibilityListener { applicationVisible ->
this.applicationVisible = applicationVisible
heapDumpTrigger.onApplicationVisibilityChanged(applicationVisible)
}
registerResumedActivityListener(application)
addDynamicShortcut(application)
disableDumpHeapInTests()
}
在这里面初始化了heapDumper，gcTrigger，heapDumpTrigger等对象用于gc和heapDump，同时还实现了OnObjectRetainedListener，并把自己添加到了上面的onObjectRetainedListeners中，以便每个对象moveToRetained的时候，InternalLeakCanary都能获取到onObjectRetained()的回调，回调里就只是回调了heapDumpTrigger.onObjectRetained()方法。看来都是依赖于HeapDumpTrigger这个类。
HeapDumpTrigger的主逻辑在checkRetainedObjects
private fun checkRetainedObjects(reason: String) {
val config = configProvider()
// A tick will be rescheduled when this is turned back on.
if (!config.dumpHeap) {
SharkLog.d { "Ignoring check for retained objects scheduled because $reason: LeakCanary.Config.dumpHeap is false" }
return
}
var retainedReferenceCount = objectWatcher.retainedObjectCount
if (retainedReferenceCount > 0) {
gcTrigger.runGc()
retainedReferenceCount = objectWatcher.retainedObjectCount
}
if (checkRetainedCount(retainedReferenceCount, config.retainedVisibleThreshold)) return
if (!config.dumpHeapWhenDebugging && DebuggerControl.isDebuggerAttached) {
onRetainInstanceListener.onEvent(DebuggerIsAttached)
showRetainedCountNotification(
objectCount = retainedReferenceCount,
contentText = application.getString(
R.string.leak_canary_notification_retained_debugger_attached
)
)
scheduleRetainedObjectCheck(
reason = "debugger is attached",
rescheduling = true,
delayMillis = WAIT_FOR_DEBUG_MILLIS
)
return
}
val now = SystemClock.uptimeMillis()
val elapsedSinceLastDumpMillis = now - lastHeapDumpUptimeMillis
if (elapsedSinceLastDumpMillis < WAIT_BETWEEN_HEAP_DUMPS_MILLIS) {
onRetainInstanceListener.onEvent(DumpHappenedRecently)
showRetainedCountNotification(
objectCount = retainedReferenceCount,
contentText = application.getString(R.string.leak_canary_notification_retained_dump_wait)
)
scheduleRetainedObjectCheck(
reason = "previous heap dump was ${elapsedSinceLastDumpMillis}ms ago (< ${WAIT_BETWEEN_HEAP_DUMPS_MILLIS}ms)",
rescheduling = true,
delayMillis = WAIT_BETWEEN_HEAP_DUMPS_MILLIS - elapsedSinceLastDumpMillis
)
return
}
SharkLog.d { "Check for retained objects found $retainedReferenceCount objects, dumping the heap" }
dismissRetainedCountNotification()
dumpHeap(retainedReferenceCount, retry = true)
}
那么HeapDumpTrigger主要是下面几个功能：
- 后台线程轮询当前还存活着的对象
- 如果存活的对象大于0，那就触发一次GC操作，回收掉没有泄露的对象
- GC完后，仍然存活着的对象数和预定的对象数相比较，如果多了就调用heapDumper.dumpHeap()方法把对象dump成文件，并交给HeapAnalyzerService去分析
- 根据存活情况展示通知
网友评论