一、垃圾回收
一般来说，程序使用内存遵循先向操作系统申请一块内存，使用内存，使用完毕之后释放内存归还给操作系统。然而在传统的C/C++等要求显式释放内存的编程语言中，在合适的时候释放内存是一个很有难度的工作，因此Java等编程语言都提供了基于垃圾回收算法的内存管理机制。
常见的垃圾回收算法有引用计数算法（Reference Counting）、标注—清除算法（Mark and Sweep GC）、复制算法（Copying GC）和逐代回收（Generational GC）等算法，其中Android虚拟机采用的是标注—清除算法，并不是大多数JVM实现里采用的逐代回收算法。
二、几个基本概念
内存泄露：程序在向系统申请分配内存空间后(new)，在使用完毕后未释放，结果导致不再使用的对象一直占据该内存单元，或者他们占用的内存没有及时得到释放，从而造成内存空间不断减少的现象。由于Android程序可以使用的内存较少，发生内存泄漏会导致内存更加紧张，甚至最终由于内存耗尽而发生OOM（out of memeroy）错误，导致应用崩溃。
内存溢出：程序向系统申请的内存空间超出了系统能给的。比如内存只能分配一个int类型，我却要塞给他一个long类型，系统就出现oom。
强引用：强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。 当内存空间不足，Java虚拟机宁愿抛出OOM（OutOfMemoryError）错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
软引用：如果一个对象只具有软引用，但内存空间足够时，垃圾回收器就不会回收它；直到虚拟机报告内存不够时才会回收， 只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。 软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
弱引用：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间是否足够，都会回收它的内存。 不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
虚引用：虚引用可以理解为虚设的引用，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。 虚引用主要用来跟踪对象被垃圾回收器回收的活动。 虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。 当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。 程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。 如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
三、Android内存泄漏存在的原因
1.静态变量导致的内存泄漏
public class MainActivity extends AppCompatActivity {
private static final String TAG = "MainActivity";
private static View mView;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate (savedInstanceState);
setContentView (R.layout.activity_main);
mView = new View (this);
}
}
上面这段代码就会产生内存泄漏，mView是静态变量，它的内部持有当前的activity，因此Activity仍然无法释放。
2.单例模式导致的内存泄漏
不合理的单例模式也会引起内存泄漏，
public class LeakTest {
private static LeakTest mInstance;
private LeakTest(Context context) {
}
/**
* 单例模式
*/
public static LeakTest getInstance(Context context) {
if(mInstance == null) {
mInstance = new LeakTest (context);
}
return mInstance;
}
}
比如以上代码是一个提供单例的测试类，需要传入一个Contex进行获取，在Activity中使用的时候如果传入了改Activity的Context，当Activity不再使用的时候，如果在onDestroy时不进行操作，就会造成静态的单例变量一直引用这个Context，导致本该释放内存的变量一直占用内存造成内存泄漏。要解决这种类型的内存泄漏可以在引用Activity的Context时变成引用Application的Context。
3.属性动画导致内存泄漏
属性动画中有一类无限循环的动画，如果在Activity中播放此类动画但是没有在onDestroy中去停止动画，那么动画就会一直播放，尽管在当前界面以及看不到动画了。这个时候Activity的View会被动画持有，View又持有这个Activity，最终导致Activity无法释放，造成内存泄漏。解决方法是在onDestroy的时候调用animator.cancle()方法来停止动画。
4.其他原因导致的内存泄漏
- 资源对象没关闭造成的内存泄漏，如查询数据库后没有关闭游标cursor
- 构造Adapter时，没有使用 convertView 重用
- Bitmap对象不再使用时，没有调用recycle()释放内存
- 对象被生命周期长的对象引用，如activity被静态变量引用导致activity不能释放，因为静态类生命周期比Activity长。
- 想暂时规避内存泄漏问题,可以在manifest.xml加入：
android:largeHeap="true"
此时heapsize会增大2-3倍，缓解OOM的发生
其他内存泄漏的原因参考：https://blog.csdn.net/cyq1028/article/details/19980369
四、内存泄漏的排查
1.LeakCanary
A memory leak detection library for Android and Java.
LeakCanary的工作机制：
RefWatcher.watch()创建一个 KeyedWeakReference 到要被监控的对象。然后在后台线程检查引用是否被清除，如果没有，调用GC。
如果引用还是未被清除，把 heap 内存 dump 到 APP 对应的文件系统中的一个
.hprof文件中。在另外一个进程中的
HeapAnalyzerService有一个HeapAnalyzer使用HAHA 解析这个文件。得益于唯一的 reference key,
HeapAnalyzer找到KeyedWeakReference，定位内存泄露。HeapAnalyzer计算 到 GC roots 的最短强引用路径，并确定是否是泄露。如果是的话，建立导致泄露的引用链。引用链传递到 APP 进程中的
DisplayLeakService， 并以通知的形式展示出来。
LeakCanary的使用
1.添加依赖
dependencies {
debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.6.2'
releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.2'
// Optional, if you use support library fragments:
debugImplementation 'com.squareup.leakcanary:leakcanary-support-fragment:1.6.2'
}
2.新建一个Application类，用于使用LeakCanary
public class ExampleApplication extends Application {
public static RefWatcher getRefWatcher(Context context) {
ExampleApplication application = (ExampleApplication) context.getApplicationContext();
return application.refWatcher;
}
private RefWatcher refWatcher;
@Override public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
// Normal app init code...
}
}
LeakCanary.install() 会返回一个预定义的 RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控调用 Activity.onDestroy() 之后泄露的 activity,LeakCanary自动监控Activity，如果要在Fragment中使用LeakCanary需要在onDestroy方法中进行监控。
public abstract class BaseFragment extends Fragment {
@Override public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(this);
}
}
只要继承自基类的Fragment都会被监控内存泄漏的情况。
3.LeakCanary的自定义和其他操作参考
https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/
