Android 内存优化

标题：内存优化分为三部分 内存溢出->内存泄漏->内存抖动 检测内存泄漏的工具：LeakCanary

一、内存泄漏

内存泄漏的本质原因：生命周期不一致

概念：

• 内存泄漏（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的生命周期来解决

4.广播、EventBus内存泄漏

解决方案：在Activity关闭时一定要及时注销广播否则会导致内存泄漏，EventBus和广播是一样的有注册，有注册必有注销，如有不注销的话就会导致一个资源浪费会产生内存泄漏的问题

5.文件流内存泄漏

解决方案：在进行文件读写的完毕时进行一个正确的关闭流操作，否则会导致内存泄漏

6.属性动画内存泄漏

动画同样是一个耗时任务，比如在Activity中启动了属性动画（ObjectAnimator），但是在销毁的时候，没有调用cancle方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去，动画引用所在的控件，所在的控件引用Activity，这就造成Activity无法正常释放。因此同样要在Activity销毁的时候cancel掉属性动画，避免发生内存泄漏。

二、内存溢出（OOM）

堆溢出：New对象过多导致GC机制没有及时回收
栈溢出：方法嵌套方法，每创建一个方法会产生一个栈帧，栈帧大于512个就会导致栈溢出
方法区溢出：方法区里存放一些类信息、常量、静态变量被所有线程共享内存不足导致方法区溢出

JVM内存模型：分为五种

方法区和堆是线程共享的，而其余的都是线程私有的

1. 方法区
2. 堆
3. 虚拟机栈
4. 本地方法栈
5. 程序计数器