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

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: Android高效加载大图、多图解决方案,有效避免程序OOM    我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状、不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小。

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

  

我们在编写Android程序的时候经常要用到许多图片,不同图片总是会有不同的形状、不同的大小,但在大多数情况下,这些图片都会大于我们程序所需要的大小。

 

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

我们可以通过下面的代码看出每个应用程序最高可用内存是多少。

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

因此在展示高分辨率图片的时候,最好先将图片压缩。压缩后的图片大小应该和用来展示它的控件大小相近,在一个很小的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类型,从而根据情况对图片进行压缩。如下代码所示:

 
  
  1. BitmapFactory.Options options = new BitmapFactory.Options();   
  2. options.inJustDecodeBounds = true;   
  3. BitmapFactory.decodeResource(getResources(), R.id.myimage, options);   
  4. int imageHeight = options.outHeight;   
  5. int imageWidth = options.outWidth;   
  6. String imageType = options.outMimeType; 
  7.   

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

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

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

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

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

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

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

那我们怎样才能对图片进行压缩呢?

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

 
  
  1. public static int calculateInSampleSize(BitmapFactory.Options options,   
  2.         int reqWidth, int reqHeight) {   
  3.     // 源图片的高度和宽度   
  4.     final int height = options.outHeight;   
  5.     final int width = options.outWidth;   
  6.     int inSampleSize = 1;   
  7.     if (height > reqHeight || width > reqWidth) {   
  8.         // 计算出实际宽高和目标宽高的比率   
  9.         final int heightRatio = Math.round((float) height / (float) reqHeight);   
  10.         final int widthRatio = Math.round((float) width / (float) reqWidth);   
  11.         // 选择宽和高中最小的比率作为inSampleSize的值,这样可以保证最终图片的宽和高   
  12.         // 一定都会大于等于目标的宽和高。   
  13.         inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;   
  14.     }   
  15.     return inSampleSize;   
  16.   

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

 
  
  1. public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,   
  2.         int reqWidth, int reqHeight) {   
  3.     // 第一次解析将inJustDecodeBounds设置为true,来获取图片大小   
  4.     final BitmapFactory.Options options = new BitmapFactory.Options();   
  5.     options.inJustDecodeBounds = true;   
  6.     BitmapFactory.decodeResource(res, resId, options);   
  7.     // 调用上面定义的方法计算inSampleSize值   
  8.     options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);   
  9.     // 使用获取到的inSampleSize值再次解析图片   
  10.     options.inJustDecodeBounds = false;   
  11.     return BitmapFactory.decodeResource(res, resId, options);   
  12. }   
  13. 下面的代码非常简单地将任意一张图片压缩成100*100的缩略图,并在ImageView上展示。 
  14. [java] view plaincopy 
  15. mImageView.setImageBitmap(   
  16.     decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100100)); 
  17.   

使用图片缓存技术

在你应用程序的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 来缓存图片的例子:

 
  
  1. private LruCache<String, Bitmap> mMemoryCache;   
  2.  
  3. @Override   
  4. protected void onCreate(Bundle savedInstanceState) {   
  5.     // 获取到可用内存的最大值,使用内存超出这个值会引起OutOfMemory异常。   
  6.     // LruCache通过构造函数传入缓存值,以KB为单位。   
  7.     int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);   
  8.     // 使用最大可用内存值的1/8作为缓存的大小。   
  9.     int cacheSize = maxMemory / 8;   
  10.     mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {   
  11.         @Override   
  12.         protected int sizeOf(String key, Bitmap bitmap) {   
  13.             // 重写此方法来衡量每张图片的大小,默认返回图片数量。   
  14.             return bitmap.getByteCount() / 1024;   
  15.         }   
  16.     };   
  17. }   
  18.  
  19. public void addBitmapToMemoryCache(String key, Bitmap bitmap) {   
  20.     if (getBitmapFromMemCache(key) == null) {   
  21.         mMemoryCache.put(key, bitmap);   
  22.     }   
  23. }   
  24.  
  25. public Bitmap getBitmapFromMemCache(String key) {   
  26.     return mMemoryCache.get(key);   
  27.   

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

当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值,则会立刻更新ImageView ,否则开启一个后台线程来加载这张图片。

 
  
  1. public void loadBitmap(int resId, ImageView imageView) {   
  2.     final String imageKey = String.valueOf(resId);   
  3.     final Bitmap bitmap = getBitmapFromMemCache(imageKey);   
  4.     if (bitmap != null) {   
  5.         imageView.setImageBitmap(bitmap);   
  6.     } else {   
  7.         imageView.setImageResource(R.drawable.image_placeholder);   
  8.         BitmapWorkerTask task = new BitmapWorkerTask(imageView);   
  9.         task.execute(resId);   
  10.     }   
  11. }   
  12. BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。 
  13.   
 
  
  1. class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {   
  2.     // 在后台加载图片。   
  3.     @Override   
  4.     protected Bitmap doInBackground(Integer... params) {   
  5.         final Bitmap bitmap = decodeSampledBitmapFromResource(   
  6.                 getResources(), params[0], 100100);   
  7.         addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);   
  8.         return bitmap;   
  9.     }   
  10.   

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

相关文章
|
4月前
|
Java Android开发
Android面试题经典之Glide取消加载以及线程池优化
Glide通过生命周期管理在`onStop`时暂停请求,`onDestroy`时取消请求,减少资源浪费。在`EngineJob`和`DecodeJob`中使用`cancel`方法标记任务并中断数据获取。当网络请求被取消时,`HttpUrlFetcher`的`cancel`方法设置标志,之后的数据获取会返回`null`,中断加载流程。Glide还使用定制的线程池,如AnimationExecutor、diskCacheExecutor、sourceExecutor和newUnlimitedSourceExecutor,其中某些禁止网络访问,并根据CPU核心数动态调整线程数。
146 2
|
29天前
|
Android开发 UED
Android 中加载 Gif 动画
【10月更文挑战第20天】加载 Gif 动画是 Android 开发中的一项重要技能。通过使用第三方库或自定义实现,可以方便地在应用中展示生动的 Gif 动画。在实际应用中,需要根据具体情况进行合理选择和优化,以确保用户体验和性能的平衡。可以通过不断的实践和探索,进一步掌握在 Android 中加载 Gif 动画的技巧和方法,为开发高质量的 Android 应用提供支持。
|
21天前
|
安全 搜索推荐 程序员
深入探索Android系统的碎片化问题及其解决方案
在移动操作系统的世界中,Android以其开放性和灵活性赢得了广泛的市场份额。然而,这种开放性也带来了一个众所周知的问题——系统碎片化。本文旨在探讨Android系统碎片化的现状、成因以及可能的解决方案,为开发者和用户提供一种全新的视角来理解这一现象。通过分析不同版本的Android系统分布、硬件多样性以及更新机制的影响,我们提出了一系列针对性的策略,旨在减少碎片化带来的影响,提升用户体验。
|
1月前
|
开发框架 移动开发 Android开发
安卓与iOS开发中的跨平台解决方案:Flutter入门
【9月更文挑战第30天】在移动应用开发的广阔舞台上,安卓和iOS两大操作系统各自占据半壁江山。开发者们常常面临着选择:是专注于单一平台深耕细作,还是寻找一种能够横跨两大系统的开发方案?Flutter,作为一种新兴的跨平台UI工具包,正以其现代、响应式的特点赢得开发者的青睐。本文将带你一探究竟,从Flutter的基础概念到实战应用,深入浅出地介绍这一技术的魅力所在。
82 7
|
2月前
|
开发框架 前端开发 Android开发
安卓与iOS开发中的跨平台解决方案
【9月更文挑战第27天】在移动应用开发的广阔天地中,安卓和iOS两大操作系统如同双子星座般耀眼。开发者们在这两大平台上追逐着创新的梦想,却也面临着选择的难题。如何在保持高效的同时,实现跨平台的开发?本文将带你探索跨平台开发的魅力所在,揭示其背后的技术原理,并通过实际案例展示其应用场景。无论你是安卓的忠实拥趸,还是iOS的狂热粉丝,这篇文章都将为你打开一扇通往跨平台开发新世界的大门。
|
1月前
|
Android开发
Android开发显示头部Bar的需求解决方案--Android应用实战
Android开发显示头部Bar的需求解决方案--Android应用实战
21 0
|
3月前
|
前端开发 开发工具 Android开发
探索安卓与iOS应用开发:跨平台解决方案的崛起
【8月更文挑战第27天】在移动设备日益普及的今天,安卓和iOS系统占据了市场的主导地位。开发者们面临着一个重要问题:是选择专注于单一平台,还是寻找一种能够同时覆盖两大系统的解决方案?本文将探讨跨平台开发工具的优势,分析它们如何改变了移动应用的开发格局,并分享一些实用的开发技巧。无论你是新手还是资深开发者,这篇文章都将为你提供有价值的见解和建议。
|
3月前
|
Android开发
Android编译出现Warning: Mapping new ns to old ns的解决方案
Android编译出现Warning: Mapping new ns to old ns的解决方案
347 3
|
3月前
|
前端开发 JavaScript Android开发
探索Android和iOS开发中的跨平台解决方案
【8月更文挑战第1天】随着移动应用市场的不断扩张,开发者面临一个共同的挑战——如何高效地为多个平台创建和维护应用程序。本文将深入探讨跨平台开发工具,特别是Flutter和React Native,通过比较它们的优势和限制,并辅以实际代码示例,揭示这些工具如何帮助开发者在保持高性能的同时,实现代码的最大化重用。
|
3月前
|
前端开发 JavaScript Android开发
安卓与iOS开发中的跨平台解决方案
【8月更文挑战第24天】在移动应用开发领域,安卓和iOS两大平台占据了主导地位。然而,为这两个平台分别开发和维护应用会带来额外的时间和成本。本文将探讨跨平台开发的概念、优势以及流行的跨平台框架,如React Native和Flutter,并分析它们如何解决多平台开发的挑战。