leakcanary2.0原理分析

1 问题描述

1.1 背景

Android内存泄漏检测工具--leakcanary，想必是众所周知。关于具体用法本文不做具体赘述，可参考官网https://square.github.io/leakcanary/。在1.x版本时，我们需要手动在初始化；但是在2.x发布之后，只需要直接在build.gradle中添加依赖即可，无需添加任何代码，做到代码0侵入。起初看到这种神操作时，我的第一感觉就是hook与插桩。

1.2 问题

秉承对知识的好奇，我花了一小段时间针对2.x源码进行分析，目的主要是解决如下困惑：
2.x是怎么做到0侵入的？

2 基础知识

2.1 App启动过程

下图描述了应用启动的整个过程。

image.png

2.2 Application

对于Application，大家一定清楚它的初始化是在Activity之前。但是可能并不知道的是：ContentProvider的初始化是在Applicaton前面，如下图是官方文档解释：

image.png

2.3 ContentProvider

ContentProvider我们基本很少使用，它的主要作用是在不同应用程序之间共享数据。关于它的基本使用不是本章讨论范围，本章主要分析下它的生命周期与Application关系。

//声明一个Applicaiton
class DemoApp : Application() {
    companion object {
        const val TAG = "DemoApp"
    }
    override fun attachBaseContext(base: Context?) {
        Log.d(TAG, "Application#attachBaseContext()")
        super.attachBaseContext(base)
    }

    override fun onCreate() {
        Log.d(TAG, "Application#onCreate()")
        super.onCreate()
    }
}
//声明一个ContentProvider
class DemoContentProvider : ContentProvider() {
    override fun onCreate(): Boolean {
        Log.d(DemoApp.TAG, "DemoContentProvider#onCreate()")
        return true
    }
}

如上代码我们只声明了两个，输出如下结果：
D/DemoApp: Application#attachBaseContext()
D/DemoApp: DemoContentProvider#onCreate()
D/DemoApp: Application#onCreate()

表明:
ContentProvider的创建确实是在Applicaiton#onCreate()方法之前，并且在Applicaition#attachBaseContext()之后。
基于这一点，被leakcancary巧妙的利用了。Leakcanary#install()正是在这执行了。

3 原理剖析

下面我们从源码角度分析。按照上面思路，leakcanary2.x需要一个contentProvider。为快速找到具体哪个provider，我们直接分析已集成的apk的manifest.xml，全局搜索leakcanary找到如下provider：

image.png

然后，搜索该类

image.png

MainProcess继承自AppWatcherInstaller，如下截图为该类以及关键生命周期方法

image.png

image.png

于是，我们清晰地认识到

1. ContentProvider#onCreate()发生在Application#onCreate()之前
2. Leakcanary#install在****ContentProvider#onCreate()之中

通过上面两点，我们不需要明码install，正如下图官方文档所述：

image.png

4 思维拓展

我们在使用androidx.lifecycle组件的时候，也没有显示调用Applicaiton#registerActivityLifecycleCallbacks()，正是使用这个原理，有兴趣的可以自行分析。