Android图片与内存优化

前提：

        在Android 2.3.3(API Level 10)以及之前，Bitmap的backing pixel 数据存储在native memory, 与Bitmap本身是分开的，Bitmap本身存储在dalvik heap 中。导致其pixel数据不能判断是否还需要使用，不能及时释放，容易引起OOM错误。 从Android 3.0(API 11)开始，pixel数据与Bitmap一起存储在Dalvik heap中。

结论：

        如何处理图片来避免OOM异常：

1.在Android 2.3.3以及之前，建议使用Bitmap.recycle()方法，及时释放资源。

2.设置Options.inPreferredConfig值来降低内存消耗 //如把默认值ARGB_8888改为RGB_565,节约一半内存

3.设置Options.inSampleSize 对大图片进行压缩

4.设置Options.inPurgeable和inInputShareable：让系统能及时回收内存。

1）inPurgeable：设置为True时，表示系统内存不足时可以被回 收，设置为False时，表示不能被回收。

2）inInputShareable：设置是否深拷贝，与inPurgeable结合使用，inPurgeable为false时，该参数无意义True：  share  a reference to the input data(inputStream, array,etc) 。 False ：a deep copy。

5.使用decodeStream代替其他decodeResource,setImageResource,setImageBitmap等方法：

//decodeStream直接调用 JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，也不使用java空间进行分辨率适配，虽节省dalvik内存，但需要在hdpi和mdpi，ldpi中配置相应的 图片资源，否则在不同分辨率机器上都是同样大小（像素点数量）。其他方法如setImageBitmap、setImageResource、 BitmapFactory.decodeResource在完成decode后，最终都是通过java层的 createBitmap来完成的，需要消耗更多内存。

6.通过程序设定手动干涉GC处理，增强堆内存处理效率，在程序onCreate时：

private final static floatTARGET_HEAP_UTILIZATION = 0.75f;

VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);

7.自定义堆内存大小：
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE)；

8.基础类型上，因为Java没有实际的指针，在敏感运算方面还是要借助NDK来完成。这点比较有意思的是Google 推出NDK可能是帮助游戏开发人员，比如OpenGL ES的支持有明显的改观，本地代码操作图形界面是很必要的；