Android内存泄漏相关

问题1 内存泄漏的基本定义是什么？内存泄漏有什么危害？
问题2 开发中常见的内存泄漏的情况有哪些？什么原因造成的？怎么解决
问题3 如何发现内存泄漏？LeakCanary的核心原理是什么？

什么是内存泄漏

当某个对象已经完成了它的使命退出，但是GC无法正常的回收内存空间，这种情况叫做内存泄漏。GC将GC Root和与GC Root（生命周期很长）相连的对象对标记为不可回收，那么如果某个对象完成了使命但是依然能和GC Root相连那么它必然造成内存泄漏，另外即便对象A不是GC Root如果它持有对象B且A生命周期比B要长也还是会造成内存泄漏，所以内存泄漏其实就是生命周期长的对象持有生命周期短的对象，导致后者在前者回收前无法被GC回收。

内存泄漏的例子

1 Handler造成的内存泄漏

一般Handler会被定义成匿名内部类，内部类会持有外部类的强引用。如果将Handler写在Activity中Handler就会持有Activity的引用，根据Handler机制我们可以打出如下引用链：Activity->Handler->Message->MessageQueue->Looper->ThreadLocal->Thread，而Thread是GC Root。如果MessageQueue中还有Message对象那么必然会造成Activity退出时候内存泄漏

解决方案：将Handler定义成静态内部类这样Handler不会持有Activity的强引用，然后Handler使用若引用持有Activity方便回调，当activity退出触发GC由于若引用特性activity能正常回收

2 Toast造成内存泄漏

如果Toast传的Context是Activity那么当Activity退出时候会造成内存泄漏。

解决方案：使用Application

3 集合造成的内存泄漏
类似HashMap、HashSet不要修改参与计算过的key的hash，如果修改了会导致get、remove等操作没法获取这个值，它会一直存在map中导致内存泄漏，如果是static的那就跟严重了

解决方案：一般人也不会这么傻

4 单例造成的内存泄漏

一些不好的单例模式可能会造成内存泄漏，例如必须要使用Context创建的对象。由于单例模式的唯一的一个变量一般都是static的，所以静态变量持有Context，如果这个Context是Activity的话就会造成内存泄漏。引用链：Context-> static，static的变量是GC Root

解决方案：一般不建议这么写，如果非要传Context可以使用Application最好，如果不行就使用若引用

5 WebView造成的内存泄漏

WebView内部一些线程会持有Activity，导致Activity无法释放。引用链是 Activity-> Thread

解决方案：将WebView放到一个单独的进程中，即可解决问题

6 线程造成内存泄漏

有时候我们为了方便在Activity内部用内部类的形式定义一个线程，因为内部类会持有外部类的引用，那么当线程的任务没有做完的时候退出Activity必然会造成内存泄漏。引用链是Activity-> Thread而Thread是GC Root

解决方案：使用其他的方法代替直接使用现场的方式，如使用RxJava、AsyncTask等等。或者和Handler处理方法类似使用WeakReference来持有Activity

LeakCanary的核心原理

LeakCanary的核心原理，大致上可以分为三步：
1 LeakCanary监听Activity的生命周期的最后一个onDestory
2 将Activity封装到KeyedWeakReference，这是继承WeakReference的所以是弱引用，它和ReferenceQueue结合起来一起使用。当GC能正常回收Activity就把持有Activity的弱引用放到引用队列里面，这样后面只需要检查引用队列里面是否有该Activity的弱引用就能判断是否内存泄漏。如果有就表示Activity被正常回收，如果没有就表示有可能内存泄漏，值得注意的是这时候LeakCanary还会帮我们主动GC一次，然后再次判断发现Activity还是没有被回收则开始拿heapDump文件开始分析
3 将heapDumpFile打包成HeapDump对象，然后调用analyze方法开始分析，ServiceHeapDumpListener是对应的实现。真正的分析交给HeapAnalyzerService这个服务去做的
4 通过HeapAnalyzerService发送前台通知
详情具体看后面文章《LeakCanary原理分析》