引用：http://blog.csdn.net/ouyangtianhan/article/details/8450225
- <span style="font-family: Arial; ">
- </span>
- <span style="font-family: Arial; ">
- 引用自：</span><a href="http://blog.csdn.net/awp258/article/details/7951932" style="font-family: Arial; ">http://blog.csdn.net/awp258/article/details/7951932</a>
最近在xoom上开发应用，碰到ui设计都是使用图片，而且是多个activity。开始没觉得怎么样，就开始做呗。等做完了，开始在前三个activity运行没问题，一切ok。但在最后一个activity里，会经常出现oom（out of memory），由于在最后一个activity，需要打开一个pdf，然后render，随着multi-touch，reander的pdf页缩放，由于reander的图片本身就比较大（比如，如果pdf放大到当前屏幕的两倍，pdf图片占用的内存为1280＊800＊4＊2／（1024＊1024），约等于8m），而且由于为了视觉上感受好，会在其中缓存图片（为了不让用户在使用过程中感受操作有停滞感），所以总是导致oom异常。
oh，my god！最怕碰到这种情况，android对于内存heap size限制让人比较崩溃，ios虽然也号称一个应用有内存限制，但是在实际使用中一个应用使用的内存往往可以超过100m，所以还是挺容易做一个性能满意的应用程序。
我的应用到底哪些地方使用了这么多内存，因为android3.0默认heap size为48m，按道理来说还是可以接受的，怎么应用没跑几下就oom呢？没办法，只能通过ddms来分析，在ddms中“update heap”－》“cause gc”，来查看应用的内存使用情况，发现每进入一个activity，1-byte array(byte[], boolean[])的值总是会相应的增加，到最后一个activity的时候啥都不干，heap size已经快30m了，oh。。。怎么会这样。。。冷静冷静。。。通过分析，1-byte array就是bitmap的占用空间，这就说明不断有新的bitmap在内存中。由于ui使用了很多图片，比如大背景图，按钮图片等等，看来是这些图片都会存在内存中，即使当前activity已经销毁进入下一个activity，前一个activity的图片资源也没有销毁。
原因找到了，但不是太想得通。因为在onCreate中我用mBtn.setBackgroundResource(R.drawable.splash)为控件设置背景图，然后在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资源和class等使用的内存都在10m左右，已经很理想了（当然如果是在android低版本比如1.5,16时还是不行的，这得重新构架应用），可以为显示pdf预留了比较多内存了。
但新的问题又出现了，当返回之前的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来减少内存占用。
