Android大图片引起的内存问题（OOM）

在Android应用开发中，对一个应用在内存使用大小是有限制。在应用中如果大量的使用Bitmap很有可能导致内存溢出的问题(OOM)，出现这种问题后，第一感觉就是头疼，但是又不得不解决，在网上查了一些资料后，找到解决方法。

问题描述：

在一个项目中，要用Gallery来显示多张不同的图片，在给Gallery的每个Item设置图片显示时，想到Bitmap如果不手动的recycle，系统是不会回收其所在的资源的，因为Android为了提高效率，Bitmap真正的位图数据是在ndk中C写的。所以就直接使用setImageResource(iconResId); 但是在部分配置比较低的设备上还是出现OOM错误。

问题分析：

在setImageResource中，是根据iconResId的到一个drawable，在将drawable显示在view中。在查阅资料后得知：Android对于直接通过资源id载入的资源做了Cache，这样下次再需要次资源时直接从cache中得到。

在Gallery中用到多个大的图片，每个图片都会在cache中进行缓存，即使在Gallery中该View被回收了。这就是导致内存溢出的问题。

问题解决：

解决的一般办法：

一：在内存引用上做些处理，常用的有软引用、强化引用、弱引用

二：在内存中加载图片时直接在内存中做处理，如：边界压缩

三：动态回收内存

四：优化Dalvik虚拟机的堆内存分配

五：自定义堆内存大小

在项目中主要将前两种方法进行了整合。

private static LinkedHashMap<String, Bitmap> hardManager;
	private static ConcurrentHashMap<String, SoftReference<Bitmap>> softManager;

设置上面的两个变量，分别保存包名到Bitmap的强引用的映射和软引用的映射。

在通过包名获取bitmap时，首先在hardManager中判断是否包含该包名，如果有，直接取出；如果没有，则在softManager中判断，有取出；没有就通过下面方法获取。获取之后在插入到hardManager中。在插入时，做判断只保证hardManager的容量为10，如果大于10，则将最早插入的删除。

private static Bitmap readBitMap(Context context, int resId) {
		BitmapFactory.Options opt = new BitmapFactory.Options();
		opt.inPreferredConfig = Bitmap.Config.RGB_565;
		opt.inPurgeable = true;
		opt.inInputShareable = true;
		// 获取资源图片
		InputStream is = context.getResources().openRawResource(resId);
		return BitmapFactory.decodeStream(is, null, opt);
	}

参考资料：

http://www.cnblogs.com/siyiganshou/archive/2012/08/10/2631727.html

http://www.cnblogs.com/siyiganshou/archive/2012/08/10/2631755.html

http://www.cnblogs.com/siyiganshou/archive/2012/08/10/2631727.html

关于Android 内存优化测试比较Drawable与Bitmap占用内存大小 中，作者的疑惑就是应用Drawable会进行缓存，所以在同样将一个图片加载1000次Drawable没有出现OOM的错误，而Bitmap出现了OOM错误。并不是因为Drawable所在的内存比Bitmap要小。

关于Drawable和Bitmap到底谁在用的内存要小，大家感兴趣可以看看源码？