标签：
=========== 1 视图显示大量图片时的内存问题
setBackgroundResource 回去res 资源文件里面找适配手机当前屏幕的文件，所以消耗高，etBackgroundDrawable不会去适配，
会导致图片显示不太兼容其他屏幕，优缺点自己去考虑就好
昨天优化一个项目（基本上每个ACTIVITY都会有大量图片），查了很多资料，借鉴了一些做法，网上的说法有对有错，这里总结一下。
android3.0 默认heap size为48m，进入ddms，在ddms中“update heap”－“cause gc”，查看应用的内存使用情况，发现每进入一个activity，1-byte array(byte[], boolean[])的值总是会相应的增加，
到最后一个activity的时候啥都不干，heap size已经快30m了。通过分析，1-byte array就是bitmap的占用空间，这就说明不断有新的bitmap在内存中。由于ui使用了很多图片，比如大背景图，按钮图片等等，看来是这些图片 都会存在内存中，即使当前activity已经销毁进入下一个activity，前一个activity的图片资源也没有销毁。
其中一个做法是：
用Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash);
BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm);
mBtn.setBackgroundDrawable(bd); 来代替mBtn.setBackgroundResource(R.drawable.splash)。
销毁的时候使用：
BitmapDrawable bd ＝ (BitmapDrawable)mBtn.getBackground();
mBtn.setBackgroundResource(0);//别忘了把背景设为null，避免onDraw刷新背景时候出现used a recycled bitmap错误
bd.setCallback(null);
bd.getBitmap().recycle();
因为setBackgroundResource时，会缓存图片的CHCHE，以便重绘时加快速度。如果说，每次都使用recycle的话，就达不到这个目的了。而且根据以往的经验，对于一般应用，根本就没有这个必要，内存过大，势必还有原因造成。
在“update heap”－“cause gc”，点击1-byte array(byte[], boolean[])行后，在Heap表里，查看图片内存的占用比例直方图，发现一些图片的占用内存居然高达10M（特别是在三星galaxy note运行时），
但项目里最大的原始图片也才1M多，很明显程序的写法有问题。最后，发现，在资源文件里，设置android:background为某些图片时，导致内存大增。但如果把设置背景的步骤写在JAVA代码里，问题便解决了。
JAVA代码：
testview.setBackgroundResource(R.drawable.testview_bg);//内存还是会增大两三倍
结合上面的另一种作法，改用setBackgroundDrawable，如：
Bitmap bitmap = null;
try {
bitmap = BitmapFactory.decodeResource(context.getResources(), res, bfOptions);
} catch (OutOfMemoryError oom) {
android.util.Log.e("getSDCardImageBitmapByUrl","OutOfMemoryError");
System.gc();
System.runFinalization();
} finally {
}
if (bitmap != null && !bitmap.isRecycled()) {
BitmapDrawable bd = new BitmapDrawable(context.getResources(), bitmap);
v.setBackgroundDrawable(bd);
// bitmapCache.put(key, new WeakReference<Bitmap>(bitmap));
drawableCache.put(key, new WeakReference<Drawable>(bd));
}
内存问题解决。 但是，setBackgroundResource和setBackgroundDrawable的差别为什么这么大，待研究。。。
标签：
原文地址：http://www.cnblogs.com/awkflf11/p/5364731.html
