Andfroid 内存溢出与内存泄漏的简单分析与解决

<一>内存溢出与内存泄露

首先我们要知道内存溢出与内存泄露的概念，什么是内存溢出和内存泄露。
内存溢出：就想杯子里得水满了，就溢出了。内存溢出就是分配的内存被用光了，不够用了。
内存泄露：就如同杯子里面有石子，导致杯子里面的一部分空间没有被利用，在APP中内存泄露就是指该被回收的内存没有被回收，导致一部分内存一直被占着，可利用内存变少了。当泄露过多 时，可利用的内存越来越少，就会引起内存溢出了。

<二> 查找内存泄露与内存溢出

(1) 内存溢出，最明显的地方就是报错，APP奔溃并报outofMemory内存溢出多数在处理图片比如操作BitMap时出现。
(2)因为内存泄露导致内存溢出，那就要去找内存泄露的地方。

内存分析工具：MAT和LeackCanary。

MAT：Memory Analysis Tools 是一个分析 Java堆数据的专业工具，用它可以定位内存泄漏的原因，但是这个是Eclipse的一个插件，现在大多数人基本都用的是Androidstudio开发工具，所以不能直接使用，虽然不能直接使用但是还是可以用的，下文会讲到具体的使用方法。
工具地址：https://www.eclipse.org/mat/

LeackCanary：是Square(square好像给我们弄了好多东西)专门为android弄的，检测泄露的工具；

工具地址：https://github.com/square/leakcanary
中文翻译：http://www.jianshu.com/p/7db231163168

在Androidstudio 下使用MAT比较麻烦，不能像eclipse下直接使用。但是这个工具可以单独使用。如果有兴趣的同学可以按照这个帖子去操作http://blog.csdn.net/enjoy517905407/article/details/50070115
下生成.hprof文件，通过sdk提供的hprof-conv的文件转换一下，使用MAT工具打开就可以更直观的看到堆的使用情况，以及涉及到泄露的地方都有提示。

但是LeackCanary就比较简单了，直接在项目的build.gradle中添加一下以来就可以了，

 debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.5‘
 releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5‘
 testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.5‘

编译完成，运行程序在你的项目旁边就会出现一个名叫Leaks的app，icon是黄色的盾牌一个感叹号，上图看看。

当你在玩你的app时出现内存泄露的情况就会出现通知栏具体，查看具体内容如图：

如上图所示：因为TestDataMode里的sinstance最终持有了TestActivity，使得TestActivity无法被释放，导致了内存泄露。

举几个我的项目当中出现的几个例子：

第一个是在别的activity中使用了监听回调，在MainActiviy实现接口重写方法，使用了一个静态的mainactiviy导致了MainActiviy无法释放回收。

这个是使用了匿名内部类导致newChatActivity无法被释放。

这个的解决方法是用静态内部类+弱引用解决的

    private static class AudioStageListener implements AudioManager.AudioStageListener{
        private final WeakReference<AudioRecordView> mAudioRecordViewWeak;

        private AudioStageListener(AudioRecordView mAudioRecordViewWeak) {
            this.mAudioRecordViewWeak = new  WeakReference<AudioRecordView>(mAudioRecordViewWeak);
        }
        @Override
        public void wellPrepared() {
            AudioRecordView audioRecordView = mAudioRecordViewWeak == null ? null : mAudioRecordViewWeak.get();
            if(audioRecordView!=null){
                mhandler.sendEmptyMessage(MSG_AUDIO_PREPARED);
            }
        }
    }

这个是一个图片下载的的要传入向上下文环境，没注意传了Activity，当图片没下载完退出Activiy，导致activity被引用无法释放。

这个的解决方法是在单例获取对象时获取全局的Application，即便是在图片未下载完成时，退出activity时也将图片下载下来缓存，但是会浪费一些流量。

    public static DataTransfer getDataTransferInstance(Context context) {
        MInstance.DATATRANSFER.mContext = context.getApplicationContext();
        return MInstance.DATATRANSFER;
    }

大概总结一下在APP常见的内存泄露以及解决方法：

1非静态内部类，静态实例化

例如：

/**
 * 自定义实现的Activity
 */
public class MyActivity extends AppCompatActivity {
    /**
     * 静态成员变量
     */
    public static InnerClass innerClass = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_my);

        innerClass = new InnerClass();
    }

    class InnerClass {

        public void doSomeThing() {
        }
    }
}

这里内部类InnerClass隐式的持有外部类MyActivity的引用，而在MyActivity的onCreate方法中调用了
innerClass = new InnerClass();

这样innerClass就会在MyActivity创建的时候是有了他的引用，而innerClass是静态类型的不会被垃圾回收，MyActivity在执行onDestory方法的时候由于被innerClass持有了引用而无法被回收，所以这样MyActivity就总是被innerClass持有而无法回收造成内存泄露。

2不正确的使用Context对象造成内存泄漏

/**
 * 自定义单例对象
 */
public class Single {
    private static Single instance;
    private Context context;
    private Object obj = new Object();

    private Single(Context context) {
        this.context = context;
    }

    /**
     * 初始化获取单例对象
     */
    public static Single getInstance(Context context) {
        if (instance == null) {
            synchronized(obj) {
                if (instance == null) {
                    instance = new Single(context);
                }
            }
        }
        return instance;
    }
}

解决方法：使用全局的的Context或者context.getApplication()；

3 使用Handler异步消息通信

在日常开发中我们通常都是这样定义Handler对象：

/**
 * 定义Handler成员变量
 */
Handler handler = new Handler() {  
        @Override  
        public void handleMessage(Message msg) {  
            dosomething();  

        }  
    };

但是这样也存在着一个隐藏的问题：在Activity中使用Handler创建匿名内部类会隐式的持有外部Activity对象的引用，当子线程使用Handler暂时无法完成异步任务时，handler对象无法销毁，同时由于隐式的持有activity对象的引用，造成activity对象以及相关的组件与资源文件同样无法销毁，造成内存泄露。我们普通的Handler，平时使用时也是可以不用考虑这些的，但是当你在子线程中有耗时操作通知UI时，要考虑到这一点，以免activity结束时子线程持有Handler对象，导致Activity无法被释放。

解决方法：

1）使用静态变量定义handler

static Handler handler = new Handler() {  

        @Override  
        public void handleMessage(Message msg) {  
            dosomething();  

        }  
    };  

这样的话，handler对象由于是静态类型无法持有外部activity的引用，但是这样Handler不再持有外部类的引用，导致程序不允许在Handler中操作activity中的对象了，这时候我们需要在Handler对象中增加一个队activity的弱引用；

static class MyHandler extends Handler {  
    WeakReference<Activity > mActivityReference;  
    MyHandler(Activity activity) {  
        mActivityReference= new WeakReference<Activity>(activity);  
    }  
    @Override  
    public void handleMessage(Message msg) {  
        final Activity activity = mActivityReference.get();  
        if (activity != null) {  
            mImageView.setImageBitmap(mBitmap);  
        }  
    }  
}  

最后在ondestory方法中将后面的消息移除

mhanHandler.removeCallbacksAndMessages(null);

弱引用相关的知识可参考：http://blog.csdn.net/qq_23547831/article/details/46505287

2）通过代码逻辑判断

在activity执行onDestory时，判断是否有handler已经执行完成，否则做相关逻辑操作；

4 使用了属性动画或循环动画

在Activity中使用了属性循环动画，在onDestroy()方法中未正确停止动画

5 使用资源文件结束之后未关闭

在使用一些资源性对象比如(Cursor，File，Stream，ContentProvider等)往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于Java虚拟机内，还存在于Java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露。

6 Bitmap使用不当

bitmap对象使用的内存较大，当我们不再使用Bitmap对象的时候一定要执行recycler方法，这里需要指出的是当我们在代码中执行recycler方法，Bitmap并不会被立即释放掉，其只是通知虚拟机该Bitmap可以被recycler了。

当然了现在项目中使用的一些图片库已经帮我们对图片资源做了很好的优化缓存工作，是我们省去了这些操作。

7 一些框架使用了注册方法而未反注册

比如我们时常使用的事件总线框架-EventBus，当我们需要注册某个Activity时需要在onCreate中：

EventBus.getDefault().register(this);

然后这样之后就没有其他操作的话就会出现内存泄露的情况，因为EventBus对象会是有该Activity的引用，即使执行了改Activity的onDestory方法，由于被EventBus隐式的持有了该对象的引用，造成其无法被回收，这时候我们需要在onDestory方法中执行：

EventBus.getDefault().unregister(this);

8 集合中的一些方法的错误使用

（1）比如List列表静态化，只是添加元素而不再使用时不清楚元素；
（2）map对象只是put，而无remove操作等等；