Android高效加载大图、多图解决方案，有效避免程序OOM

Android高效加载大图、多图解决方案，有效避免程序OOM

  

咱们在编写Android程序的时候常常要用到许多图片，不一样图片老是会有不一样的形状、不一样的大小，但在大多数状况下，这些图片都会大于咱们程序所须要的大小。

 

好比说系统图片库里展现的图片大都是用手机摄像头拍出来的，这些图片的分辨率会比咱们手机屏幕的分辨率高得多。你们应该知道，咱们编写的应用程序都是有必定内存限制的，程序占用了太高的内存就容易出现OOM(OutOfMemory)异常。

咱们能够经过下面的代码看出每一个应用程序最高可用内存是多少。

int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
Log.d("TAG", "Max memory is " + maxMemory + "KB");

所以在展现高分辨率图片的时候，最好先将图片压缩。压缩后的图片大小应该和用来展现它的控件大小相近，在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处，但却会占用咱们至关多宝贵的内存，并且在性能上还可能会带来负面影响。下面咱们就来看一看，如何对一张大图片进行适当的压缩，让它可以以最佳大小显示的同时，还能防止OOM的出现。

BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于建立Bitmap对象，咱们应该根据图片的来源选择合适的方法。好比SD卡中的图片可使用decodeFile方法，网络上的图片可使用decodeStream方法，资源文件中的图片可使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易致使OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可让解析方法禁止为bitmap分配内存，返回值也再也不是一个Bitmap对象，而是null。虽然Bitmap是null了，可是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让咱们能够在加载图片以前就获取到图片的长宽值和MIME类型，从而根据状况对图片进行压缩。以下代码所示：

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;

为了不OOM异常，最好在解析每张图片的时候都先检查一下图片的大小，除非你很是信任图片的来源，保证这些图片都不会超出你程序的可用内存。

如今图片的大小已经知道了，咱们就能够决定是把整张图片加载到内存中仍是加载一个压缩版的图片到内存中。如下几个因素是咱们须要考虑的：

预估一下加载整张图片所需占用的内存。

为了加载这一张图片你所愿意提供多少内存。

用于展现这张图片的控件的实际大小。

当前设备的屏幕尺寸和分辨率。

好比，你的ImageView只有128*96像素的大小，只是为了显示一张缩略图，这时候把一张1024*768像素的图片彻底加载到内存中显然是不值得的。

那咱们怎样才能对图片进行压缩呢？

经过设置BitmapFactory.Options中inSampleSize的值就能够实现。好比咱们有一张2048*1536像素的图片，将inSampleSize的值设置为4，就能够把这张图片压缩成512*384像素。本来加载这张图片须要占用13M的内存，压缩后就只须要占用0.75M了(假设图片是ARGB_8888类型，即每一个像素点占用4个字节)。下面的方法能够根据传入的宽和高，计算出合适的inSampleSize值：

public static int calculateInSampleSize(BitmapFactory.Options options,
        int reqWidth, int reqHeight) {
    // 源图片的高度和宽度
    final int height = options.outHeight;
    final int width = options.outWidth;
    int inSampleSize = 1;
    if (height > reqHeight || width > reqWidth) {
        // 计算出实际宽高和目标宽高的比率
        final int heightRatio = Math.round((float) height / (float) reqHeight);
        final int widthRatio = Math.round((float) width / (float) reqWidth);
        // 选择宽和高中最小的比率做为inSampleSize的值，这样能够保证最终图片的宽和高
        // 必定都会大于等于目标的宽和高。
        inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
    }
    return inSampleSize;
}

使用这个方法，首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true，解析一次图片。而后将BitmapFactory.Options连同指望的宽度和高度一块儿传递到到calculateInSampleSize方法中，就能够获得合适的inSampleSize值了。以后再解析一次图片，使用新获取到的inSampleSize值，并把inJustDecodeBounds设置为false，就能够获得压缩后的图片了。

public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
        int reqWidth, int reqHeight) {
    // 第一次解析将inJustDecodeBounds设置为true，来获取图片大小
    final BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(res, resId, options);
    // 调用上面定义的方法计算inSampleSize值
    options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
    // 使用获取到的inSampleSize值再次解析图片
    options.inJustDecodeBounds = false;
    return BitmapFactory.decodeResource(res, resId, options);
}
下面的代码很是简单地将任意一张图片压缩成100*100的缩略图，并在ImageView上展现。
[java] view plaincopy
mImageView.setImageBitmap(
    decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));

使用图片缓存技术

在你应用程序的UI界面加载一张图片是一件很简单的事情，可是当你须要在界面上加载一大堆图片的时候，状况就变得复杂起来。在不少状况下，（好比使用ListView, GridView 或者 ViewPager 这样的组件），屏幕上显示的图片能够经过滑动屏幕等事件不断地增长，最终致使OOM。

为了保证内存的使用始终维持在一个合理的范围，一般会把被移除屏幕的图片进行回收处理。此时垃圾回收器也会认为你再也不持有这些图片的引用，从而对这些图片进行GC操做。用这种思路来解决问题是很是好的，但是为了能让程序快速运行，在界面上迅速地加载图片，你又必需要考虑到某些图片被回收以后，用户又将它从新滑入屏幕这种状况。这时从新去加载一遍刚刚加载过的图片无疑是性能的瓶颈，你须要想办法去避免这个状况的发生。

这个时候，使用内存缓存技术能够很好的解决这个问题，它可让组件快速地从新加载和处理图片。下面咱们就来看一看如何使用内存缓存技术来对图片进行缓存，从而让你的应用程序在加载不少图片的时候能够提升响应速度和流畅性。

内存缓存技术对那些大量占用应用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache (此类在android-support-v4的包中提供) 。这个类很是适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，而且把最近最少使用的对象在缓存值达到预设定值以前从内存中移除。

在过去，咱们常常会使用一种很是流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。可是如今已经再也不推荐使用这种方式了，由于从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得再也不可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，于是没法用一种可预见的方式将其释放，这就有潜在的风险形成应用程序的内存溢出并崩溃。

为了可以选择一个合适的缓存大小给LruCache, 有如下多个因素应该放入考虑范围内，例如：

你的设备能够为每一个应用程序分配多大的内存？

设备屏幕上一次最多能显示多少张图片？有多少图片须要进行预加载，由于有可能很快也会显示在屏幕上？

你的设备的屏幕大小和分辨率分别是多少？一个超高分辨率的设备（例如 Galaxy Nexus) 比起一个较低分辨率的设备（例如 Nexus S），在持有相同数量图片的时候，须要更大的缓存空间。

图片的尺寸和大小，还有每张图片会占据多少内存空间。

图片被访问的频率有多高？会不会有一些图片的访问频率比其它图片要高？若是有的话，你也许应该让一些图片常驻在内存当中，或者使用多个LruCache 对象来区分不一样组的图片。

你能维持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。

并无一个指定的缓存大小能够知足全部的应用程序，这是由你决定的。你应该去分析程序内存的使用状况，而后制定出一个合适的解决方案。一个过小的缓存空间，有可能形成图片频繁地被释放和从新加载，这并无好处。而一个太大的缓存空间，则有可能仍是会引发 java.lang.OutOfMemory 的异常。

下面是一个使用 LruCache 来缓存图片的例子：

private LruCache<String, Bitmap> mMemoryCache;

@Override
protected void onCreate(Bundle savedInstanceState) {
    // 获取到可用内存的最大值，使用内存超出这个值会引发OutOfMemory异常。
    // LruCache经过构造函数传入缓存值，以KB为单位。
    int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
    // 使用最大可用内存值的1/8做为缓存的大小。
    int cacheSize = maxMemory / 8;
    mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
        @Override
        protected int sizeOf(String key, Bitmap bitmap) {
            // 重写此方法来衡量每张图片的大小，默认返回图片数量。
            return bitmap.getByteCount() / 1024;
        }
    };
}

public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
    if (getBitmapFromMemCache(key) == null) {
        mMemoryCache.put(key, bitmap);
    }
}

public Bitmap getBitmapFromMemCache(String key) {
    return mMemoryCache.get(key);
}

在这个例子当中，使用了系统分配给应用程序的八分之一内存来做为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。所以，这个缓存大小能够存储2.5页的图片。

当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。若是找到了相应的键值，则会马上更新ImageView ，不然开启一个后台线程来加载这张图片。

public void loadBitmap(int resId, ImageView imageView) {
    final String imageKey = String.valueOf(resId);
    final Bitmap bitmap = getBitmapFromMemCache(imageKey);
    if (bitmap != null) {
        imageView.setImageBitmap(bitmap);
    } else {
        imageView.setImageResource(R.drawable.image_placeholder);
        BitmapWorkerTask task = new BitmapWorkerTask(imageView);
        task.execute(resId);
    }
}
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。

class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
    // 在后台加载图片。
    @Override
    protected Bitmap doInBackground(Integer... params) {
        final Bitmap bitmap = decodeSampledBitmapFromResource(
                getResources(), params[0], 100, 100);
        addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
        return bitmap;
    }
}

掌握了以上两种方法，不论是要在程序中加载超大图片，仍是要加载大量图片，都不用担忧OOM的问题了!不过仅仅是理论地介绍不知道你们能不能彻底理解，在后面的文章中我会演示如何在实际程序中灵活运用上述技巧来避免程序OOM，敬请期待。