如何自己设计一个内存泄漏监控系统

监控生命周期

在 Android 应用中，准确判断对象是否处于生命周期终结状态是监控内存泄漏的关键起始点。对于 Activity 而言，其 onDestroy 方法的执行标志着它在理论上进入了可被回收的阶段。而在这一过程中，Activity 的 onDestroy 方法会调用 getApplication().dispatchActivityDestroyed(this)。

基于此机制，在 Application 的 registerActivityLifecycleCallbacks 方法中进行监听操作，从而得知哪些 Activity 需要被回收。

public class MyApplication extends Application {
    private static final String TAG = "MyApplication";

    @Override
    public void onCreate() {
        super.onCreate();
        // 注册 Activity 生命周期回调
        registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {
            @Override
            public void onActivityDestroyed(@NonNull Activity activity) {
                Log.d(TAG, "onActivityDestroyed: " + activity.getClass().getName());
                // 此时表明该 activity 需要回收了，后续可针对此 activity 进行内存泄漏监控操作
            }

            // 其他生命周期回调方法，这里暂不做详细处理，但在完整的监控系统中可能需要根据需求进一步利用
            @Override
            public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {}

            @Override
            public void onActivityStarted(@NonNull Activity activity) {}

            @Override
            public void onActivityResumed(@NonNull Activity activity) {}

            @Override
            public void onActivityPaused(@NonNull Activity activity) {}

            @Override
            public void onActivityStopped(@NonNull Activity activity) {}

            @Override
            public void onActivitySaveInstanceState(@NonNull Activity activity, @NonNull Bundle outState) {}
        });
    }
}

registerActivityLifecycleCallbacks 方法能够在 Application 层面获取到所有 Activity 的生命周期事件通知。当 onActivityDestroyed 被触发时，得到一个可能存在内存泄漏风险的对象（即刚被销毁的 Activity），后续便可以针对这个对象展开进一步的监控与分析工作。

监控 GC 情况

GC回收的对象是哪些，没有回收的对象又是哪些?

在确定了可能被回收的对象（如 Activity）后，需要深入监控其在垃圾回收（GC）过程中的情况，即明确哪些对象被 GC 回收了，哪些没有。

以 Fragment 为例（Fragment 通常依托于 Activity），创建一个 FragmentWatcher 类来实现相关监控功能。

public class FragmentWatcher {
    private static final String TAG = "alvin FragmentWatcher";

    // 定义 Fragment 生命周期回调
    private final FragmentManager.FragmentLifecycleCallbacks fragmentLifecycleCallbacks =
            new FragmentManager.FragmentLifecycleCallbacks() {
                @Override
                public void onFragmentViewDestroyed(@NonNull FragmentManager fm, @NonNull Fragment f) {
                    super.onFragmentViewDestroyed(fm, f);
                    Log.i(TAG, "onFragmentViewDestroyed: " + f.getClass().getName());
                }

                @Override
                public void onFragmentDestroyed(@NonNull FragmentManager fm, @NonNull Fragment f) {
                    super.onFragmentDestroyed(fm, f);
                    Log.i(TAG, "onFragmentDestroyed: " + f.getClass().getName());
                }
            };

    // 用于在指定的 Activity 中启动对其所属 Fragment 的监控
    void watchFragments(AppCompatActivity activity) {
        FragmentManager fragmentManager = activity.getSupportFragmentManager();
        // 注册 Fragment 生命周期回调，设置 recursive 为 true 表示递归监控所有子 Fragment
        fragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true);
    }
}

为了进一步确定对象是否真正被回收，引入弱引用和引用队列的概念。

弱引用的特性是，如果其引用的对象在垃圾回收时没有其他强引用指向它，那么该对象将会被回收，并且弱引用自身会被加入到引用队列中。

引用队列可以配合软引用、弱引用及幽灵引用使用，当引用的对象将要被JVM回收时，会将其加入到引用队列中。

public static void main(String[] args) {
    // 创建引用队列
    ReferenceQueue<String> queue = new ReferenceQueue<>();
    String string1 = new String("hello all");
    // 创建软引用并关联 string1 和引用队列
    SoftReference<String> softReference = new SoftReference<>(string1, queue);

    ReferenceQueue<String> queue2 = new ReferenceQueue<>();
    String string2 = new String("yes!");
    // 创建弱引用并关联 string2 和引用队列
    WeakReference<String> weakReference = new WeakReference<>(string2, queue2);

    string1 = null;
    // 此时软引用的对象不会被回收，因为内存充足
    System.out.println(softReference.get());  // hello all
    System.out.println(queue.poll()); // null

    string2 = null;
    // 此时弱引用的对象虽然被设置为 null，但还未被 GC 回收
    System.out.println(weakReference.get());  // yes
    System.out.println(queue2.poll());  // null

    System.gc();

    // 软引用在内存不足时才会回收，这里内存充足所以不会被回收
    System.out.println(softReference.get());  // hello all
    System.out.println(queue.poll());  // null

    // 弱引用在 JVM 垃圾回收时被回收，此时弱引用的 get 方法返回 null，且弱引用被加入到引用队列中
    System.out.println(weakReference.get());  // null
    System.out.println(queue2.poll());  // java.lang.ref.WeakReference
}

在内存泄漏监控系统中，用弱引用去引用将要被释放的 Activity 或者 Fragment，配合引用队列来监控该 Activity 或者 Fragment 是否有被回收。

如果弱引用在 GC 后被释放（即弱引用的 get 方法返回 null），则说明该对象没有发生内存泄漏；
如果弱引用未被释放，则可能存在内存泄漏情况，但也可能是该对象所引用的其他对象还未被释放，这种情况下需要进一步等待和分析。

分析调用栈

当发现可能存在内存泄漏的对象（即弱引用未被释放的情况）时，需要深入分析可能存在泄漏问题的变量的持有链。

通过分析持有链，可以追溯到对象被哪些其他对象所引用，从而找出可能导致对象无法被回收的原因。

例如，如果一个 Activity 被一个长时间存活的对象（如一个单例类中的静态变量）所引用，那么即使 Activity 已经执行了 onDestroy 方法，它也无法被垃圾回收器回收，从而导致内存泄漏。

在实际的分析过程中，可能需要借助一些工具和技术来获取和解析对象的持有链信息，例如通过分析堆转储（Heap Dump）文件来获取对象的引用关系图，然后沿着引用链逐步排查可能存在的问题。

LeakCanary 相关原理与优化

监控机制与初始化

LeakCanary 以 Application 为切入点，通过在 Application 中注册相关回调函数来监听 Activity 的生命周期事件，进而在 Activity 的生命周期方法中对 Fragment 的生命周期进行进一步的监听与适配。

例如，在 Activity 的 onCreate 方法中，LeakCanary 会执行类似如下代码来启动对 Fragment 的监控：

1
2
3

for (FragmentRefWatcher watcher : fragmentRefWatchers) {
    watcher.watchFragments(activity);
}

这里的 watch 函数是公开的，这意味着不仅可以对 Activity 和 Fragment 进行内存泄漏监控，任何怀疑会被泄露的对象都可以通过 watch 进行监听，这种设计极大地扩展了 LeakCanary 的监控范围和灵活性。

自启动原理

从 2.0 版本开始，LeakCanary 实现了自启动功能，其原理是将启动逻辑放到了 Provider 中。在 Android 应用的启动流程中，Provider 的 onCreate 方法会在应用启动时被调用，早于 Application 的 onCreate 方法。

new application() -> provider.oncreate() -> application.oncreate()

LeakCanary 利用这一特性，在其 Provider（如 leakcanary.internal.AppWatcherInstaller$MainProcess）的 onCreate 方法中进行一些初始化和启动操作，从而实现了无需手动编写代码调用 Install 方法进行初始化的自动化功能。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.squareup.leakcanary.objectwatcher">

    <uses-sdk android:minSdkVersion="14"/>

    <application>
        <provider
            android:name="leakcanary.internal.AppWatcherInstaller$MainProcess"
            android:authorities="${applicationId}.leakcanary-installer"
            android:enabled="@bool/leak_canary_watcher_auto_install"
            android:exported="false"/>
    </application>
</manifest>

在应用启动时，首先会创建 new Application()，然后调用 provider.onCreate()，最后才是 application.onCreate()。LeakCanary 正是利用这个顺序，在 provider.onCreate() 中完成了部分关键的初始化工作，使得整个内存泄漏监控系统能够自动启动并运行。

2.0优势

语言与技术更新

随着 Kotlin 语言在 Android 开发领域的日益普及（已在众多大厂中逐渐替代 Java），LeakCanary 也积极跟进技术趋势，采用 Kotlin 语言进行开发。Google 对 Kotlin 的支持也促使越来越多的库优先使用 Kotlin 开发，这不仅使得 LeakCanary 的代码更加简洁、高效，也有利于与其他基于 Kotlin 的库和框架进行集成。

内存优化与解析库切换

在处理堆转储（Heap Dump）文件时，LeakCanary 进行了重要的优化。之前它使用 Haha 库对 dump 文件进行解析，而 Haha 是基于 Android Studio 中的 perflib 开发的。然而，这种方式存在一些性能问题，例如一个 160M 的 Heap dump 文件在 Android Studio 中打开需要使用 2G 的内存。为了解决这个问题，LeakCanary 引入了 Shark 库，使用 Shark 解析 dump 文件仅需要 40Mb 内存，大大提高了内存使用效率和解析速度，提升了整个内存泄漏监控系统的性能和可用性。

面临的挑战与发展方向

尽管 LeakCanary 在不断发展和优化，但使用新的语言（Kotlin）和技术也带来了一些新的问题。例如，由于 Kotlin 语言的特性和生态相对较新，在开发过程中必然会遇到一些不稳定问题需要解决。此外，随着 Android SDK 的不断更新，LeakCanary 需要持续适配新的 API 和功能变化，同时也要不断扩展其功能，以覆盖越来越多的内存泄漏场景，确保在不同的 Android 设备和应用环境下都能准确、高效地监控内存泄漏情况。

总结

为什么注册时的参数是application

为了全面且有效地监控 Activity 和 Fragment 的生命周期。

Application 在 Android 应用中具有全局唯一性和长生命周期的特性。它的生命周期贯穿整个应用的运行过程，从应用启动到关闭。通过以 Application 作为注册点，能够在应用的最顶层建立起一个统一的监控入口。

确保对所有 Activity 的生命周期事件进行捕获，无论这些 Activity 在何时被创建、销毁或经历其他状态变化。例如，在 Application 的 onCreate 方法中注册相关的生命周期回调，就可以最早开始对后续创建的 Activity 进行监控准备。

对于 Fragment 的监控而言，由于 Fragment 是依托于 Activity 存在的，通过 Application 对 Activity 的生命周期监控，能够在 Activity 的生命周期回调方法中进一步嵌入对其内部 Fragment 的监控逻辑。这种层级式的监控结构，以 Application 为核心枢纽，使得整个应用内的 Activity 和 Fragment 生命周期都能被纳入到内存泄漏监控的视野范围内，为及时发现可能存在的内存泄漏风险提供了全面的数据基础。

怎么监听

通过调用 Application 的 registerActivityLifecycleCallbacks 方法，并传入一个实现了 ActivityLifecycleCallbacks 接口的实例作为参数，就相当于注册了一组针对 Activity 生命周期各个阶段的 Callback 函数。

这个接口定义了多个方法，如 onActivityCreated、onActivityDestroyed 等，分别对应 Activity 的不同生命周期事件。

当这些事件在应用运行过程中发生时，系统会自动调用注册的 Callback 函数实例中的相应方法。

在这些方法内部，可以编写代码来执行与内存泄漏监控相关的操作，例如记录 Activity 的创建和销毁时间、检查其相关资源的引用情况等。

监听 Fragment 的具体策略

采用了 adapter 设计模式，构建了一种适配机制，使得 Fragment 的生命周期能够与 Activity 的生命周期监控体系相融合。

在 Activity 的 onCreate 方法中，这是一个关键的切入点。因为 onCreate 方法在 Activity 初始化过程中较早被调用，此时可以对该 Activity 后续可能涉及的 Fragment 进行预先的监控设置。具体而言，会创建一个专门用于监听 Fragment 生命周期的 FragmentLifecycleCallbacks 实例，并将其注册到 Activity 的 FragmentManager 上。这个 FragmentLifecycleCallbacks 实例就像是一个桥梁，它能够接收到 Fragment 的各种生命周期事件通知，如 onFragmentCreated、onFragmentDestroyed 等。

全局只会有一个FragmentManager

当 Fragment 的生命周期事件发生时，FragmentLifecycleCallbacks 中的相应方法会被触发。在这些方法内部，可以将 Fragment 的生命周期信息进行记录和处理，以适配到整个基于 Activity 生命周期监控的内存泄漏监控框架中。

例如，记录 Fragment 的创建和销毁信息，分析其与所属 Activity 以及其他相关对象之间的引用关系，判断在 Fragment 生命周期结束后是否存在不合理的引用导致其无法被垃圾回收，从而及时发现可能存在的内存泄漏隐患。