在onDestroy中会用 ((BitmapDrawable)mBtn.getBackground()).setCallback(null)清理背景图。按道理来说图片资源应 该已经清理掉了的。仔细看Bitmap的源代码，它其实起的作用是销毁java对象BitmapDrawable，而android为了提高效率，Bitmap真正的位图数据是在ndk中用c写的，所以用setCallback是不能销毁位图数据的，应该调用Bitmap的recycle()来清理内存。在onDestroy加上((BitmapDrawable)mBtn.getBackground()).getBitmap().recycle()，这样跑下来，内存情况很理想，不管在哪个activity中，使用的资源仅仅是当前activity用到的，就不会象之前到最后一个activity的时候，所有之前使用的资源都累积在内存中。
但新的问题又出现了，当返回之前的activity时，会出现“try to use a recycled bitmap"的异常。这真是按了葫芦起了瓢啊，内心那个沮丧。。。没办法，继续分析。看来是后加上recycle引起的， 位图肯定在内存中有引用，在返回之前的activity时，因为位图数据其实已经被销毁了，所以才造成目前的情况。在看了 setBackgroundResource的源码以后，恍然大悟，android对于直接通过资源id载入的资源其实是做了cache的了，这样下次再 需要此资源的时候直接从cache中得到，这也是为效率考虑。但这样做也造成了用过的资源都会在内存中，这样的设计不是很适合使用了很多大图片资源的应 用，这样累积下来应用的内存峰值是很高的。
看了sdk后，我用：
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();
这样调整后，避免了在应用里缓存所有的资源，节省了宝贵的内存，而其实这样也不会造成太大效率问题，毕竟重新载入资源是非常快速，不会对性能造成很严重的影响，在xoom里我没有感受到和之前有什么区别。
总之，在android上使用大量位图是个比较痛苦的事，内存限制的存在对应用是个很大的瓶颈。但不用因噎费食，其实弄明白了它里面的机制，应用可 以突破这些限制的。这只是其中的一种处理方法，还可以考虑BitmapFactory.Options的inSampleSize来减少内存占用。