使用LRU算法缓存图片,android 3.0

在您的UI中显示单个图片是非常简单的,如果您需要一次显示很多图片就有点复杂了。在很多情况下 (例如使用 ListView, GridView 或者 ViewPager控件), 显示在屏幕上的图片以及即将显示在屏幕上的图片数量是非常大的(例如在图库中浏览大量图片)。

在这些控件中,当一个子控件不显示的时候,系统会重用该控件来循环显示 以便减少对内存的消耗。同时垃圾回收机制还会 释放那些已经载入内存中的Bitmap资源(假设您没有强引用这些Bitmap)。一般来说这样都是不错的,但是在用户来回滑动屏幕的时候,为了保证UI 的流畅性和载入图片的效率,您需要避免重复的处理这些需要显示的图片。 使用内存缓存和磁盘缓存可以解决这个问题,使用缓存可以让控件快速的加载已经处理过的图片。

这节内容介绍如何使用缓存来提高UI的载入输入和滑动的流畅性。

使用内存缓存

内存缓存提高了访问图片的速度,但是要占用不少内存。 LruCache 类(在API 4之前可以使用Support Library 中的类 )特别适合缓存Bitmap, 把最近使用到的 Bitmap对象用强引用保存起来(保存到LinkedHashMap中),当缓存数量达到预定的值的时候,把 不经常使用的对象删除。

注意: 过去,实现内存缓存的常用做法是使用 SoftReference 或者 WeakReference bitmap 缓存, 但是不推荐使用这种方式。从Android 2.3 (API Level 9) 开始,垃圾回收开始强制的回收掉 soft/weak 引用 从而导致这些缓存没有任何效率的提升。 另外,在 Android 3.0 (API Level 11)之前,这些缓存的Bitmap数据保存在底层内存(native memory)中,并且达到预定条件后也不会释放这些对象,从而可能导致 程序超过内存限制并崩溃。

在使用 LruCache 的时候,需要考虑如下一些因素来选择一个合适的缓存数量参数:

  • 程序中还有多少内存可用
  • 同时在屏幕上显示多少图片?要先缓存多少图片用来显示到即将看到的屏幕上?
  • 设备的屏幕尺寸和屏幕密度是多少?超高的屏幕密度(xhdpi 例如 Galaxy Nexus) 设备显示同样的图片要比低屏幕密度(hdpi 例如 Nexus S)设备需要更多的内存。
  • 图片的尺寸和格式决定了每个图片需要占用多少内存
  • 图片访问的频率如何?一些图片的访问频率要比其他图片高很多?如果是这样的话,您可能需要把这些经常访问的图片放到内存中。
  • 在质量和数量上如何平衡?有些情况下保存大量的低质量的图片是非常有用的,当需要的情况下使用后台线程来加入一个高质量版本的图片。

这里没有万能配方可以适合所有的程序,您需要分析您的使用情况并在指定自己的缓存策略。使用太小的缓存并不能起到应有的效果,而使用太大的缓存会消耗更多 的内存从而有可能导致 java.lang.OutOfMemory 异常或者留下很少的内存供您的程序其他功能使用。

下面是一个使用 LruCache 缓存的示例:

 private LruCache<string, bitmap=""> mMemoryCache;  
  
 @Override 
 protected void onCreate(Bundle savedInstanceState) {  
     ...  
  // Get memory class of this device, exceeding this amount will throw an 
  // OutOfMemory exception. 
  final int memClass = ((ActivityManager) context.getSystemService(  
             Context.ACTIVITY_SERVICE)).getMemoryClass();  
  
  // Use 1/8th of the available memory for this memory cache. 
  final int cacheSize = 1024 * 1024 * memClass / 8;  
  
     mMemoryCache = new LruCache<string, bitmap="">(cacheSize) {  
  @Override 
  protected int sizeOf(String key, Bitmap bitmap) {  
  // The cache size will be measured in bytes rather than number of items. 
  return bitmap.getByteCount();  
         }  
     };  
     ...  
 }  
  
 public void addBitmapToMemoryCache(String key, Bitmap bitmap) {  
  if (getBitmapFromMemCache(key) == null) {  
         mMemoryCache.put(key, bitmap);  
     }  
 }  
  
 public Bitmap getBitmapFromMemCache(String key) {  
  return mMemoryCache.get(key);  
 }  

注意: 在这个示例中,该程序的1/8内存都用来做缓存用了。在一个normal/hdpi设备中,这至少有4MB(32/8)内存。 在一个分辨率为 800×480的设备中,满屏的GridView全部填充上图片将会使用差不多1.5MB(800*480*4 bytes) 的内存,所以这样差不多在内存中缓存了2.5页的图片。

当在 ImageView 中显示图片的时候, 先检查LruCache 中是否存在。如果存在就使用缓存后的图片,如果不存在就启动后台线程去载入图片并缓存:

 public void loadBitmap(int resId, ImageView imageView) {  
  final String imageKey = String.valueOf(resId);  
  
  final Bitmap bitmap = getBitmapFromMemCache(imageKey);  
  if (bitmap != null) {  
         mImageView.setImageBitmap(bitmap);  
     } else {  
         mImageView.setImageResource(R.drawable.image_placeholder);  
         BitmapWorkerTask task = new BitmapWorkerTask(mImageView);  
         task.execute(resId);  
     }  
 }  

BitmapWorkerTask 需要把新的图片添加到缓存中:

 class BitmapWorkerTask extends AsyncTask<integer, void,="" bitmap=""> {  
     ...  
  // Decode image in background. 
  @Override 
  protected Bitmap doInBackground(Integer... params) {  
  final Bitmap bitmap = decodeSampledBitmapFromResource(  
                 getResources(), params[0], 100, 100));  
         addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);  
  return bitmap;  
     }  
     ...  
 }  

使用磁盘缓存

在访问最近使用过的图片中,内存缓存速度很快,但是您无法确定图片是否在缓存中存在。像 GridView 这种控件可能具有很多图片需要显示,很快图片数据就填满了缓存容量。 同时您的程序还可能被其他任务打断,比如打进的电话 — 当您的程序位于后台的时候,系统可能会清楚到这些图片缓存。一旦用户恢复使用您的程序,您还需要重新处理这些图片。

在这种情况下,可以使用磁盘缓存来保存这些已经处理过的图片,当这些图片在内存缓存中不可用的时候,可以从磁盘缓存中加载从而省略了图片处理过程。 当然, 从磁盘载入图片要比从内存读取慢很多,并且应该在非UI线程中载入磁盘图片。

注意: 如果缓存的图片经常被使用的话,可以考虑使用 ContentProvider ,例如在图库程序中就是这样干滴。

在示例代码中有个简单的 DiskLruCache 实现。然后,在Android 4.0中包含了一个更加可靠和推荐使用的DiskLruCache(libcore/luni/src/main/java/libcore/io/DiskLruCache.java) 。您可以很容易的把这个实现移植到4.0之前的版本中使用(来 href="http://www.google.com/search?q=disklrucache">Google一下 看看其他人是否已经这样干了!)。

这里是一个更新版本的 DiskLruCache :

 private DiskLruCache mDiskCache;  
 private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB 
 private static final String DISK_CACHE_SUBDIR = "thumbnails";  
  
 @Override 
 protected void onCreate(Bundle savedInstanceState) {  
     ...  
  // Initialize memory cache 
     ...  
     File cacheDir = getCacheDir(this, DISK_CACHE_SUBDIR);  
     mDiskCache = DiskLruCache.openCache(this, cacheDir, DISK_CACHE_SIZE);  
     ...  
 }  
  
 class BitmapWorkerTask extends AsyncTask<integer, void,="" bitmap=""> {  
     ...  
  // Decode image in background. 
  @Override 
  protected Bitmap doInBackground(Integer... params) {  
  final String imageKey = String.valueOf(params[0]);  
  
  // Check disk cache in background thread 
         Bitmap bitmap = getBitmapFromDiskCache(imageKey);  
  
  if (bitmap == null) { // Not found in disk cache 
  // Process as normal 
  final Bitmap bitmap = decodeSampledBitmapFromResource(  
                     getResources(), params[0], 100, 100));  
         }  
  
  // Add final bitmap to caches 
         addBitmapToCache(String.valueOf(imageKey, bitmap);  
  
  return bitmap;  
     }  
     ...  
 }  
  
 public void addBitmapToCache(String key, Bitmap bitmap) {  
  // Add to memory cache as before 
  if (getBitmapFromMemCache(key) == null) {  
         mMemoryCache.put(key, bitmap);  
     }  
  
  // Also add to disk cache 
  if (!mDiskCache.containsKey(key)) {  
         mDiskCache.put(key, bitmap);  
     }  
 }  
  
 public Bitmap getBitmapFromDiskCache(String key) {  
  return mDiskCache.get(key);  
 }  
  
 // Creates a unique subdirectory of the designated app cache directory. Tries to use external 
 // but if not mounted, falls back on internal storage. 
 public static File getCacheDir(Context context, String uniqueName) {  
  // Check if media is mounted or storage is built-in, if so, try and use external cache dir 
  // otherwise use internal cache dir 
  final String cachePath = Environment.getExternalStorageState() == Environment.MEDIA_MOUNTED  
             || !Environment.isExternalStorageRemovable() ?  
                     context.getExternalCacheDir().getPath() : context.getCacheDir().getPath();  
  
  return new File(cachePath + File.separator + uniqueName);  
 }  

在UI线程中检测内存缓存,在后台线程中检测磁盘缓存。磁盘操作从来不应该在UI线程中实现。当图片处理完毕后,最终的结果会同时添加到 内存缓存和磁盘缓存中以便将来使用。

处理配置改变事件

运行时的配置变更 — 例如 屏幕方向改变 — 导致Android摧毁正在运行的Activity,然后使用 新的配置从新启动该Activity (详情,参考这里 Handling Runtime Changes)。 您需要注意避免在配置改变的时候导致重新处理所有的图片,从而提高用户体验。

幸运的是,您在 使用内存缓存 部分已经有一个很好的图片缓存了。该缓存可以通过 Fragment (Fragment会通过setRetainInstance(true)函数保存起来)来传递给新的Activity 当Activity重新启动 后,Fragment 被重新附加到Activity中,您可以通过该Fragment来获取缓存对象。

下面是一个在 Fragment中保存缓存的示例:

 private LruCache<string, bitmap=""> mMemoryCache;  
  
 @Override 
 protected void onCreate(Bundle savedInstanceState) {  
     ...  
     RetainFragment mRetainFragment =  
             RetainFragment.findOrCreateRetainFragment(getFragmentManager());  
     mMemoryCache = RetainFragment.mRetainedCache;  
  if (mMemoryCache == null) {  
         mMemoryCache = new LruCache<string, bitmap="">(cacheSize) {  
             ... // Initialize cache here as usual 
         }  
         mRetainFragment.mRetainedCache = mMemoryCache;  
     }  
     ...  
 }  
  
 class RetainFragment extends Fragment {  
  private static final String TAG = "RetainFragment";  
  public LruCache<string, bitmap=""> mRetainedCache;  
  
  public RetainFragment() {}  
  
  public static RetainFragment findOrCreateRetainFragment(FragmentManager fm) {  
         RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG);  
  if (fragment == null) {  
             fragment = new RetainFragment();  
         }  
  return fragment;  
     }  
  
  @Override 
  public void onCreate(Bundle savedInstanceState) {  
  super.onCreate(savedInstanceState);  
         <strong>setRetainInstance(true);</strong>  
     }  
 }  

您可以尝试分别使用和不使用Fragment来旋转设备的屏幕方向来查看具体的图片载入情况。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏郭霖

Android ListView异步加载图片乱序问题,原因分析及解决方案

在Android所有系统自带的控件当中,ListView这个控件算是用法比较复杂的了,关键是用法复杂也就算了,它还经常会出现一些稀奇古怪的问题,让人非常头疼。比...

421100
来自专栏非著名程序员

Android自定义ViewGroup神器-ViewDragHelper

? 投稿作者:zhuhf 原文链接:http://www.jianshu.com/p/111a7bc76a0e 特别声明:本文为zhuhf原创并授权发布,未经...

34350
来自专栏everhad

札记:android手势识别,MotionEvent

摘要 本文是手势识别输入事件处理的完整学习记录。内容包括输入事件InputEvent响应方式,触摸事件MotionEvent的概念和使用,触摸事件的动作分类、多...

38170
来自专栏Android常用基础

基于zxing的二维码扫描

现在的应用中二维码扫描已经成为一个应用必不可少的功能,现在大部分Android二维码扫描都是基于zxing和Zbar,这文章就来介绍一下基于zxing的二维码扫...

50620
来自专栏编程之路

羊皮书APP(Android版)开发系列(二十三)10分钟单例模式实战-Glide图片加载库封装工具类

12050
来自专栏developerHaoz 的安卓之旅

Android Volley 源码解析(三),图片加载的实现

在上一篇文章中,我们一起深入探究了 Volley 的缓存机制,通过源码分析对缓存的工作原理进行了了解,这篇文章将带大家一起探究「Volley 图片加载的实现」,...

10520
来自专栏张高兴的博客

张高兴的 Xamarin.Android 学习笔记:(三)活动生命周期

381110
来自专栏Android干货园

【PageLayout】非常简单的一键切换加载-空数据-错误页,支持自定义

Android中经常使用一个空白页和网络错误页用来提高用户体验,给用户一个较好的感官,如果获取到的数据为空,那么会显示一个空白数据页,如果在获取数据的过程中网络...

13030
来自专栏分享达人秀

日期选择器DatePicker和时间选择器TimePicker

在实际开发中,经常会遇见一些时间选择器、日期选择器、数字选择器等需求,那么从本期开始来学习Android中常用选择器,今天学习的是DatePicker和...

40050
来自专栏Samego开发资源

Android车轮之图片加载框架Android-Universal-Image-Loader

15950

扫码关注云+社区

领取腾讯云代金券