内存优化2- 内存泄露和内存抖动

内存泄露

产生的原因：一个长生命周期的对象持有一个短生命周期对象的引用
通俗讲就是该回收的对象，因为引用问题没有被回收，最终会产生OOM

内存抖动

内存频繁的分配与回收，（分配速度大于回收速度时）最终会产生OOM

使用工具分析内存泄露和抖动

常用的内存分析的工具：
Android Profiler
MAT
DDMS
top/procrank
meinfo
Procstats
Finder-Activity
LeakCanary
LeakInspector
工具很多，掌握原理方法，工具随便找两个能用就行，这里就不多做介绍了。

优化内存的良好编码习惯

1.不要使用比需求更占空间的基本数据类型

2.循环尽量用foreach,少用iterator, 自动装箱尽量少用

3.数据结构与算法的解度处理

数组，链表，栈，树，图。。。。。。
数据量千级以内可以使用 Sparse数组(key为整数)，ArrayMap（key为对象），性能不如HashMap但节约内存

4.枚举优化

每一个枚举值都是一个单例对象,在使用它时会增加额外的内存消耗,所以枚举相比与 Integer 和 String 会占用更多的内存,较多的使用 Enum 会增加 DEX 文件的大小,会造成运行时更多的IO开销,使我们的应用需要更多的空间,特别是分dex多的大型APP，枚举的初始化很容易导致ANR

5.static staticfinal的问题:

static会由编译器调用clinit方法进行初始化
static final不需要进行初始化工作，打包在dex文件中可以直接调用，并不会在类初始化申请内存
所以基本数据类型的成员，可以全写成static final

6.字符串的连接尽量少用加号(+)

7.重复申请内存的问题

同一个方法多次调用，如递归函数 ，回调函数中new对象,读流直接在循环中new对象等
不要在onMeause() onLayout() onDraw() 中去刷新UI（requestLayout）

8.避免GC回收将来要重用的对象

内存设计模式对象池+LRU算法

9.Activity组件泄漏

非业务需要不要把activity的上下文做参数传递，可以传递application的上下文
和Activity有关联的对象写成static 如private static Button btn; private static Drawable drawable
非静态内部类和匿名内部内会持有activity引用
单例模式持有activity引用
handler.postDelayed()问题

如果开启的线程需要传入参数，用弱引接收可解决问题
handler记得清除removeCallbacksAndMessages(null)

10.尽量使用IntentService,而不是Service