Android 防止OOM优化

1. Android2.x及以下的系统优化：

Bitmap被解码后的像素被存储在Native Heap中，

Dalvik Heap有个external计数，记录了Bitmap所占用的内存。

当 Dalvik Allocated + External Allocated + new Allocated>= 允许分配最大值时，就会引发OutOfMemoryError异常，

销毁的时候必须要调用recycle()。BitmapFactory.Options参数，隐藏了inNativeAlloc属性，

可以使Bitmap的内存不算在Dalvik Heap中。

2. Android 3.x及以上的系统优化：

Bitmap被解码后的像素被存储在Java Heap，只要Bitmap没有

被引用，在内存紧张时就会被回收，不需要主动调用recycle。只有当 Dalvik Allocated + new Allocated>= 允许分配最大值时，

就会引发OutOfMemoryError异常，BitmapFactory.Options参数，有个inPurgeable属性，开启后像素会存储在Native Heap中，

有个缺陷就是，在Bitmap显示时如何Native Heap中没有缓存，又需要重新解码，会阻塞UI线程。

可以在jni层通过AndroidBitmap_lockPixels把解码后的内存锁住，防止被回收，然后在不适用时通过AndroidBitmap_unlockPixels(env, zBitmap)

来取消加锁（可以参考Fresco的实现）

3. AndroidManifest.xml设置largeHeap=true

ActivityManager.getMemoryClass()可以获取dalvik.vm.heapgrowthlimitd的值，单位MB
ActivityManager.getLargeMemoryClass()可以获取dalvik.vm.heapsize的值，单位MB
Runtime.getRuntime().maxMemory()获取当前VM的最大可用内存，单位Byte

4. 对Bitmap的创建封装统一的入口

使用LruCache减少Bitmap频繁的create

尽量使用decodeStream代替decodeResource decodeFile

使用catch,当发生OOM时，主动执行GC，降低图片灰度值，再次创建

根据view的实际大小来解码相应大小的bitmap

5. 防止内存泄露

避免使用生命周期长的对象应用生命周期短的对象（使用 static关键字，单例中的引用）

注意注册与反注册配对使用

使用leakcanary工具来动态追踪内存泄露，使用MAT来静态分析内存泄露。

6.不要频繁的分配大内存对象，不适用的对象提前置NULL，提前回收。