自从Google在2013年发布了Android Studio后，Android Studio凭借着自己良好的内存优化，酷炫的UI主题，强大的自动补全提示以及Gradle的编译支持正逐步取代Eclipse，成为主流的Android开发IDE。Android Studio在为我们提供了良好的编码体验的同时，也提供了许多对App性能分析的工具，让开发者可以更方便分析App性能。Google在IO大会上一直告诫开发者不要无节制的使用手机内存，要注意一些不良的开发习惯会导致App的内存泄漏。虽然如今网上检测App内存泄漏的文章汗牛充栋，但是要使用DDMS和MAT，不仅使用步骤复杂繁琐，而且要手动排查内存泄漏的位置，操作起来多有不便。其实Android Studio已经开始支持自动进行内存泄漏检查了，本文就带着大家一探其中的奥妙吧。

什么是内存泄漏
Android虚拟机的垃圾回收采用的是根搜索算法。GC会从根节点（GC Roots）开始对heap进行遍历。到最后，部分没有直接或者间接引用到GC Roots的就是需要回收的垃圾，会被GC回收掉。而内存泄漏出现的原因就是存在了无效的引用，导致本来需要被GC的对象没有被回收掉。

举个栗子

    private static Leak mLeak;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_second);
        mLeak = new Leak();
    }

    class Leak {
    }

mLeak是存储在静态区的静态变量，而Leak是内部类，其持有外部类Activity的引用。这样就导致Activity需要被销毁时，由于被mLeak所持有，所以系统不会对其进行GC，这样就造成了内存泄漏。

再举一个最常犯的栗子

public class Singleton {
    private static Singleton instance;
    private Context mContext;
    private Singleton(Context context){
        this.mContext = context;
    }

    public static Singleton getInstance(Context context){
        if (instance == null){
            synchronized (Singleton.class){
                if (instance == null){
                    instance = new Singleton(context);
                }
            }
        }
        return instance;
    }
}

如果我们在在调用Singleton的getInstance()方法时传入了Activity。那么当instance没有释放时，这个Activity会一直存在。因此造成内存泄露。
解决方法可以将new Singleton(context)改为new Singleton(context.getApplicationContext())即可，这样便和传入的Activity没关系了。

内存泄漏的检测
打开Android Studio，编译代码，在模拟器或者真机上运行App，然后点击，在Android Monitor下点击Monitor对应的Tab，进入如下界面

在Memory一栏中，可以观察不同时间App内存的动态使用情况，点击可以手动触发GC，点击可以进入HPROF Viewer界面，查看Java的Heap，如下图

Reference Tree代表指向该实例的引用，可以从这里面查看内存泄漏的原因，Shallow Size指的是该对象本身占用内存的大小，Retained Size代表该对象被释放后，垃圾回收器能回收的内存总和。
下面我们以掌上道聚城客户端为例，来一探内存泄漏检测的方法。
打开Android Studio，编译代码，运行掌上道聚城，然后开始尽情的耍我们的App啦，然后就从Memory Monitor里面观察App的内存使用曲线，突然发现，纳尼！！！怎么内存使用越来越大了，这就很有可能是发生内存泄漏了，然后点击手动进行GC，再点击观看JavaHeap，点击Analyzer Task，Android Monitor就可以为我们自动分析泄漏的Activity啦，分析出来如下图所示

public static VideoTagHelper getInstance(Context context) {
        if (tagHelper == null) {
            tagHelper = new VideoTagHelper();
        }
        tagHelper.context = context;
        return tagHelper;
    }

和刚刚举得栗子里出现的错误一模一样啊，这段代码是谁写的，拖出去······
我们修复了检查出的内存泄漏的问题，并将修复前和修复后的代码在相同的模拟器上运行并进行相同的操作，查看他们使用内存的情况，如下图所示

在修复了内存泄漏问题后，内存使用下降了16.3%！！！

内存泄漏产生的原因在Android中大致分为以下几种：

1.static变量引起的内存泄漏 
因为static变量的生命周期是在类加载时开始 类卸载时结束，也就是说static变量是在程序进程死亡时才释放，如果在static变量中 引用了Activity 那么 这个Activity由于被引用，便会随static变量的生命周期一样，一直无法被释放，造成内存泄漏。

解决办法： 
在Activity被静态变量引用时，使用 getApplicationContext 因为Application生命周期从程序开始到结束，和static变量的一样。

2.线程造成的内存泄漏 
类似于上述例子中的情况，线程执行时间很长，及时Activity跳出还会执行，因为线程或者Runnable是Acticvity内部类，因此握有Activity的实例(因为创建内部类必须依靠外部类)，因此造成Activity无法释放。 
AsyncTask 有线程池，问题更严重

解决办法： 
1.合理安排线程执行的时间，控制线程在Activity结束前结束。 
2.将内部类改为静态内部类，并使用弱引用WeakReference来保存Activity实例 因为弱引用 只要GC发现了 就会回收它 ，因此可尽快回收

3.BitMap占用过多内存 
bitmap的解析需要占用内存，但是内存只提供8M的空间给BitMap，如果图片过多，并且没有及时 recycle bitmap 那么就会造成内存溢出。

解决办法： 
及时recycle 压缩图片之后加载图片

4.资源未被及时关闭造成的内存泄漏 
比如一些Cursor 没有及时close 会保存有Activity的引用，导致内存泄漏

解决办法： 
在onDestory方法中及时 close即可

5.Handler的使用造成的内存泄漏 
由于在Handler的使用中，handler会发送message对象到 MessageQueue中 然后 Looper会轮询MessageQueue 然后取出Message执行，但是如果一个Message长时间没被取出执行，那么由于 Message中有 Handler的引用，而 Handler 一般来说也是内部类对象，Message引用 Handler ，Handler引用 Activity 这样 使得 Activity无法回收。

解决办法： 
依旧使用 静态内部类+弱引用的方式 可解决

6.带参数的单例

如果我们在在调用Singleton的getInstance()方法时传入了Activity。那么当instance没有释放时，这个Activity会一直存在。因此造成内存泄露。
解决方法：

可以将new Singleton(context)改为new Singleton(context.getApplicationContext())即可，这样便和传入的Activity没关系了。

基于Android Studio的内存泄漏检测与解决全攻略