总结
主要原因:是当一个对象处于可以被回收状态时,却因为该对象被其他暂时不可被回收的对象持有引用,而导致不能被回收,如此一来,该对象所占用的内存被回收以作他用,这部分内存就算是被泄露掉了。简单来说,就是该丢掉的垃圾还占着有用的空间没有被及时丢掉
如果某些单例需要使用到Context对象,推荐使用Application的context,不要使用Activity的context,否则容易导致内存泄露。单例对象的生命周期和Application一致,这样Application和单例对象就一起销毁。
优先使用静态内部类而不是非静态的,因为非静态内部类持有外部类引用可能导致垃圾回收失败。如果你的静态内部类需要宿主Activity的引用来执行某些东西,你要将这个引用封装在一个WeakReference中,避免意外导致Activity泄露,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,都会回收 只被弱引用关联 的对象,只被 说明这个对象本身已经没有用处了。、
对了dialog的处理,dialog引起的内存泄漏主要是由于,dialog还在显示,但是宿主的activity已经被杀,导致dialog没有载体。解决的办法就是在ac被杀或者执行onpause函数时判断dialog不为null就关闭。在横竖屏切换时,因为会重走整个生命周期,所有也是内存泄漏的高发地。
Rxjava及eventBus等监听者模式,需要在ca销毁的时间取消订阅,也可以用Rxlifecycle绑定生命周期,一键解决内存泄漏
5.广播类导致的内存泄漏,注册广播之后需要反注册,不然会引发内存泄漏
6.handler,声明handler最好声明成静态内部类,同时持有外部Activity的弱引用。这样就不会出现ac已经死掉了,handler还在发送消息的情况,但是最好的操作是在ondetory是执行handler.removeCallbacksAndMessages(null);关闭所有的消息通知。