LeakCanary 为什么会生成新的桌面图标啊

问题起源

大家现在都在用 LeakCanary 来做内存泄漏的检测，引入方式比较简单。

在 LeakCanary 2.0 之前

dependencies {
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.5'
}

以及在 Application 的 onCreate：

LeakCanary.install(this);

在 LeakCanary 2.0 之后，LeakCanary.install(this) 不必由开发者再自己手动写了，因为使用了 contentprovider 来自动完成

internal sealed class AppWatcherInstaller : ContentProvider() {
    override fun onCreate(): Boolean {
    	val application = context!!.applicationContext as Application
    	InternalAppWatcher.install(application)
   		return true
  }
}

安装以后，我们会看到生成了一个 Leaks 的桌面图标

导入一个库，却生成了另外的桌面图标，这是为什么呢？

问题探究

点开 Leaks 图标，dump 出 top activity 或者其他工具，可以知道打开的Activity 是 DisplayLeakActivity，我们到 github 上找 LeakCanary 源码（Tag 1.5），在库中搜索 DisplayLeakActivity
可以轻易找到

原来这个 DisplayLeakActivity 也定义了 以及 ，所以也可出现在应用程序列表上。
上面是 LeakCanary 1.5 的实现，那么 LeakCanary 2.0 是怎么实现的呢

这里可以看到，LeakCanary 生成图标的方式改变为使用 activity-alias 实现。顾名思义，activity-alias 可以指定 targetActivity，然后成为这个 targetActivity 的别名，一般供 Launcher 判别使用。注意，这个 activity-alias 仅作为标记使用，并没有 class 类，并通过 enabled 属性来确认是否启用。关于这个 activity-alias 的使用，可以用来动态替换图标，参考这篇文章：
上次发版我就改了一行代码

LeakCanary 原理总结

我们先来看一张架构图（来自LeakCanary 源码分析）：

整体过程就是，LeakCanary 会将监视的 activity 在 Lifecycle 的 onDestroy 阶段，使用弱引用 WeakReference 包装，并且添加到 ReferenceQueue 中，添加后，开启 ensureGone 方法，移除不可达对象或者再次触发 GC，判断监视对象是否还存在 ReferenceQueue 中。如果存在，则使用 Debug.dumpHprofData 生成堆内存快照 hprof 文件，hprof 文件具有固定格式，因此分析堆内存的各个对象的引用链，在引用链上的 GCroot 或者其他一些明确的对象是不需要分析的，因此标记为 leaking：no 或者 leaking unknown，直到找到第一个 leaking：yes 的对象，这个对象就是内存泄漏点。