Android高效加载大图、多图解决方案，有效避免程序OOM
来源：程序员人生 发布时间：2016-06-04 08:04:13 阅读次数：2834次
本文转载自：http://blog.csdn.net/guolin_blog/article/details/9316683
本篇文章主要内容来自于Android Doc，我翻译以后又做了些加工，英文好的朋友也能够直接去读原文。
http://developer.android.com/training/displaying-bitmaps/index.html
高效加载大图片
我们在编写Android程序的时候常常要用到许多图片，不同图片总是会有不同的形状、不同的大小，但在大多数情况下，这些图片都会大于我们程序所需要的大小。比如说系统图片库里展现的图片大都是用手机摄像头拍出来的，这些图片的分辨率会比我们手机屏幕的分辨率高很多。大家应当知道，我们编写的利用程序都是有1定内存限制的，程序占用了太高的内存就容易出现OOM(OutOfMemory)异常。我们可以通过下面的代码看出每一个利用程序最高可用内存是多少。
-
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
-
Log.d("TAG", "Max memory is " + maxMemory + "KB");
因此在展现高分辨率图片的时候，最好先将图片进行紧缩。紧缩后的图片大小应当和用来展现它的控件大小相近，在1个很小的ImageView上显示1张超大的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存，而且在性能上还可能会带来负面影响。下面我们就来看1看，如何对1张大图片进行适当的紧缩，让它能够以最好大小显示的同时，还能避免OOM的出现。
BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象，我们应当根据图片的来源选择适合的方法。比如SD卡中的图片可使用decodeFile方法，网络上的图片可使用decodeStream方法，资源文件中的图片可使用decodeResource方法。这些方法会尝试为已构建的bitmap分配内存，这时候就会很容易致使OOM出现。为此每种解析方法都提供了1个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就能够让解析方法制止为bitmap分配内存，返回值也不再是1个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异常，最好在解析每张图片的时候都先检查1下图片的大小，除非你非常信任图片的来源，保证这些图片都不会超越你程序的可用内存。
现在图片的大小已知道了，我们就能够决定是把整张图片加载到内存中还是加载1个紧缩版的图片到内存中。以下几个因素是我们需要斟酌的：
- 预估1下加载整张图片所需占用的内存。
- 为了加载这1张图片你所愿意提供多少内存。
- 用于展现这张图片的控件的实际大小。
- 当前装备的屏幕尺寸和分辨率。
比如，你的ImageView只有128*96像素的大小，只是为了显示1张缩略图，这时候候把1张1024*768像素的图片完全加载到内存中明显是不值得的。
那我们怎样才能对图片进行紧缩呢？通过设置BitmapFactory.Options中inSampleSize的值就能够实现。比如我们有1张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 = heightRatio < widthRatio ? heightRatio : widthRatio;
-
}
-
return inSampleSize;
-
}
使用这个方法，首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true，解析1次图片。然后将BitmapFactory.Options连同期望的宽度和高度1起传递到到calculateInSampleSize方法中，就能够得到适合的inSampleSize值了。以后再解析1次图片，使用新获得到的inSampleSize值，并把inJustDecodeBounds设置为false，就能够得到紧缩后的图片了。
-
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
-
int reqWidth, int reqHeight) {
-
-
final BitmapFactory.Options options = new BitmapFactory.Options();
-
options.inJustDecodeBounds = true;
-
BitmapFactory.decodeResource(res, resId, options);
-
-
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
-
-
options.inJustDecodeBounds = false;
-
return BitmapFactory.decodeResource(res, resId, options);
-
}
下面的代码非常简单地将任意1张图片紧缩成100*100的缩略图，并在ImageView上展现。
-
mImageView.setImageBitmap(
-
decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));
使用图片缓存技术
在你利用程序的UI界面加载1张图片是1件很简单的事情，但是当你需要在界面上加载1大堆图片的时候，情况就变得复杂起来。在很多情况下，（比如使用ListView, GridView 或 ViewPager 这样的组件），屏幕上显示的图片可以通过滑动屏幕等事件不断地增加，终究致使OOM。
为了保证内存的使用始终保持在1个公道的范围，通常会把被移除屏幕的图片进行回收处理。此时垃圾回收器也会认为你不再持有这些图片的援用，从而对这些图片进行GC操作。用这类思路来解决问题是非常好的，可是为了能让程序快速运行，在界面上迅速地加载图片，你又必须要斟酌到某些图片被回收以后，用户又将它重新滑入屏幕这类情况。这时候重新去加载1遍刚刚加载过的图片无疑是性能的瓶颈，你需要想办法去避免这个情况的产生。
这个时候，使用内存缓存技术可以很好的解决这个问题，它可让组件快速地重新加载和处理图片。下面我们就来看1看如何使用内存缓存技术来对图片进行缓存，从而让你的利用程序在加载很多图片的时候可以提高响应速度和流畅性。
内存缓存技术对那些大量占用利用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache (此类在android-support-v4的包中提供) 。这个类非常合适用来缓存图片，它的主要算法原理是把最近使用的对象用强援用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值到达预设定值之前从内存中移除。
在过去，我们常常会使用1种非常流行的内存缓存技术的实现，即软援用或弱援用 (SoftReference or WeakReference)。但是现在已不再推荐使用这类方式了，由于从 Android 2.3 (API Level 9)开始，垃圾回收器会更偏向于回收持有软援用或弱援用的对象，这让软援用和弱援用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因此没法用1种可预感的方式将其释放，这就有潜伏的风险造成利用程序的内存溢出并崩溃。
为了能够选择1个适合的缓存大小给LruCache, 有以下多个因素应当放入斟酌范围内，例如：
- 你的装备可以为每一个利用程序分配多大的内存？
- 装备屏幕上1次最多能显示多少张图片？有多少图片需要进行预加载，由于有可能很快也会显示在屏幕上？
- 你的装备的屏幕大小和分辨率分别是多少？1个超高分辨率的装备（例如 Galaxy Nexus) 比起1个较低分辨率的装备（例如 Nexus S），在持有相同数量图片的时候，需要更大的缓存空间。
- 图片的尺寸和大小，还有每张图片会占据多少内存空间。
- 图片被访问的频率有多高？会不会有1些图片的访问频率比其它图片要高？如果有的话，你或许应当让1些图片常驻在内存当中，或使用多个LruCache 对象来辨别不同组的图片。
- 你能保持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。
并没有1个指定的缓存大小可以满足所有的利用程序，这是由你决定的。你应当去分析程序内存的使用情况，然后制定出1个适合的解决方案。1个太小的缓存空间，有可能造成图片频繁地被释放和重新加载，这并没有好处。而1个太大的缓存空间，则有可能还是会引发 java.lang.OutOfMemory 的异常。
下面是1个使用 LruCache 来缓存图片的例子：
-
private LruCache<String, Bitmap> mMemoryCache;
-
-
@Override
-
protected void onCreate(Bundle savedInstanceState) {
-
-
-
int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
-
-
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);
-
}
在这个例子当中，使用了系统分配给利用程序的8分之1内存来作为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。1个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。因此，这个缓存大小可以存储2.5页的图片。
当向 ImageView 中加载1张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值，则会立刻更新ImageView ，否则开启1个后台线程来加载这张图片。
生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠
