【App】内存泄漏

GCRoots

GCRoots：

1.虚拟机栈（栈帧中的本地变量表）中引用的对象；
2.方法区中的类静态属性引用的对象；
3.方法区中常量引用的对象；
4.本地方法栈中JNI（即一般说的Native方法）中引用的对象

JVM GC模型

标记/清除算法、复制算法、标记/整理算法
jvm采用分代收集算法对不同区域采用不同的回收算法。
新生代：采用复制算法（比较适合用于存活率低的内存区域），分为一块Eden空间和From Survivor、To Survivor，8：1：1；年龄值达到年龄阈值，移到老年代；
老年代：标记/清除算法或标记/整理算法（存活率高，没有额外空间给他做担保）；

可达性分析

可达性分析算法的弊端：
1.如果方法区几百兆，一个个检查里面的引用，将耗费大量资源
2.在分析时，需保证这个对象引用关系不再变化，否则结果将不准确
OopMap: 记录栈上本地变量到堆上对象的引用关系；safepoint安全点的时候更新OopMap数据，枚举根节点时，递归遍历每个栈帧的OopMap，就可以找到所有的GCRoots。OopMap可以避免全栈扫描，加快枚举根节点的速度，可以帮助HotSpot实现准确式GC。
安全点：
1:循环的末尾
2:方法临返回前/调用方法的call指令后
3:可能抛异常的位置
RememberedSet

LeakCanary 使用

LeakCanary初始化

用过LeakCanary1.x的同学一定知道，过去LeakCanary初始化的时候都是需要在Application中调用LeakCanary.install()进行注册的，升级到2.0之后连注册的代码都省了。

AppWatcher.java
1、AppWatcher#manualInstall()会在主进程中自动被AppWatcherInstaller调用；
2、AppWatcherInstaller会在AndroidManifest.xml中被注册；
3、如果要在非主进程监听内存泄漏，需要手动调用AppWatcher#manualInstall()方法；
既然这个AppWatcherInstaller会在AndroidManifest.xml中被注册，那么它一定是四大组件之一，其实AppWatcherInstaller就是ContentProvider的子类。

APP构建经过 manifest-merge 后会合并多个清单⽂件，这个 ContentProvider 会被合并到唯⼀的manifest.xml中. 当APP初始化时会加载这个 LeakSentryInstaller ,就会⾃动帮我们执⾏ InternalLeakSentry.install(application)

检测内存泄漏

InternalAppWatcher.java
这个⽅法中⽐较关键的就是 ActivityDestroyWatcher#install() 和FragmentDestroyWatcher#install() ，

ObjectWatcher.java
源码看到⽬前为⽌，⼩结⼀下其实就是 Activity 会在 onDestory() 之后，调⽤下⾯的ObjectWatcher#watch() ，这个⽅法⽐较关键，不仅仅可以检测Activity的内存泄漏，还可以通过这个⽅法检测任何对象的内存泄漏

思考1：如何判断⼀个对象是否被回收？
如果⼀个对象除了弱引⽤以外，没有被其他对象所引⽤，当发⽣GC时，这个弱引⽤对象就会被回收，并且被回收掉的对象会被存放到ReferenceQueue中，所以当ReferenceQueue中有这个对象就代表这个对象已经被回收，反之就是没有被回收；
思考2: 这⾥为什么要延迟五秒执⾏任务
我们都知道GC不是即时的, ⻚⾯销毁后预留5秒的时间给GC操作, 再后续分析引⽤泄露,避免⽆效的分析

⽣成heap dump ⽂件

AndroidHeapDumper.java
这个过程主要就是两步
1.发送通知
2.使⽤ Debug.dumpHprofData(heapDumpFile.absolutePath) 捕获堆转储

分析 heap dump ⽂件

最后启动⼀个前台服务 HeapAnalyzerService 来分析 heap dump ⽂件。然后通过解析库找到
最短 GC Roots 引⽤路径，展示给⽤户