当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。
内存泄漏是造成应用程序OOM的主要原因之一。我们知道Android系统为每个应用程序分配的内存是有限的，而当一个应用中产生的内存泄漏比较多时，这就难免会导致应用所需要的内存超过系统分配的内存限额，这就造成了内存溢出从而导致应用Crash。
因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。 1、MAT是一款强大的内存分析工具，功能繁多而复杂。 2、LeakCanary则是由Square开源的一款轻量级的第三方内存泄漏检测工具，当检测到程序中产生内存泄漏时，它将以最直观的方式告诉我们哪里产生了内存泄漏和导致谁泄漏了而不能被回收。
由于单例的静态特性使得其生命周期和应用的生命周期一样长，如果一个对象已经不再需要使用了，而单例对象还持有该对象的引用，就会使得该对象不能被正常回收，从而导致了内存泄漏。 示例：防止单例导致内存泄漏的实例
// 使用了单例模式 public class AppManager { private static AppManager instance; private Context context; private AppManager(Context context) { this.context = context; } public static AppManager getInstance(Context context) { if (instance != null) { instance = new AppManager(context); } return instance; } }这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。？？？
例如，有时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，可能会出现如下写法：
public class MainActivity extends AppCompatActivity { private static TestResource mResource = null; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); if(mResource == null){ mResource = new TestResource(); } //... } class TestResource { //... } }这样在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据。虽然这样避免了资源的重复创建，但是这种写法却会造成内存泄漏。因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，从而导致Activity的内存资源不能被正常回收。 解决方法：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。
示例：创建匿名内部类的静态对象
public class MainActivity extends AppCompatActivity { private final Handler handler = new Handler() { @Override public void handleMessage(Message msg) { // ... } }; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new Thread(new Runnable() { @Override public void run() { // ... handler.sendEmptyMessage(0x123); } }); } }1、从Android的角度 当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。另外，主线程的Looper对象会伴随该应用程序的整个生命周期。 2、 Java角度 在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。
对上述的示例进行分析，当MainActivity结束时，未处理的消息持有handler的引用，而handler又持有它所属的外部类也就是MainActivity的引用。这条引用关系会一直保持直到消息得到处理，这样阻止了MainActivity被垃圾回收器回收，从而造成了内存泄漏。 解决方法：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
示例：AsyncTask和Runnable
public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new Thread(new MyRunnable()).start(); new MyAsyncTask(this).execute(); } class MyAsyncTask extends AsyncTask<Void, Void, Void> { // ... public MyAsyncTask(Context context) { // ... } @Override protected Void doInBackground(Void... params) { // ... return null; } @Override protected void onPostExecute(Void aVoid) { // ... } } class MyRunnable implements Runnable { @Override public void run() { // ... } } }AsyncTask和Runnable都使用了匿名内部类，那么它们将持有其所在Activity的隐式引用。如果任务在Activity销毁之前还未完成，那么将导致Activity的内存资源无法被回收，从而造成内存泄漏。 解决方法：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。
1）比如在Activity中register了一个BraodcastReceiver，但在Activity结束后没有unregister该BraodcastReceiver。 2）资源性对象比如Cursor，Stream、File文件等往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null，而不关闭它们，往往会造成内存泄漏。 3）对于资源性对象在不使用的时候，应该调用它的close()函数将其关闭掉，然后再设置为null。在我们的程序退出时一定要确保我们的资源性对象已经关闭。 4）Bitmap对象不在使用时调用recycle()释放内存。2.3以后的bitmap应该是不需要手动recycle了，内存已经在java层了。
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的Item的View对象会被回收，然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的，getView()的第二个形参convertView就是被缓存起来的Item的View对象（初始化时缓存中没有View对象则convertView是null）。
构造Adapter时，没有使用缓存的convertView。 解决方法：在构造Adapter时，使用缓存的convertView。
我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。 解决方法：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其长期占用的内存也不能被回收，从而造成内存泄露。 解决方法：为WebView另外开启一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
1、在涉及使用Context时，对于生命周期比Activity长的对象应该使用Application的Context。凡是使用Context优先考虑Application的Context，当然它并不是万能的，对于有些地方则必须使用Activity的Context。对于Application，Service，Activity三者的Context的应用场景如下：
其中，NO1表示Application和Service可以启动一个Activity，不过需要创建一个新的task任务队列。而对于Dialog而言，只有在Activity中才能创建。除此之外三者都可以使用。
2、对于需要在静态内部类中使用非静态外部成员变量（如：Context、View )，可以在静态内部类中使用弱引用来引用外部类的变量来避免内存泄漏。 3、对于不再需要使用的对象，显示的将其赋值为null，比如使用完Bitmap后先调用recycle()，再赋为null。 4、保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。 5、对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏： 1）将内部类改为静态内部类 2）静态内部类中使用弱引用来引用外部类的成员变量
1、内存泄漏：
当出现对Activity、View或drawable等类的对象长期持有无用的引用，就会造成被引用的对象无法在GC时回收，而是长期占用堆空间，此时就会发生内存泄漏。 简单来说，就是保留下来却永远不再使用的对象引用。
2、内存溢出：
如果应用程序在消耗光了所有的可用堆空间(16M到48M），那么再试图在堆上分配新对象时就会引起OOM(Out Of Memory Error)异常，此时应用程序就会崩溃退出。
3、两者的区别：
简单的说，就是内存溢出是占用内存太大，超过了其可以承受的范围； 内存泄漏是回收不及时甚至是没有被回收，而在推空间中产生的许多无用的引用。 于是过多的内存泄漏就会导致内存溢出，从而迫使程序崩溃退出。
4、四种不同类型的引用：
引用名称
Strong Reference(强引用)
Soft Reference (软引用)
Weak Reference (弱引用)
Phantom Reference (虚引用)
引用特点
通常我们编写的代码都是Strong Ref，于此对应的是强可达性，只有去掉强可达，对象才被回收。
对应软可达性，只要有足够的内存，就一直保持对象，直到发现内存吃紧且没有Strong Ref时才回收对象。一般可用来实现缓存，
比Soft Ref更弱，当发现不存在Strong Ref时，立刻回收对象而不必等到内存吃紧的时候
根本不会在内存中保持任何对象，你只能使用Phantom Ref本身。一般用于在进入finalize()方法后进行特殊的清理过程
引用方式
通过java.lang.ref.
SoftReference类实现
通过java.lang.ref.WeakReference和java.util.WeakHashMap类实现
通过java.lang.ref.PhantomReference实现
5、持有Context引用造成的泄漏。
在Android应用程序中，很多操作都用到了Context对象，但是大多数都是用来加载和访问资源的。 这就是为什么所有的显示控件都需要一个Context对象作为构造方法的参数。 在Android应用程序中通常可以使用两种Context对象：Activity和Application。 当类或方法需要Context对象的时候常见的作法是使用第一个作为Context参数。 但这就意味着View对象对整个activity保持引用，因此也就保持对activity内的所有东西的引用， 也就是整个View结构和它所有的资源都无法被及时的回收，而且对activity的长期引用是比较隐蔽的。
当屏幕方向改变时，Android系统默认作法是会销毁当前的Activity，然后创建一个新的Activity，这个新的Activity会显示刚才的状态。 在这样做的过程中，Android系统会重新加载UI用到的资源。 现在假设的应用程序中有一个比较大的bitmap类型的图片，每次旋转时都重新加载图片所用的时间较多。 为了提高屏幕旋转时Activity的创建速度，最简单的方法是用静态变量的方法。
这样的代码执行起来是快速的，但同时是错误的：这样写会一直保持着对Activity的引用。 当一个Drawable对象附属于一个View时，这个View就相当于drawable对象的一个回调（引用）。 在上面的代码片段中，就意味着drawable和TextView存在着引用的关系， 而TextView自己持有了对Activity（Context对象）的引用，这个Activity又引用了相当多的东西。
有两种简单的方法可以避免由引用context对象造成的内存泄露。 首先第一个方法是避免context对象超出它的作用范围。 上面的例子展示了静态引用的情况，但是在类的内部，隐式的引用外部的类同样的危险。 第二种方法是，使用Application对象。这个context对象会随着应用程序的存在而存在，而不依赖于activity的生命周期。 如果你打算对context对象保持一个长期的引用，请记住这个application对象。 通过调用Context.getApplicationContext() 或者 Activity.getApplication().方法，你可以很容易的得到这个对象。 如果在activity中使用静态的类时如果需要引用activity,应该采用WeakReference弱引用来引用Activity。
总结一下避免Context泄漏应该注意的问题： 尽量使用Application这种Context类型，
注意对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字，Context里如果有线程，一定要在onDestroy()里及时停掉。 为了防止内存泄露，我们应该注意以下几点： （1）不要让生命周期长的对象引用activity context，即保证引用activity的对象要与activity本身生命周期是一样的. （2）对于生命周期长的对象，可以使用application context。 （3）避免非静态的内部类，尽量使用静态类，避免生命周期问题，注意内部类对外部对象引用导致的生命周期变化。
6、线程之间通过Handler通信引起的内存泄漏
Android中线程之间进行通信时最常用的作法是通过接收消息的目标线程所持有Handler对象来创建Message对象，然后再向目标线程发送该Message。 在目标线程中Handler在执行handleMessage()时会根据相应Message来执行相应不同功能。 另外一种作法是通过Handler对象向目标线程直接发送Runnable对象来执行该Runnable对象中不同的功能代码。 在通过Handler进行通信时如果不注意，也很有可能引起内存泄漏。
在sendMessage完成之后显示的将msg成员变量置为null，并且在退出整个应用程序之前，将handler置为null。
7、将变量的作用域设置为最小
最小化作用域意味着对垃圾收集器更快的可见。让我们举一个例子。 我们有一个变量定义在方法级,当方法执行完毕后,也就是说,控制跳出方法后,则该变 量将不会被引用。 这也就意味着它已经可以被垃圾回收。但是如果该变量是类级的,这时垃圾回收器就需要等待直到对该类的所有的引用都被移除后才能进行垃圾回收。 优化属性的作用域是必须的。同样这也是封装原则。最小化作用域降低了通过包访问变量并减少了耦合。
8、构造Adapter时，没有使用缓存的convertView。
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象 缓存起来。 当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。 这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。
由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话， 即浪费时间，也造 成内存垃圾，给垃圾回收增加压力，如果垃圾回收来不及的话，虚拟机将不得不给该应用进程分配更多的内存，造成不必要的内存开支。
9、Bitmap的回收和置空。 Bitmap 对象不在使用时调用 recycle()释放内存，有时我们会手工的操作 Bitmap 对象, 如果一个Bitmap 对象比较占内存, Bitmap对象在不使用时，我们应该先调用recycle()释放内存，然后才它设置为null。 虽然recycle()从源码上看，调用它应该能立即释放Bitmap的主要内存，但是测试结果显示它并没能立即释放内存。 但是我它应该还是能大大的加速Bitmap的主要内存的释放。
10、资源对象没关闭造成的内存泄露。
资源性对象比如（Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。 它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟机外。 如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。 因为有些资源 性对象，比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，它自己会调close()关闭）， 如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。 因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。 如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
11、各种注册没取消。
这种情况造成的内存泄露这种Android的内存泄露比纯java的内存泄露还要严重，因为其他一些Android程序可能引用我们的Anroid程序的对象（比如注册机制）。 即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android程序的某个对象的引用，泄露的内存依然不能被垃圾回收 。比如假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)， 则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。 对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。 但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。 如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。 虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。
12、集合容器对象没清理造成的内存泄露。
我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时， 并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。 所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
13、static关键字的滥用。
当类的成员变量声明成static后，它是属于类的而不是属于对象的， 如果我们将很大的资源对象（Bitmap，context等）声明成static，那么这些资源不会随着对象的回收而回收， 会一直存在，所以在使用static关键字定义成员变量的时候要慎重。
14、WebView对象没有销毁。
当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。
15、GridView的滥用。
GridView和ListView的实现方式不太一样。GridView的View不是即时创建的，而是全部保存在内存中的。 比如一个GridView有100项，虽然我们只能看到10项，但是其实整个100项都是在内存中的。 所以在应用程序退出之前，要讲gridView和adapter全部置为null。
