内存优化
高炳秋
2017年7月
一、前言（问题提出）
为了提高app的稳定性，一旦发生内存泄露，久而久之，就会出现oom，进而导致crash。
二、gc
分类
1、内存泄露：对象已经不再使用了，但是无法被内存回收；
2、内存溢出：对象太多，无法被无法，超过大小限制。
对象已死判断方法
1.如果有个对象引用他，则加1，当方法介绍时，则减去1。
2.可达性分析。
从gc root开始，如果不存在任何强引用链相连，说明可回收
引用分类
1.强引用：如果没有其他说明，都是强引用；
2.软引用（SoftReference）：当内存不够时就回收
3.弱引用（WeakReference）：gc触发时，就回收
4.虚引用（WeakReference）：没用过
总结：一般都是强引用；如果担心对象发生内存泄露，就是使用弱引用，常见的有内部类等。
回收算法
1.标记-清除：判断对象是否已死，然后标记，逐个清除；
问题：产生了大量碎片，效率低
2.复制算法：把回收后还存活的对象复制到其他，然后清除剩下的；（分为eden：suivivor；8:1）复制到suivivor区；
3.标记-整理（老年代）：先1，然后整理
4.分代：根据不同的年代采取不同的算法
总结：一般都是强引用；如果担心对象发生内存泄露，就是使用弱引用，常见的有内部类等。
分代策略
1.优先eden
2.大对象老年代
3.长时间的老年代
Minor gc：老年代小于新生代的最大值；
Full gc：老年代小于每次新生代升级平均值；
三、总结及备注
大对象处于老年代容易内存泄露；
一般不要主动调用System.gc();cpu消耗极大
四、实践
判断一个对象是否会内存泄露，主要看谁引用（调用）了该对象；如果其中的一个调用类声明周期大于该对象就可能发生内存泄露；
五、常见情况：
Handle：handle作为内部类，会持有外部类的引用，一直异步任务执行较久甚至卡住，就是导致外部Activity或者Fragment无法释放。可以修改为static，使用软引用；
mvp中的内存问题：vp互相引用，会导致p执行就时，v层无法释放。可以在onDestroy中解除引用（mView置空）或者使用eventbus解耦。
bitmap太大：会直接导致内存溢出，可以从图片质量（质量压缩），大小减少（inSampleSize）和Build.config三个方面减少bitmap大小。对于不在使用的图片可以调用recycle()方法回收内存。
单例：单例里面的成员变量都是无法释放的，请注意成员变量的大小。（类似Activity，Fragment）
