Android 加载大图、多图和LruCache缓存详细介绍

我们在编写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异常,最好在解析每张图片的时候都先检查一下图片的大小,除非你非常信任图片的来源,保证这些图片都不会超出你程序的可用内存

现在图片的大小已经知道了,我们就可以决定是把整张图片加载到内存中还是加载一个压缩版的图片到内存中。以下几个因素是我们需要考虑的:

  1. 预估一下加载整张图片所需占用的内存
  2. 为了加载这一张图片你所愿意提供多少内存
  3. 用于展示这张图片的控件的实际大小
  4. 当前设备的屏幕尺寸和分辨率

比如,你的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上展示

mImageView.setImageBitmap( 
    decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));

LruCache缓存

在你应用程序的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, 有以下多个因素应该放入考虑范围内,例如:

  1. 你的设备可以为每个应用程序分配多大的内存?
  2. 设备屏幕上一次最多能显示多少张图片?有多少图片需要进行预加载,因为有可能很快也会显示在屏幕上?
  3. 你的设备的屏幕大小和分辨率分别是多少?一个超高分辨率的设备(例如 Galaxy Nexus) 比起一个较低分辨率的设备(例如 Nexus S),在持有相同数量图片的时候,需要更大的缓存空间
  4. 图片的尺寸和大小,还有每张图片会占据多少内存空间
  5. 图片被访问的频率有多高?会不会有一些图片的访问频率比其它图片要高?如果有的话,你也许应该让一些图片常驻在内存当中,或者使用多个LruCache 对象来区分不同组的图片
  6. 你能维持好数量和质量之间的平衡吗?有些时候,存储多个低像素的图片,而在后台去开线程加载高像素的图片会更加的有效

并没有一个指定的缓存大小可以满足所有的应用程序,这是由你决定的。你应该去分析程序内存的使用情况,然后制定出一个合适的解决方案。一个太小的缓存空间,有可能造成图片频繁地被释放和重新加载,这并没有好处。而一个太大的缓存空间,则有可能还是会引起 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的问题了!不过仅仅是理论地介绍不知道大家能不能完全理解。

感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!

(0)

相关推荐

  • Android Bitmap的加载优化与Cache相关介绍

    一 . 高效加载 Bitmap BitMapFactory 提供了四类方法: decodeFile,decodeResource,decodeStream 和 decodeByteArray 分别用于从文件系统,资源,输入流以及字节数组中加载出一个 Bitmap 对象. 高效加载 Bitmap 很简单,即采用 BitMapFactory.options 来加载所需要尺寸图片.BitMapFactory.options 就可以按照一定的采样率来加载缩小后的图片,将缩小后的图片置于 ImageVie

  • 解析Android中View转换为Bitmap及getDrawingCache=null的解决方法

    1.前言 Android中经常会遇到把View转换为Bitmap的情形,比如,对整个屏幕视图进行截屏并生成图片:Coverflow中需要把一页一页的view转换为Bitmap.以便实现复杂的图形效果(阴影.倒影效果等):再比如一些动态的实时View为便于观察和记录数据.需要临时生成静态的Bitmap. 2.实现方法 1)下面是笔者经常用的一个转换方法 public static Bitmap convertViewToBitmap(View view, int bitmapWidth, int

  • 详解Android的内存优化--LruCache

    概念: LruCache 什么是LruCache? LruCache实现原理是什么? 这两个问题其实可以作为一个问题来回答,知道了什么是 LruCache,就只然而然的知道 LruCache 的实现原理:Lru的全称是Least Recently Used ,近期最少使用的!所以我们可以推断出 LruCache 的实现原理:把近期最少使用的数据从缓存中移除,保留使用最频繁的数据,那具体代码要怎么实现呢,我们进入到源码中看看. LruCache源码分析 public class LruCache<

  • Android VideoCache视频缓存的方法详解

    Android VideoCache视频缓存的方法详解 项目中遇到视频播放,需要加载网络url,不可能每次都进行网络加载,当然了,就需要用到我们的缓存机制 AndroidVideoCache AndroidVideoCache是一个视频/音频缓存库,利用本地代理实现了边下边播,使用起来非常简单. HttpProxyCacheServer是主要类,是一个代理服务器,可以配置缓存文件的数量.缓存文件的大小.缓存文件的目录和缓存文件命名算法,文件缓存均基于LRU算法,利用Builder来配置: //配

  • 实现Android 获取cache缓存的目录路径的方法

    实现Android 获取cache缓存的目录路径的方法 Android开发中,有时需要知道cache缓存的路径.我写了一个静态类,供大家能参考 public class CommonUtil { /** * 获取cache路径 * * @param context * @return */ public static String getDiskCachePath(Context context) { if (Environment.MEDIA_MOUNTED.equals(Environmen

  • android中图片的三级缓存cache策略(内存/文件/网络)

    1.简介 现在android应用中不可避免的要使用图片,有些图片是可以变化的,需要每次启动时从网络拉取,这种场景在有广告位的应用以及纯图片应用(比如百度美拍)中比较多. 现在有一个问题:假如每次启动的时候都从网络拉取图片的话,势必会消耗很多流量.在当前的状况下,对于非wifi用户来说,流量还是很贵的,一个很耗流量的应用,其用户数量级肯定要受到影响.当然,我想,向百度美拍这样的应用,必然也有其内部的图片缓存策略.总之,图片缓存是很重要而且是必须的. 2.图片缓存的原理 实现图片缓存也不难,需要有相

  • Android 加载大图、多图和LruCache缓存详细介绍

    我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小.比如说系统图片库里展示的图片大都是用手机摄像头拍出来的,这些图片的分辨率会比我们手机屏幕的分辨率高得多.大家应该知道,我们编写的应用程序都是有一定内存限制的,程序占用了过高的内存就容易出现OOM(OutOfMemory)异常.我们可以通过下面的代码看出每个应用程序最高可用内存是多少 int maxMemory = (int) (Runtime.ge

  • Android 加载大图及多图避免程序出现OOM(OutOfMemory)异常

    Android 加载大图及多图避免程序出现OOM(OutOfMemory)异常 1.高效加载大图片 我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状.不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小.比如说系统图片库里展示的图片大都是用手机摄像头拍出来的,这些图片的分辨率会比我们手机屏幕的分辨率高得多.大家应该知道,我们编写的应用程序都是有一定内存限制的,程序占用了过高的内存就容易出现OOM(OutOfMemory)异常.我们可以通过下面的代码看

  • Android加载长图的多种方案分享

    背景介绍 在某些特定场景下,我们需要考虑加载长图的需求,比如加载一幅<清明上河图>,这个好像有点过分了,那就加载1/2的<清明上河图>吧... 那TMD还不是一样道理. 言归正传说一下我这边遇到的情况,之前有图片或大图的模块是划分为H5来实现的,现在需求变更划分为原生开发,那么问题就来了. 图片尺寸为 图片大小为 这一刻我是懵逼的,哪个端图片上传的时候没限制尺寸和压缩?mdzz, 吐槽归吐槽,还是要撸起袖子解决加载长图大图的问题. 先提供几个技术方案来对比一下: 方案1:WebVi

  • Android 加载GIF图最佳实践方案

    起因 最近在项目中遇到需要在界面上显示一个本地的 GIF 图.按照惯例我直接用了 Glide 框架来实现. Glide 地址: https://github.com/bumptech/glide 我用的 Glide版本为 4.0.0-RC1 , 具体的实现代码如下: Glide.with( this ).asGif().load( R.drawable.yiba_location ).into( location_image ) ; 运行的效果很卡顿,我怀疑是不是方法没有用对,调了压缩模式,还是

  • Android之高效加载大图的方法示例

    加载大图到内存是一件令人头疼的事情.因为大图的原因,我们会在Crash报告中看到OOM(内存不足).Android的内存有限,这一点我们应该心里有数. stackoverflow上有许多相关问题的回答,当你碰到oom时,可以直接跳过本文,粘贴复制答案即可.但是对于其他人来说,我想告诉你们一些加载大图的知识和原理. 加载Bitmap到内存 so easy.你所需要做的就是使用BitmapFactory解码你的图片. Bitmap bitmap = BitmapFactory.decodeResou

  • Android仿ios加载loading菊花图效果

    项目中经常会用到加载数据的loading显示图,除了设计根据app自身设计的动画loading,一般用的比较多的是仿照ios 的菊花加载loading 图,当然一些条件下还会涉及到加载成功/ 失败情况的显示,还有显示文字.   使用ProgressBar 来加载动画转圈,这里使用drawable文件 定义转圈动画, indeterminateDrawable 属性进行加载. <?xml version="1.0" encoding="utf-8"?> &

  • 在Android中高效的加载大图的方法示例

    将大图加载到内存中总是令人痛苦,因为我们经常会在应用的崩溃报告中看到OOM(Out Of Memory)的bug.大家都知道,Android系统的内存有限.我们必须牢记这一点. stackoverflow上有很多关于大图加载的问题,当你的应用程序遇到OOM的时候,你可以选择直接复制粘贴其中的答案来解决这个问题.因此,你完全可以略过本篇文章,但我想介绍一些加载大图的基础知识及其实际工作的原理. 我只想解释图片解码背后的逻辑.我建议你使用Picasso或Glide来加载图片.没有必要重新发明轮子.

  • Android如何使用Glide加载清晰长图

    最近项目中使用的是Glide加载图片,上线后用户反馈图片模糊,经过测试后发现是用户点击超长图放大的时候,图片变的模糊看不起,这很影响用户的体验,要解决这个问题,我们需要先充分的了解Glide的使用. Glide概述 使用习惯Glide3的朋友总会觉得Glide 4相对于Glide 3改动非常大,其实不然.之所以大家会有这种错觉,是因为你将Glide 3的用法直接搬到Glide 4中去使用,结果IDE全面报错,然后大家可能就觉得Glide 4的用法完全变掉了. 其实Glide 4相对于Glide

  • Android加载Gif动画实现代码

    Android加载Gif动画如何实现?相信大家都很好奇,本文就为大家揭晓,内容如下 <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_he

  • Android 加载assets中的资源文件实例代码

    Android 加载assets资源 在android中,如何加载assets目录下的文件夹呢?方法很简单,使用 AssetManager, 即 AssetManager assetManager = getAssets(); 例子如下: AssetManager assetManager = getAssets(); try { String[] files = assetManager.list("Files"); for(int i=0; i<FILES.LENGTH; {

随机推荐