小海编码日记

在从LeakCanary看内存快照生成一节中，我们已经了解了hprof的生成，并且将生成的hprof文件通过Android Studio进行解析，确实发现了内存泄漏对象MainActivity，但是在实际开发中，要求开发者自己去手动pull hprof文件进行解析，相对而言，操作是比较麻烦的，我们期望能通过代码分析出内存泄漏对象的引用链以提示开发者。在LeakCanary早起是通过库进行hprof文件解析的，随后在LeakCanary2.0之后迁移到。

前面我们已经完成了生命周期监控并且可以通过ReferenceQueue和WeakHashMap的比较确定哪些对象发生泄漏了，那么接下来需要考虑的就是如何确定这个对象是被谁持有导致泄漏的呢？从一文中可知，当我们使用Android Studio或MAT分析内存泄漏问题时，通常首先是需要抓取发生内存泄漏时的hprof文件，随后使用分析软件打开该文件，排查泄漏对象被持有的GC Roots，进而解决内存泄漏问题。

前面已经了解了Service，Fragment，ViewModel对象的销毁时机，那么在触发销毁时机后，我们怎么判断这些对象有没有回收呢？大家都知道在Java中有强引用，弱引用，软引用，虚引用四种引用方式，而我们判断对象是否回收，就需要通过弱引用来实现，针对弱引用而言。

在ViewModel机制中，主要包含ViewModelStore，ViewModelStoreOwner和ViewModelProvider这两个角色，其中ViewModelStoreOwner接口由持有ViewModelStore的类实现，ViewModelStore主要用于存储ViewModel对象，ViewModelProvider是一个工具类，用于构造ViewModel对象，同时在构造时会将构造的对象添加到ViewModelStore中。

前文中我们已经了解到LeakCanary中Service生命销毁的监听方式，那么Fragment的生命周期监听又是怎么实现的呢？Activity生命周期监听，在Application里面有ActivityLifecycleCallbacks，那么Fragment是否相似呢？

大家都知道使用LeakCanary可以监控项目中存在的问题，那么LeakCanary是怎么实现的呢？LeakCanary通过检测程序中对象的引用关系，收集应该被回收的对象并标记，随后等待GC后，检查该对象是否按预期回收即可，目前LeakCanary支持Service，Activity，Fragment，ViewModel以及View的泄漏检测，接下来我们一起来看下Service的关联部分。首先，我们考虑如果要认定一个Service对象可以被回收，前提条件是什么？