都2024年了Android开发者，别再忽视LeakCanary了，GitHub标星1w的Android架构师必备技能

return
}
InternalAppWatcher.application = application

val configProvider = { AppWatcher.config }
ActivityDestroyWatcher.install(application, objectWatcher, configProvider)
FragmentDestroyWatcher.install(application, objectWatcher, configProvider)
onAppWatcherInstalled(application)
}

可以看到这里主要把Activity和Fragment区分了开来，然后分别进行注册。Activity的生命周期监听是借助于Application.ActivityLifecycleCallbacks。

fecycleCallbacks =
object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
override fun onActivityDestroyed(activity: Activity) {
if (configProvider().watchActivities) {
objectWatcher.watch(activity)
}
}
}


而Fragment的生命周期监听是借助了Activity的ActivityLifecycleCallbacks生命周期回调，当Activity创建的时候去调用FragmentManager.registerFragmentLifecycleCallbacks方法注册Fragment的生命周期监听。

override fun onFragmentViewDestroyed(
fm: FragmentManager,
fragment: Fragment
) {
val view = fragment.view
if (view != null && configProvider().watchFragmentViews) {
objectWatcher.watch(view)
}
}

override fun onFragmentDestroyed(
fm: FragmentManager,
fragment: Fragment
) {
if (configProvider().watchFragments) {
objectWatcher.watch(fragment)
}
}
}

最终，Activity和Fragment都将自己的引用传入了ObjectWatcher.watch()进行监控。从这里开始进入到LeakCanary的引用监测逻辑。

题外话：LeakCanary 2.0版本和1.0版本相比，增加了Fragment的生命周期监听，每个类的职责也更加清晰。但是我个人觉得使用 (Activty)->Unit 这种lambda表达式作为类的写法不是很优雅，倒不如面向接口编程。完全可以设计成ActivityWatcher和FragmentWatcher都继承自某个接口，这样也方便后续扩展。

![](https://img-blog.csdnimg.cn/img_convert/eaa54f3d1fd7ed8e73276c400d63d592.webp?x-oss-process=image/format,png)

# 2\. 引用监控

**2.1 引用和GC**

1.  引用
首先我们先介绍一点准备知识。大家都知道，java中存在四种引用：

*   强引用：垃圾回收器绝不会回收它，当内存空间不足，Java虚拟机宁愿抛出OOM
*   软引用：只有在内存不足的时候JVM才会回收仅有软引用指向的对象所占的空间
*   弱引用：当JVM进行垃圾回收时，无论内存是否充足，都会回收仅被弱引用关联的对象。
*   虚引用：和没有任何引用一样，在任何时候都可能被垃圾回收。

一个对象在被gc的时候，如果发现还有软引用（或弱引用，或虚引用）指向它，就会在回收对象之前，把这个引用加入到与之关联的引用队列(ReferenceQueue)中去。如果一个软引用（或弱引用，或虚引用）对象本身在引用队列中，就说明该引用对象所指向的对象被回收了。

当软引用（或弱引用，或虚引用）对象所指向的对象被回收了，那么这个引用对象本身就没有价值了，如果程序中存在大量的这类对象（注意，我们创建的软引用、弱引用、虚引用对象本身是个强引用，不会自动被gc回收），就会浪费内存。因此我们这就可以手动回收位于引用队列中的引用对象本身。

比如我们经常看到这种用法

WeakReference weakReference = new WeakReference(list);

还有也有这样一种用法

WeakReference weakReference = new WeakReference(list, new ReferenceQueue

这样就可以把对象和ReferenceQueue关联起来，进行对象是否gc的判断了。另外我们从弱引用的特征中看到，弱引用是不会影响到这个对象是否被gc的，很适合用来监控对象的gc情况。

2.GCjava中有两种手动调用GC的方式。

System.gc();
// 或者
Runtime.getRuntime().gc();

2.2 监控

我们在第一节中提到，Activity和Fragment都依赖于响应的LifecycleCallback来回调销毁信息，然后调用了ObjectWatcher.watch添加了销毁后的监控。接下来我们看ObjectWatcher.watch做了什么操作

@Synchronized fun watch(
watchedObject: Any,
name: String
) {
removeWeaklyReachableObjects()
val key = UUID.randomUUID().toString()
val watchUptimeMillis = clock.uptimeMillis()
val reference =
KeyedWeakReference(watchedObject, key, name, watchUptimeMillis, queue)
watchedObjects[key] = reference
checkRetainedExecutor.execute {
moveToRetained(key)
}
}

private fun removeWeaklyReachableObjects() {
// WeakReferences are enqueued as soon as the object to which they point to becomes weakly
// reachable. This is before finalization or garbage collection has actually happened.
var ref: KeyedWeakReference?
do {
ref = queue.poll() as KeyedWeakReference?
if (ref != null) {
watchedObjects.remove(ref.key)
}
} while (ref != null)
}

@Synchronized private fun moveToRetained(key: String) {
removeWeaklyReachableObjects()
val retainedRef = watchedObjects[key]
if (retainedRef != null) {
retainedRef.retainedUptimeMillis = clock.uptimeMillis()
onObjectRetainedListeners.forEach { it.onObjectRetained() }
}
}

这里我们看到，有一个存储着KeyedWeakReference的ReferenceQueue对象。在每次增加watch object的时候，都会去把已经处于ReferenceQueue中的对象给从监控对象的map即watchObjects中清理掉，因为这些对象都已经被回收了。然后再去生成一个KeyedWeakReference，这个对象就是一个持有了key和监测开始时间的WeakReference对象。最后再去调用moveToRetained，相当于记录和回调给监控方这个对象正式开始监测的时间。

那么我们现在已经拿到了需要监控的对象了，但是又是怎么去判断这个对象已经内存泄露的呢？这就要继续往下面看。我们主要到前面在讲解InternalAppWatcher的install方法的时候，除了install了Activity和Fragment的检测器，还调用了onAppWatcherInstalled(application)方法，看代码发现这个方法就是InternalLeakCanary的invoke方法。

 override fun invoke(application: Application) {
this.application = application

AppWatcher.objectWatcher.addOnObjectRetainedListener(this)

val heapDumper = AndroidHeapDumper(application, leakDirectoryProvider)

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
)
}

override fun onObjectRetained() {
if (this::heapDumpTrigger.isInitialized) {
heapDumpTrigger.onObjectRetained()
}
}

我们看到首先是初始化了heapDumper，gcTrigger，heapDumpTrigger等对象用于gc和heapDump，同时还实现了OnObjectRetainedListener，并把自己添加到了上面的onObjectRetainedListeners中，以便每个对象moveToRetained的时候，InternalLeakCanary都能获取到onObjectRetained()的回调，回调里就只是回调了heapDumpTrigger.onObjectRetained()方法。看来都是依赖于HeapDumpTrigger这个类。

HeapDumpTrigger主要的处理逻辑都在checkRetainedObjects方法中。

if (retainedReferenceCount > 0) {
gcTrigger.runGc() // 触发一次GC操作，只保留不能被回收的对象
retainedReferenceCount = objectWatcher.retainedObjectCount
}

if (checkRetainedCount(retainedReferenceCount, config.retainedVisibleThreshold)) return

if (!config.dumpHeapWhenDebugging && DebuggerControl.isDebuggerAttached) {
showRetainedCountWithDebuggerAttached(retainedReferenceCount)
scheduleRetainedObjectCheck(“debugger was attached”, WAIT_FOR_DEBUG_MILLIS)
return
}

val heapDumpUptimeMillis = SystemClock.uptimeMillis()
KeyedWeakReference.heapDumpUptimeMillis = heapDumpUptimeMillis
dismissRetainedCountNotification()
val heapDumpFile = heapDumper.dumpHeap()
if (heapDumpFile == null) {
scheduleRetainedObjectCheck(“failed to dump heap”, WAIT_AFTER_DUMP_FAILED_MILLIS)
showRetainedCountWithHeapDumpFailed(retainedReferenceCount)
return
}
lastDisplayedRetainedObjectCount = 0
objectWatcher.clearObjectsWatchedBefore(heapDumpUptimeMillis)

HeapAnalyzerService.runAnalysis(application, heapDumpFile)

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

总结

**其实上面说了这么多，钱是永远赚不完的，在这个知识付费的时代，知识技能提升才是是根本！我作为一名8年的高级工程师，知识技能已经学习的差不多。**在看这篇文章的可能有刚刚入门，刚刚开始工作，或者大佬级人物。

像刚刚开始学Android开发小白想要快速提升自己，最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以这里分享一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

这么重要的事情说三遍啦！点赞+点赞+点赞 免费分享所有学习秘籍！
直达领取链接：点击链接免费领取【Android高级架构师】

【Android高级架构师系统学习资料】高级架构师进阶必备——设计思想解读开源框架

第一章、热修复设计
第二章、插件化框架设计
第三章、组件化框架设计
第四章、图片加载框架
第五章、网络访问框架设计
第六章、RXJava 响应式编程框架设计
第七章、IOC 架构设计
第八章、Android 架构组件 Jetpack

[外链图片转存中…(img-re9c31wo-1711105272439)]

【Android高级架构师系统学习资料】高级架构师进阶必备——设计思想解读开源框架

第一章、热修复设计
第二章、插件化框架设计
第三章、组件化框架设计
第四章、图片加载框架
第五章、网络访问框架设计
第六章、RXJava 响应式编程框架设计
第七章、IOC 架构设计
第八章、Android 架构组件 Jetpack