最近开发电视版的云存储应用，要求”我的相册“模块有全屏预览图片的功能，全屏分辨率是1920*1080超清。
UI组件方面采用Gallery+ImageSwitcher组合，这里略过，详情参见google Android API。
相册图片预取缓存策略是内存缓存（硬引用LruCache、软引用SoftReference<Bitmap>）、外部文件缓存（context.getCachedDir()），缓存中取不到的情况下再向服务端请求下载图片。同时缓存三张图片（当前预览的这张，前一张以及后一张）。
//需要导入外部jar文件 android-support-v4.jar
import android.support.v4.util.LruCache;
//开辟8M硬缓存空间
private final int hardCachedSize = 8*1024*1024;
//hard cache
private final LruCache<String, Bitmap> sHardBitmapCache = new LruCache<String, Bitmap>(hardCachedSize){
@Override
public int sizeOf(String key, Bitmap value){
return value.getRowBytes() * value.getHeight();
}
@Override
protected void entryRemoved(boolean evicted, String key, Bitmap oldValue, Bitmap newValue){
Log.v("tag", "hard cache is full , push to soft cache");
//硬引用缓存区满，将一个最不经常使用的oldvalue推入到软引用缓存区
sSoftBitmapCahe.put(key, new SoftReference<Bitmap>(oldValue));
}
}
//软引用
private static final int SOFT_CACHE_CAPACITY = 40;
private final static LinkedHashMap<String, SoftReference<Bitmap>> sSoftBitmapCache =
new LinkedHashMao<String, SoftReference<Bitmap>>(SOFT_CACHE_CAPACITY, 0.75f, true){
@Override
public SoftReference<Bitmap> put(String key, SoftReference<Bitmap> value){
return super.input(key, value);
}
@Override
protected boolean removeEldestEntry(LinkedHashMap.Entry<Stirng, SoftReference<Bitmap>> eldest){
if(size() > SOFT_CACHE_CAPACITY){
Log.v("tag", "Soft Reference limit , purge one");
return true;
}
return false;
}
}
//缓存bitmap
public boolean putBitmap(String key, Bitmap bitmap){
if(bitmap != null){
synchronized(sHardBitmapCache){
sHardBitmapCache.put(key, bitmap);
}
return true;
}
return false;
}
//从缓存中获取bitmap
public Bitmap getBitmap(String key){
synchronized(sHardBitmapCache){
final Bitmap bitmap = sHardBitmapCache.get(key);
if(bitmap != null)
return bitmap;
}
//硬引用缓存区间中读取失败，从软引用缓存区间读取
synchronized(sSoftBitmapCache){
SoftReference<Bitmap> bitmapReference = sSoftBtimapCache.get(key);
if(bitmapReference != null){
final Bitmap bitmap2 = bitmapReference.get();
if(bitmap2 != null)
return bitmap2;
else{
Log.v("tag", "soft reference 已经被回收");
sSoftBitmapCache.remove(key);
}
}
}
return null;
}
2.外部文件缓存
private File mCacheDir = context.getCacheDir();
private static final int MAX_CACHE_SIZE = 20 * 1024 * 1024; //20M
private final LruCache<String, Long> sFileCache = new LruCache<String, Long>(MAX_CACHE_SIZE){
@Override
public int sizeOf(String key, Long value){
return value.intValue();
}
@Override
protected void entryRemoved(boolean evicted, String key, Long oldValue, Long newValue){
File file = getFile(key);
if(file != null)
file.delete();
}
}
private File getFile(String fileName) throws FileNotFoundException {
File file = new File(mCacheDir, fileName);
if(!file.exists() || !file.isFile())
throw new FileNotFoundException("文件不存在或有同名文件夹");
return file;
}
//缓存bitmap到外部存储
public boolean putBitmap(String key, Bitmap bitmap){
File file = getFile(key);
if(file != null){
Log.v("tag", "文件已经存在");
return true;
}
FileOutputStream fos = getOutputStream(key);
boolean saved = bitmap.compress(CompressFormat.JPEG, 100, fos);
fos.flush();
fos.close();
if(saved){
synchronized(sFileCache){
sFileCache.put(key, getFile(key).length());
}
return true;
}
return false;
}
//根据key获取OutputStream
private FileOutputStream getOutputStream(String key){
if(mCacheDir == null)
return null;
FileOutputStream fos = new FileOutputStream(mCacheDir.getAbsolutePath() + File.separator + key);
return fos;
}
//获取bitmap
private static BitmapFactory.Options sBitmapOptions;
static {
sBitmapOptions = new BitmapFactory.Options();
sBitmapOptions.inPurgeable=true; //bitmap can be purged to disk
}
public Bitmap getBitmap(String key){
File bitmapFile = getFile(key);
if(bitmapFile != null){
Bitmap bitmap = BitmapFactory.decodeStream(new FileInputStream(bitmapFile), null, sBitmapOptions);
if(bitmap != null){
//重新将其缓存至硬引用中
...
}
}
}
3.从服务端下载图片
下载成功后调用1内存缓存的putBitmap()函数,缓存图片。
在外部文件缓存中也写入一份，调用2的putBitmap()函数.
4.预览图片的流程
1) 如果预览的图片在内存缓存区中，直接调用1的getBitmap()函数，获取bitmap数据(先在硬引用缓存区查找匹配，若硬引用区匹配失败，再去软引用区匹配)
2) 如果从内存缓存区读取失败，再从外部文件缓存中读取，调用2的getBitmap()函数
3) 如果从外部文件缓存中读取失败，则从服务端下载该图片，过程3.
5.生成key值
private static String generateKey(String fileId, int width, int height) {
String ret = fileId + "_" + Integer.toString(width) + "x" + Integer.toString(height);
return ret;
}
String key = generateKey(...)即可生成唯一的key值
http://blog.csdn.net/jdsjlzx/article/details/7589098
Android使用BitmapFactory.Options解决加载大图片内存溢出问题
http://orgcent.com/android-outofmemoryerror-load-big-image/
由于Android对图片使用内存有限制，若是加载几兆的大图片便内存溢出。Bitmap会将图片的所有像素（即长x宽）加载到内存中，如果图片分辨率过大，会直接导致内存溢出（java.lang.OutOfMemoryError），只有在BitmapFactory加载图片时使用BitmapFactory.Options对相关参数进行配置来减少加载的像素。
1、设置缩放大小对图片作处理
public Bitmap getBitmapFromFile(File dst, int width, int height) {
if (null != dst && dst.exists()) {
BitmapFactory.Options opts = null;
if (width > 0 && height > 0) {
opts = new BitmapFactory.Options();
opts.inJustDecodeBounds = true;
BitmapFactory.decodeFile(dst.getPath(), opts);
// 计算图片缩放比例
final int minSideLength = Math.min(width, height);
opts.inSampleSize = computeSampleSize(opts, minSideLength,
width * height);
opts.inJustDecodeBounds = false;
opts.inInputShareable = true;
opts.inPurgeable = true;
}
try {
return BitmapFactory.decodeFile(dst.getPath(), opts);
} catch (OutOfMemoryError e) {
e.printStackTrace();
}
}
return null;
}
public static int computeSampleSize(BitmapFactory.Options options,
int minSideLength, int maxNumOfPixels) {
int initialSize = computeInitialSampleSize(options, minSideLength,
maxNumOfPixels);
int roundedSize;
if (initialSize <= 8) {
roundedSize = 1;
while (roundedSize < initialSize) {
roundedSize <<= 1;
}
} else {
roundedSize = (initialSize + 7) / 8 * 8;
}
return roundedSize;
}
private static int computeInitialSampleSize(BitmapFactory.Options options,
int minSideLength, int maxNumOfPixels) {
double w = options.outWidth;
double h = options.outHeight;
int lowerBound = (maxNumOfPixels == -1) ? 1 : (int) Math.ceil(Math
.sqrt(w * h / maxNumOfPixels));
int upperBound = (minSideLength == -1) ? 128 : (int) Math.min(Math
.floor(w / minSideLength), Math.floor(h / minSideLength));
if (upperBound < lowerBound) {
// return the larger one when there is no overlapping zone.
return lowerBound;
}
if ((maxNumOfPixels == -1) && (minSideLength == -1)) {
return 1;
} else if (minSideLength == -1) {
return lowerBound;
} else {
return upperBound;
}
}
http://blog.csdn.net/jdsjlzx/article/details/7589143
方法一：
在从网络或本地加载图片的时候，只加载缩略图。
/**
* 按照路径加载图片
* @param path 图片资源的存放路径
* @param scalSize 缩小的倍数
* @return
*/
public static Bitmap loadResBitmap(String path, int scalSize) {
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = scalSize;
Bitmap bmp = BitmapFactory.decodeFile(path, options);
return bmp;
}
这个方法的确能够少占用不少内存，可是它的致命的缺点就是，因为加载的是缩略图，所以图片失真比较严重，对于对图片质量要求很高的应用，可以采用下面的方法。
方法二：
运用JAVA的软引用，进行图片缓存，将经常需要加载的图片，存放在缓存里，避免反复加载。
关于软引用（SoftReference）的详细说明，请参看http://blog.csdn.net/helixiuqqq/article/details/6610199。下面是我写的一个图片缓存的工具类。
/**
*
* @author larson.liu
* 该类用于图片缓存，防止内存溢出
*/
public class BitmapCache {
static private BitmapCache cache;
/** 用于Chche内容的存储*/
private Hashtable<Integer, BtimapRef> bitmapRefs;
/** 垃圾Reference的队列（所引用的对象已经被回收，则将该引用存入队列中）*/
private ReferenceQueue<Bitmap> q;
/**
* 继承SoftReference，使得每一个实例都具有可识别的标识。
*/
private class BtimapRef extends SoftReference<Bitmap> {
private Integer _key = 0;
public BtimapRef(Bitmap bmp, ReferenceQueue<Bitmap> q, int key) {
super(bmp, q);
_key = key;
}
}
private BitmapCache() {
bitmapRefs = new Hashtable<Integer, BtimapRef>();
q = new ReferenceQueue<Bitmap>();
}
/**
* 取得缓存器实例
*/
public static BitmapCache getInstance() {
if (cache == null) {
cache = new BitmapCache();
}
return cache;
}
/**
* 以软引用的方式对一个Bitmap对象的实例进行引用并保存该引用
*/
private void addCacheBitmap(Bitmap bmp, Integer key) {
cleanCache();// 清除垃圾引用
BtimapRef ref = new BtimapRef(bmp, q, key);
bitmapRefs.put(key, ref);
}
/**
* 依据所指定的drawable下的图片资源ID号（可以根据自己的需要从网络或本地path下获取），重新获取相应Bitmap对象的实例
*/
public Bitmap getBitmap(int resId, Context context) {
Bitmap bmp = null;
// 缓存中是否有该Bitmap实例的软引用，如果有，从软引用中取得。
if (bitmapRefs.containsKey(resId)) {
BtimapRef ref = (BtimapRef) bitmapRefs.get(resId);
bmp = (Bitmap) ref.get();
}
// 如果没有软引用，或者从软引用中得到的实例是null，重新构建一个实例，
// 并保存对这个新建实例的软引用
if (bmp == null) {
bmp = BitmapFactory.decodeResource(context.getResources(), resId);
this.addCacheBitmap(bmp, resId);
}
return bmp;
}
private void cleanCache() {
BtimapRef ref = null;
while ((ref = (BtimapRef) q.poll()) != null) {
bitmapRefs.remove(ref._key);
}
}
// 清除Cache内的全部内容
public void clearCache() {
cleanCache();
bitmapRefs.clear();
System.gc();
System.runFinalization();
}
}
在程序代码中调用该类：
imageView.setImageBitmap(bmpCache.getBitmap(R.drawable.kind01, this));
这样当你的imageView需要来回变换背景图片时，就不需要再重复加载。
方法三：
及时销毁不再使用的Bitmap对象。
if (bitmap != null && b!itmap.isRecycled()){
bitmap.recycle();
bitmap = null; // recycle()是个比较漫长的过程，设为null，然后在最后调用System.gc()，效果能好很多
}
System.gc();
方法四：
尽可能少的使用图片资源。
这个有点像废话哈。但我只知道我们经理说服客户改了一下需求，然后在一个动态的listView里（最多时能有100多项），就一下子少加载了几十张网络图片，这该能节约多少内存啊！
综合运用以上四种方法，一般的项目，应该就能避免oom的错误。欢迎一起探讨更好的关于“图片内存溢出问题”的解决方案。
android Bitmap过大内存溢出问题的解决
http://www.eoeandroid.com/blog-535302-2208.html
手机内存的管理，至关重要。
一般用到gallery的时候，需要加载大量图片，这时候，就会出现OOM的问题。
一般会报这种错误：java.lang.OutOfMemoryError: bitmap size exceeds VM budget，这是因为，android系统中读取位图Bitmap时.分给虚拟机中图片的堆栈大小只有8M。所以不管是如何调用的图片，太多太大虚拟机肯定会报这个错误。
遇到这种问题的解决方案是：缩小图片+回收资源的方式，来优化内存：
1.尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。
因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，无需再使用java层的createBitmap，从而节省了java层的空间。如果在读取时加上图片的Config参数，可以跟有效减少加载的内存，从而跟有效阻止抛out of Memory异常
另外，decodeStream直接拿的图片来读取字节码了， 不会根据机器的各种分辨率来自动适应，使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相应的图片资源，否则在不同分辨率机器上都是同样大小（像素点数量），显示出来的大小就不对了。
另外，以下方式也大有帮助：
1. InputStream is = this.getResources().openRawResource(R.drawable.pic1);
BitmapFactory.Options options=new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = 10; //width，hight设为原来的十分一
Bitmap btp =BitmapFactory.decodeStream(is,null,options);
2. if(!bmp.isRecycle() ){
bmp.recycle() //回收图片所占的内存
system.gc() //提醒系统及时回收
}
2.回收资源
（1）
//用来存放图片的缓存
HashMap<Integer, Bitmap> bitmapCache = new HashMap<Integer, Bitmap>();
//如果没有图片，或者已经存在
if(bitmapCache.isEmpty() || !AppConst.bitmapCache.containsKey(position)){
bitmapCache.put(position, bm);
System.out.println("-----------inset cache---------");
}
（2）定义FreeBitmap函数，在activity结束的时候，调用FreeBitmap函数，回收map中的资源
private void FreeBitmap(HashMap<Integer, Bitmap> cache){
if(cache.isEmpty()){
return;
}
for(Bitmap bitmap:cache.values()){
if(bitmap != null && !bitmap.isRecycled()){
bitmap.recycle();
System.out.println("=============recycle bitmap=======");
}
}
cache.clear();
}
--------------------------------------------------------------------------------------------------------------------------------------------------
另外★Android 还有一些性能优化的方法（参考：http://blog.csdn.net/reachkate/article/details/6780496）：
● 首先内存方面，可以参考 Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配
● 基础类型上，因为Java没有实际的指针，在敏感运算方面还是要借助NDK来完成。这点比较有意思的是Google推出NDK可能是帮助游戏开发人员，比如OpenGL ES的支持有明显的改观，本地代码操作图形界面是很必要的。
● 图形对象优化，这里要说的是Android上的Bitmap对象销毁，可以借助recycle()方法显示让GC回收一个Bitmap对象，通常对一个不用的Bitmap可以使用下面的方式，如
Java代码
if(bitmapObject.isRecycled()==false) //如果没有回收
bitmapObject.recycle();
if(bitmapObject.isRecycled()==false) //如果没有回收 bitmapObject.recycle();
● 目前系统对动画支持比较弱智对于常规应用的补间过渡效果可以，但是对于游戏而言一般的美工可能习惯了GIF方式的统一处理，目前 Android系统仅能预览GIF的第一帧，可以借助J2ME中通过线程和自己写解析器的方式来读取GIF89格式的资源。
● 对于大多数Android手机没有过多的物理按键可能我们需要想象下了做好手势识别 GestureDetector 和重力感应来实现操控。通常我们还要考虑误操作问题的降噪处理。
Android堆内存也可自己定义大小
对于一些大型Android项目或游戏来说在算法处理上没有问题外，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都 比较吝啬，对于软件的流畅性来说RAM对性能的影响十分敏感，除了上次Android开发网提到的 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
Java代码
private
final
static
int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ; VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。
当然对于内存吃紧来说还可以通过手动干涉GC去处理，我们将在下次提到具体应用。
优化Dalvik虚拟机的堆内存分配
对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体 原理我们可以参考开源工程，这里我们仅说下使用方法:
Java代码
private
final
static floatTARGET_HEAP_UTILIZATION = 0.75f;
private final static floatTARGET_HEAP_UTILIZATION = 0.75f;
在程序onCreate时就可以调用
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
前言
众所周知，每个Android应用程序在运行时都有一定的内存限制，限制大小一般为16MB或24MB（视平台而定）。因此在开发应用时需要特别关注自身的内存使用量，而一般最耗内存量的资源，一般是图片、音频文件、视频文件等多媒体资源；由于Android系统对音频、视频等资源做了边解析便播放的处理，使用时并不会把整个文件加载到内存中，一般不会出现内存溢出（以下简称OOM）的错误，因此它们的内存消耗问题暂不在本文的讨论范围。本文重点讨论的是图片的内存消耗问题，如果你要开发的是一款图片浏览器应用，例如像Android系统自带的Gallery那样的应用，这个问题将变得尤为突出；如果你开发的是目前的购物客户端，有时候处理不当也会碰到这种问题。
目前碰到的OOM场景，无外乎以下几种情形，不过无论是哪种情形，解决问题的思路都是一致的。
(1)显示单张图片，图片文件体积达到3000*4000级别的时候；
(2)在ListView或Gallery等控件中一次性加载大量图片时；
相关知识介绍
1.颜色模型
常见的颜色模型有RGB、YUV、CMYK等，在大多数图像API中采用的都是RGB模型，Android也是如此；另外，在Android中还有包含透明度Alpha的颜色模型，即ARGB。关于颜色模型更加详细的信息暂不在本文的讨论范围之内。
2.计算机中颜色值的数字化编码
在不考虑透明度的情况下，一个像素点的颜色值在计算机中的表示方法有以下3种：
(1)浮点数编码：比如float: (1.0, 0.5, 0.75)，每个颜色分量各占1个float字段，其中1.0表示该分量的值为全红或全绿或全蓝；
(2)24位的整数编码：比如24-bit:(255, 128, 196)，每个颜色分量各占8位，取值范围0-255，其中255表示该分量的值为全红或全绿或全蓝；
(3)16位的整数编码：比如16-bit:(31, 45, 31)，第1和第3个颜色分量各占5位，取值范围0-31，第2个颜色分量占6位，取值范围0-63；
在Java中，float类型的变量占32位，int类型的变量占32位，short和char类型的变量都在16位，因此可以看出，用浮点数表示法编码一个像素的颜色，内存占用量是96位即12字节；而用24位整数表示法编码，只要一个int类型变量，占用4个字节（高8位空着，低24位用于表示颜色）；用16位整数表示法编码，只要一个short类型变量，占2个字节；因此可以看出采用整数表示法编码颜色值，可以大大节省内存，当然，颜色质量也会相对低一些。在Android中获取Bitmap的时候一般也采用整型编码。
以上2种整型编码的表示法中，R、G、B各分量的顺序可以是RGB或BGR，Android里采用的是RGB的顺序，本文也都是遵循此顺序来讨论。在24位整型表示法中，由于R、G、B分量各占8位，有时候业内也以RGB888来指代这一信息；类似的，在16位整型表示法中，R、G、B分量分别占5、6、5位，就以RGB565来指代这一信息。
现在再考虑有透明度的颜色编码，其实方式与无透明度的编码方式一样：24位整型编码RGB模型采用int类型变量，其闲置的高8位正好用于放置透明度分量，其中0表示全透明，255表示完全不透明；按照A、R、G、B的顺序，就可以以ARGB8888来概括这一情形；而16位整型编码的RGB模型采用short类型变量，调整各分量所占为数分别至4位，那么正好可以空出4位来编码透明度值；按照A、R、G、B的顺序，就可以以ARGB4444来概括这一情形。回想一下Android的BitmapConfig类中，有ARGB_8888、ARGB_4444、RGB565等常量，现在可以知道它们分别代表了什么含义。同时也可以计算一张图片在内存中可能占用的大小，比如采用ARGB_8888编码载入一张1920*1200的图片，大概就会占用1920*1200*4/1024/1024=8.79MB的内存。
3.Bitmap在内存中的存储区域
http://www.7dot9.com/2010/08/android-bitmap%E5%86%85%E5%AD%98%E9%99%90%E5%88%B6/ 一文中对Android内存限制问题做了一些探讨，作者认为Bitmap对象通过栈上的引用来指向堆上的Bitmap对象，而Bitmap对象又对应了一个使用了外部存储的native图像，实际上使用的是byte[]来存储的内存空间。但为了确保外部分配内存成功，应该保证当前已分配的内存加上当前需要分配的内存值，大小不能超过当前堆的最大内存值，而且内存管理上将外部内存完全当成了当前堆的一部分。
4.Java对象的引用类型
(1)强引用（StrongReference）如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
(2)软引用（SoftReference）如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
(3)弱引用（WeakReference）弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。
(4)虚引用（PhantomReference）“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
解决OOM的常用方案
内存限制是Android对应用的一个系统级限制，作为应用层开发人员，没有办法彻底去消灭这个限制，但是可以通过一些手段去合理使用内存，从而规避这个问题。以下是个人总结的一些常用方法：
(1)缓存图像到内存，采用软引用缓存到内存，而不是在每次使用的时候都从新加载到内存；
(2)调整图像大小，手机屏幕尺寸有限，分配给图像的显示区域本身就更小，有时图像大小可以做适当调整；
(3)采用低内存占用量的编码方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省内存；
(4)及时回收图像，如果引用了大量Bitmap对象，而应用又不需要同时显示所有图片，可以将暂时用不到的Bitmap对象及时回收掉；
(5)自定义堆内存分配大小，优化Dalvik虚拟机的堆内存分配；
本文主要将对前面4种方式做演示和分析。
演示试验说明
为了说明出现OOM的场景和解决OOM的方法，本人制作了一个Android应用——OomDemo来演示，此应用的基本情况说明如下：
(1)该应用展示一个gallery，该gallery只加载图片，gallery的adapter中传入图片的路径而不是图片对象本身，adapter动态加载图片；
(2)演示所用的图片预存储到sdcard的cache目录下，文件名分别为a.jpg，b.jpg…r.jpg，总共18张；
(3)图片为规格1920*1200的jpg图片，文件大小在423KB-1.48MB范围内；
(4)运行环境：模拟器——android2.2版本系统——480*320屏幕尺寸；Moto Defy——2.3.4版本CM7系统——854*480屏幕尺寸；
(5)程序基本结构图：
演示结果与说明
1.演示一
首先采用最简单的图片加载方式，不带任何图片缓存、调整大小或者回收，SimpleImageLoader.class便是承担此职责。加载图片部分的代码如下：
@Override
public Bitmap loadBitmapImage(String path) {
return BitmapFactory.decodeFile(path);
}
@Override
public Drawable loadDrawableImage(String path) {
return new BitmapDrawable(path);
}
演示结果：在模拟器上图片只能加载1-3张，之后便会出现OOM错误；在Defy上不会出现错误；原因是两者内存限制不同，Defy上运行的是第三方ROM，内存分配有40MB。另外gallery每次显示一张图片时，都要重新解析获得一张图片，尽管在Defy上还未曾出错，但当图片量加大，GC回收不及时时，还是有可能出现OOM。
2.演示二
为图片加载的添加一个软引用缓存，每次图片从缓存中获取图片对象，若缓存中不存在，才会从Sdcard加载图片，并将该对象加入缓存。同时软引用的对象也有助于GC在内存不足的时候回收它们。ImageLoaderWithCache.class负责这个职责，关键代码如下：
private HashMap<String, SoftReference<Bitmap>> mImageCache;
@Override
public Bitmap loadBitmapImage(String path) {
if(mImageCache.containsKey(path)) {
SoftReference<Bitmap> softReference = mImageCache.get(path);
Bitmap bitmap = softReference.get();
if(null != bitmap)
return bitmap;
}
Bitmap bitmap = BitmapFactory.decodeFile(path);
mImageCache.put(path, new SoftReference<Bitmap>(bitmap));
return bitmap;
}
@Override
public Drawable loadDrawableImage(String path) {
return new BitmapDrawable(loadBitmapImage(path));
}
演示结果：在模拟器上，能不无缓存时多加载1-2张图片，但还是会出现OOM；在Defy上不曾出错。由于本次所用的图片都相对比较占内存，在GC还未来得及回收软引用对象时，就又要申请超出剩余量的内存空间，因此仍然没能完全避免OOM。如果换成加载大量的小图片，比如100*100规格的，缓存中软引用的作用可能就发挥出来了。（这一假设可以进一步试验证明一下）
3.演示三
为了进一步避免OOM，除了缓存，还可以对图片进行压缩，进一步节省内存，多数情况下调整图片大小并不会影响应用的表现力。ImageLoaderWithScale.class便是负责这个职责，调整大小的代码如下：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(path, options);
if (options.mCancel || options.outWidth == -1 || options.outHeight == -1) {
Log.d(“OomDemo”, “alert!!!” + String.valueOf(options.mCancel) + ” ” + options.outWidth + options.outHeight);
return null;
}
options.inSampleSize = Util.computeSampleSize(options, 600, (int) (1 * 1024 * 1024));
Log.d(“OomDemo”, “inSampleSize: ” + options.inSampleSize);
options.inJustDecodeBounds = false;
options.inDither = false;
options.inPreferredConfig = Bitmap.Config.ARGB_8888;
Bitmap bitmap = BitmapFactory.decodeFile(path, options);
演示结果：在上述代码中，首先解码图片的边界，在不需要得到Bitmap对象的前提下就能获得图像宽高（宽高值分别被设置到options.outWidth和options.outHeight两个属性中）。computeSampleSize这个方法的参数分别为“解析图片所需的BitmapFactory.Options”、“调整后图片最小的宽或高值”、“调整后图片的内存占用量上限”。结合原始图片的宽高，此方法可以计算得到一个调整比例，再用此比例调整原始图片并加载到内存中，此时图片所消耗的内存不会超出事先指定的大小。在模拟器中，限制图片所占内存大小为1*1024*1024时，比未压缩过时能加载更多图片，但仍然会出现OOM；若限制图片所占内存大小为0.5*1024*1024，则能完整的载入所有图片。所以调整图片大小还是能够有效节省内存的。在Defy中不会出错，原因同上。
4.演示四
在有些情况下，严重缩小图片还是会影响应用的显示效果的，所以有必要在尽可能少地缩小图片的前提下展示图片，此时手动去回收图片就变得尤为重要。在类ImageLoaderWithRecyle.class中，便增加了回收图片资源的方法：
@Override
public void releaseImage(String path) {
if(mImageCache.containsKey(path)) {
SoftReference<Bitmap> reference = mImageCache.get(path);
Bitmap bitmap = reference.get();
if(null != bitmap) {
Log.d(“OomDemo”, “recyling ” + path);
bitmap.recycle();
}
mImageCache.remove(path);
}
}
演示结果：图片压缩限制仍然维持在1*1024*1024，在adapter中，及时调用releaseImage方法，回收暂时不需要的图片。此时模拟器中也从未出现过OOM，所以总的来讲，综合缓存、调整大小、回收等各种手段，还是能够有效避免OOM的。
小结
本文介绍了软引用缓存、调整大小、回收等手段来避免OOM，总体来说效果还是明显的。但实际应用场景中，图片的应用不想本文所演示的那样简单，有时候图片资源可能来自与网络，这时需要配合异步加载的方式先下载图片并通过回调的方法来显示；有时候图片资源还需要加边框、加文字等额外修饰，所以在图片加载之后还要另做处理。
另外由于本人能力所限以及时间关系，本文还有诸多不完善之处。比如对Android内存分配的理解不深，没能透彻地解释Bitmap的内存占用情况；通过自定义堆内存分配大小，优化Dalvik虚拟机的堆内存分配的方法来解决OOM，本文也没有给予演示；再比如在上文的演示试验里，没有把内存占用情况的详细信息用图像形式直观地展示出来；还有演示所用的图片数量过少、规格单一、测试环境偏少，所有没能进行更加严谨科学的对比试验，遗漏了某些意外情况。最后欢迎大家来共同探索、交流并提出建议。
参考代码
http://longerian.googlecode.com/svn/trunk/OomDemo
补充说明
本文原本是发表在本人的原生Wordpress空间里，无奈在天朝无法访问，所以特地搬家到此。
本文参考过的文章资料汇总
http://winuxxan.blog.51cto.com/2779763/512180
http://www.7dot9.com/2010/08/android-bitmap%E5%86%85%E5%AD%98%E9%99%90%E5%88%B6/
http://blog.csdn.net/rickleaf/article/details/6393185
http://hi.baidu.com/455611934/blog/item/cb56aa442bc7b829879473d8.html
http://ck19860613.iteye.com/blog/842732
http://blog.csdn.net/kavendb/article/details/5935577
437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
