|
标题：内存优化分为三部分 内存溢出->内存泄漏->内存抖动
一、内存泄漏
内存泄漏的本质原因：生命周期不一致
概念：
- 内存泄漏（Memory Leak）：当一个对象不在使用了，本应该被垃圾回收器（JVM）回收。但是这个对象由于被其他正在使用的对象所持有，造成无法被回收的结果。内存泄漏最终会导致内存溢出。
- 内存溢出（Out of Memory）：系统会给每个APP分配内存也就是Heap Size值。当APP占用的内存加上我们申请的内存资源超过了Dalvik虚拟机的最大内存时就会抛出的Out Of Memory异常。
- 内存抖动：在短时间内频繁的创建和销毁对象，会导致抖动现象。
- 强引用：当前内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不愿意回收来解决内存不足。
- 软引用：当前内存空间足够时，不回收，不足够时，开始回收。
- 弱引用：一旦发现有弱引用对象，不管当前内存够与不够都会回收。
- 虚引用：在任何情况下都会被回收。
1.单例内存泄漏
问题：创建单例的时候由于需要传入一个Context,如果Context是Activity的Context那么内存泄漏的问题就来了，当这个Activity关闭时这个单例还持有这个Activity的引用，导致这个Activity没有办法回收会导致内存泄漏的问题
解决方案：Context使用Application中的Context，这时Context的生命周期和Application的生命周期一样长，解决内存泄漏
2.Handler内存泄漏
问题：当A页面跳转到B页面时A页面会finish(关闭)，由于A页面的Handler对象为非静态匿名内部类对象，它自动会持有外部类的引用，从而导致无法回收造成内存泄漏。
解决方案：将Handler声明为静态内部类，就不会持有外部类引用，其生命周期就和外部类无关，如果Handler里面需要Context的话，可以通过弱引用的方式，避免内存泄漏，但是在Handler中还有一个问题就是在这个页面关闭时如果消息队列中还有待处理的消息时，要在Activity的生命周期onDestory中移除消息队列中的待处理消息。
3.MVP内存泄漏
在写MVP时Presenter作为Model和View的中间人，需要做一些比较耗时的操作，例如网络请求，如果Presenter在请求结束之前关闭Activity这时如果是强引用的话会导致Presenter会一直持有Activity的引用，导致Activity无法回收,从而发生内存泄漏。
解决方案：使用弱引用的方式写MVP，通过Activity、Fragment的生命周期来解决
检测内存泄漏的工具：LeakCanary检测内存泄漏，系统自带的一个检测工具
内存泄漏还有很多，以上是平常常见的，还有文件内容的读写如果不及时关闭流也会造成内存泄漏
二、内存溢出
堆溢出：
栈溢出：
方法区溢出：
|