内存泄漏，这个名词很常见，那什么是内存泄漏呢？通俗易懂的来说 就是对象已经不需要被使用了，但是还没有被释放。
专业一点来说下安卓的泄漏，生命周期较长的对象持有生命周期较短的对象的引用。内存不在GC掌控之内了。当一个对象已经不需要再使用了，本该被回收时，而有另外一个正在使用的对象持有它的引用从而就导致，对象不能被回收。这种导致了本该被回收的对象不能被回收而停留在堆内存中，就产生了内存泄漏。
下面我们将从一个handler例子 来分析内存泄漏。
这是一个在Activity 中 handler发送一个延迟2s的消息，紧接着finish()界面，来模拟界面崩溃。看到这里，请大家闭上眼睛来思考一下，这个会不会造成内存泄漏？
好睁开眼，继续往下看，上面当做一个遗留问题 来思考。
先解释一下 最后一行 这个finish（），这里也是模拟界面崩溃的一个操作。解决内存泄漏 就是需要在程序正常运行和非正常运行时，保证内存的稳定，防止内存泄漏。
直入主题，下面带大家来看为啥会造成泄漏。
这是在追寻源码时，里面的一个死循环+一个锁。这两个东西 其实会带出很多的面试点 比如死循环为什么不会造成anr等。加锁之后 ，延迟发送的消息是否还准确等。这个如果大家感兴趣 以后我会再写一个专题 来详细翻源码来看具体原因。咱们继续：
咱们直入主题，handler.sendxx： MessageQueue.enqueueMessage()消息入队列
Thread -> Looper.loop()：MessageQueue.next() -> handler.dispatchMessage()消息出队列,从上面的源码中 我们看到了 有一句msg.target==null的判断。 这个target是啥呢？在学习的时候 大家可以思考下，下面给大家看一下源码。
没想到尽然是一个handler。那么现在内存泄漏就很明显 了。handler 是message 的成员变量。当我们使用handler的时候 handler里面未处理完的消息 还持有handler的引用。相信初级安卓开发的人员 都知道怎么去解决这个问题，调用他的移除消息方法，这是处理方式，如果别人问道原因和原理会一脸懵逼，或者会答handler持有外部类的引用，其实只是答对了一部分 或者也可以说根本没有答。最后来一笔画龙点睛的总结，为什么造成泄漏。Message 持有handler的引用，handler持有当前界面的引用，如果当前界面销毁 ，消息没有处理完 就造成了泄漏。
顺便带大家来了解一下总结LeakCanary的原理
leacCanary添加依赖不需要初始化，根据源码可知道会先走到contprovider 的onCreate（）方法，完成自动初始化。
1、LeakCanary只能检测Activity已经与Activity相关联的对象，通过注册生命周期。
2、它的实现是通过：
监听Activity的生命周期，在onDestroy时，去分析这个要销毁的Activity以及与的相关的对象是否存在内存泄漏
采用了弱引用和弱引用Queue的特性进行判断引用对象即Activity是否已经被回收，具体原理是: KeyedWeakReference继承了WeakReference，它也是弱引用的实现类，一般我们创建弱引用对象时都是只传与之关联的对象，这里还传递使用了一个WeakReferenceQueue，这个用来干嘛的？这个queue它的作用是用来存放已经被回收的弱引用对象，如果queue中有这个弱引用就代表这个弱引用所关联的对象已经被回收；而如果queue中没有这个弱引用对象则代表这个弱引用所关联的对象还没被回收，是存在内存泄漏的可能性。
如果GC之后引用对象还存活，那么通过Debug的dumpHprofData方法调用nativie方法让虚拟机去抓取堆内存快照（File heapDumpFile = heapDumper.dumpHeap();），根据堆内存快照文件的格式hprof协议、GC ROOT、GC引用链的原理进行解析、分析堆内存快照，heapdumpListener.analyze（。。。） 开启HeapAnalyzerService.class 服务，得到分析结果信息类，sendResultToListener，最后将这个分析结果发送给监听者，让结果监听者处理这个分析结果。将分析结果通过通知栏的方式显示出来，如果存在内存泄漏则当点击通知栏时会打开DispalyLeakActivity将内存泄漏的信息展示处理
面试核心流程。以上所有内容如有错误 欢迎大家指出。共同交流。
