Question

android bitmap 使用时候注意什么

Answer 1

一、 问题的背景和意义
在Android移动应用开发中，对Bitmap的不小心处理，很容易引起程序内存空间耗尽而导致的程序崩溃问题。比如我们常遇到的问题：
java.lang.OutofMemoryError: bitmap size exceeds VM budget.
导致该问题的出现，一般由以下几方面原因导致：
引动设备一般存储空间非常有限。当然不同设备分配给应用的内存空间是不同的。但相对不但提高的设备分辨率而言，内存的分配仍然是相对紧张的。
Bitmap对象常常占用大量的内存空间，比如：对于2592*1936的设备，如果采用ARGB_8888的格式加载图像，内存占用将达到19MB空间。
在Anroid App中经常用到ListView，ViewPager等控件，这些控件常会包含较大数量的图片资源。
二、 问题及场景分析
1 高效地加载大图片。
BitmapFactory类提供了一些加载图片的方法：decodeByteArray(), decodeFile(), decodeResource(), 等等。
为了避免占用较大内存，经常使用BitmapFactory.Options 类，设置inJustDecodeBounds属性为true。
//
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds =true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
为了避免java.lang.OutOfMemory 的异常，我们在真正decode图片之前检查它的尺寸，除非你确定这个数据源提供了准确无误的图片且不会导致占用过多的内存。
加载一个按比例缩小的版本到内存中。例如，如果把一个原图是1024*768 pixel的图片显示到ImageView为128*96 pixel的缩略图就没有必要把整张图片都加载到内存中。为了告诉解码器去加载一个较小的图片到内存，需要在你的BitmapFactory.Options 中设置 inSampleSize 为true 。例如, 一个分辨率为2048x1536 的图片，如果设置inSampleSize 为4，那么会产出一个大概为512x384的图片。加载这张小的图片仅仅使用大概0.75MB，如果是加载全图那么大概要花费12MB(假设bitmap的配置是ARGB_8888).
2 不要在主线程处理图片。

众所周知的问题，不再赘述。
注意两点：1. 为了保证使用的资源能被回收，建议使用WeakReference, 以应用内存内存紧张时，回收部分资源，保证程序进程不被杀死。
2. 避免异步任务的长时间耗时操作，在任务执行结束后，及时释放资源。
3 管理Bitmap内存。
在Android开发中，加载一个图片到界面很容易，但如果一次加载大量图片就复杂多了。在很多情况下（比如：ListView,GridView或ViewPager），能够滚动的组件需要加载的图片几乎是无限多的。
有些组件的child view在不显示时会回收，并循环使用，如果没有任何对bitmap的持久引用的话，垃圾回收器会释放你加载的bitmap。这没什么问题，但当这些图片再次显示的时候，要想避免重复处理这些图片，从而达到加载流畅的效果，就要使用内存缓存和本地缓存了，这些缓存可以让你快速加载处理过的图片。
3.1 内存缓存
内存缓存以牺牲内存的代价，带来快速的图片访问。LruCache类（API Level 4之前可以使用Support Library）非常适合图片缓存任务，在一个LinkedHashMap中保存着对Bitmap的强引用，当缓存数量超过容器容量时，删除最近最少使用的成员（LRU）。
注意：在过去，非常流行用SoftReference或WeakReference来实现图片的内存缓存，但现在不再推荐使用这个方法了。因为从Android 2.3 （API Level 9）之后，垃圾回收器会更积极的回收soft/weak的引用，这将导致使用soft/weak引用的缓存几乎没有缓存效果。顺带一提，在Android3.0（API Level 11）以前，bitmap是储存在native 内存中的，所以系统以不可预见的方式来释放bitmap，这可能会导致短时间超过内存限制从而造成崩溃。 收起

Answer 2

内存溢出

.