内存泄露和内存溢出

内存溢出是对象的内存超出了分配的空间的大小

内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

内存溢出的原因是由于内存泄露导致

  内存泄露是长时间保持某些资源的引用 垃圾回收器无法回收他 该对象占用的内存也无法使用

就造成了内存泄露

Android 中常见就是Activity被引用在调用finish之后却没有释放，第二次打开activity又重新创建，这样的内存泄露不断的发生,则会导致内存的溢出

内存溢出的原因

1、 内存泄露导致内存溢出

2、占用内存较多的对象

保存了多个耗用内存过大的对象（如Bitmap）或加载单个超大的图片，造成内存超出限制。

内存泄漏的原因

比如当你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。
1.资源对象没关闭

如Cursor，File等资源。他们会在finalize中关闭，但这样效率太低。容易造成内存泄漏
SQLiteCurost,当数据量大的时候容易泄漏

2.使用Adapter时，没有使用系统缓存的converView
3.没有即时调用recycle()释放不再使用的bitmap
4.使用application的context来替代activity相关的context

不要让生命周期长于Activity的对象持有到Activity的引用

5.广播注册没取消造成内存泄露
6.Handler应该申明为静态对象， 并在其内部类中保存一个对外部类的弱引用。

内存泄漏检测工具

Handler内存溢出

因为handler在使用的时候是在activity中作为一个内部类使用的 如果activity意外关闭的时候 handler中还有没被处理的消息

这个时候handler就一直持有activty的引用 会导致内存泄露

解决方法

将handler定义成为静态的成员变量    定义一个弱引用对象保持对外部类的引用

mvp造成的内存泄露

因为p层一直持有activity的引用所以当activity意外关闭的时候 p层如果还没有处理完数据的话 也会一直持有activity的引用

所以要在p层创建activity的弱引用对象当创建时关联  activity销毁的时候将p层的对象置为空

Rxjava造成的内存泄露

.使用取消订阅管理器：CompositeSubscription,让CompositeSubscription持有所有的请求。统一取消。

        this.msubscription.add(i);//把订阅加入管理集合中

http://blog.csdn.net/zr940326/article/details/51550002

  //在activity结束生命周期的时候取消订阅，解除对context的引用

静态引起的内存泄露

假如在我们的一个Activity中有一个静态的public属性持有这个Activity的引用，而在另一个对象中引用到了这个Activity中的静态属性，而当我们销毁这个Activity的时候，那么这个Activity就应该被GC回收掉，因为它已经没有使用价值了，但是由于另一个对象还在持有它的静态属性的引用。所以GC无法回收掉它，还在占用着内存空间导致内存空间变小，就会造成内存泄漏。
比如在一个Activity中的static属性是Context，而这个Context在这个Activity启动之后获取到这个Activity的引用，也就是context = this,那么在另一个对象中调用到了这个Activity中的Context，如果这个对象跟着这个Activity一起销毁的话还好，如果没有，那么在Activity销毁的时候，另一个对象就是还持有这个Activity的Context的引用，这样就会导致GC无法完全回收掉这个Activity。

单例模式引起的内存泄漏
首先单例模式的生命周期是和Application保持一致的，如果在我们的单例对象中，有一个类似于注册监听的方法，，那么让我们的Activity去实现这个监听的接口，然后向这个单例对象去注册监听，如果我们没有释放注册的方法的话，那么我们的这个单例对象会一直持有这个Activity的对象，因此Activty无法被及时的释放。