使用图片缓存技术
在你应用程序的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 来缓存图片的例子：
[java]
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
privateLruCache<String,
Bitmap> mMemoryCache;
@Override
protectedvoidonCreate(Bundle
savedInstanceState) {
intmaxMemory
= (int)
(Runtime.getRuntime().maxMemory() /1024);
intcacheSize
= maxMemory /8;
mMemoryCache
=newLruCache<String,
Bitmap>(cacheSize) {
@Override
protectedintsizeOf(String
key, Bitmap bitmap) {
returnbitmap.getByteCount()
/1024;
}
};
}
publicvoidaddBitmapToMemoryCache(String
key, Bitmap bitmap) {
if(getBitmapFromMemCache(key)
==null)
{
mMemoryCache.put(key,
bitmap);
}
}
publicBitmap
getBitmapFromMemCache(String key) {
returnmMemoryCache.get(key);
}
|
在这个例子当中，使用了系统分配给应用程序的八分之一内存来作为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。因此，这个缓存大小可以存储2.5页的图片。
当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值，则会立刻更新ImageView ，否则开启一个后台线程来加载这张图片。
[java]
|
1
2
3
4
5
6
7
8
9
10
11
|
publicvoidloadBitmap(intresId,
ImageView imageView) {
finalString
imageKey = String.valueOf(resId);
finalBitmap
bitmap = getBitmapFromMemCache(imageKey);
if(bitmap
!=null)
{
imageView.setImageBitmap(bitmap);
}else{
imageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTask
task =newBitmapWorkerTask(imageView);
task.execute(resId);
}
}
|
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
[java]
|
1
2
3
4
5
6
7
8
9
10
|
classBitmapWorkerTaskextendsAsyncTask<Integer,
Void, Bitmap> {
@Override
protectedBitmap
doInBackground(Integer... params) {
finalBitmap
bitmap = decodeSampledBitmapFromResource(
getResources(),
params[0],100,100);
addBitmapToMemoryCache(String.valueOf(params[0]),
bitmap);
returnbitmap;
}
}
使用图片缓存技术
在你应用程序的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 来缓存图片的例子：
[java]
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
privateLruCache<String,
Bitmap> mMemoryCache;
@Override
protectedvoidonCreate(Bundle
savedInstanceState) {
intmaxMemory
= (int)
(Runtime.getRuntime().maxMemory() /1024);
intcacheSize
= maxMemory /8;
mMemoryCache
=newLruCache<String,
Bitmap>(cacheSize) {
@Override
protectedintsizeOf(String
key, Bitmap bitmap) {
returnbitmap.getByteCount()
/1024;
}
};
}
publicvoidaddBitmapToMemoryCache(String
key, Bitmap bitmap) {
if(getBitmapFromMemCache(key)
==null)
{
mMemoryCache.put(key,
bitmap);
}
}
publicBitmap
getBitmapFromMemCache(String key) {
returnmMemoryCache.get(key);
}
|
在这个例子当中，使用了系统分配给应用程序的八分之一内存来作为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。因此，这个缓存大小可以存储2.5页的图片。
当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值，则会立刻更新ImageView ，否则开启一个后台线程来加载这张图片。
[java]
|
1
2
3
4
5
6
7
8
9
10
11
|
publicvoidloadBitmap(intresId,
ImageView imageView) {
finalString
imageKey = String.valueOf(resId);
finalBitmap
bitmap = getBitmapFromMemCache(imageKey);
if(bitmap
!=null)
{
imageView.setImageBitmap(bitmap);
}else{
imageView.setImageResource(R.drawable.image_placeholder);
BitmapWorkerTask
task =newBitmapWorkerTask(imageView);
task.execute(resId);
}
}
|
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
[java]
|
1
2
3
4
5
6
7
8
9
10
|
classBitmapWorkerTaskextendsAsyncTask<Integer,
Void, Bitmap> {
@Override
protectedBitmap
doInBackground(Integer... params) {
finalBitmap
bitmap = decodeSampledBitmapFromResource(
getResources(),
params[0],100,100);
addBitmapToMemoryCache(String.valueOf(params[0]),
bitmap);
returnbitmap;
}
}
|
|
分享到：
相关推荐
Android使用LruCache缓存图片，
案例包含Android-Universal-Image-Loader 网络图片加载框架实现图片加载和结合universal-image-loader与LruCache来自定义缓存图片，可以设置缓存与不缓存。 博客地址：...
AsyncTask的使用及ListView的常见优化 asyncTask异步加载数据 使用了LruCache优化图片加载 通过滑动监听提高ListView滑动流畅度.rar,太多无法一一验证是否可用，程序如果跑不起来需要自调，部分代码功能进行参考学习...
Android Lrucache加载网络图片（AsyncTask ），采用Lrucache算法，AsyncTask 异步缓存加载图片
1、使用了线程池来管理...2、使用LruCache来缓存图片 3、使用手机来缓存图片 4、GridView滑动的时候取消下载任务，静止的时候进行下载，GridView滑动更加的流畅 5、降低了代码的耦合性，结构更加的清晰，便于以后重用
这是一个包含异步加载、网络编程、JSON解析、LruCache图片缓存的简易的ListView图文混排Demo.rar,太多无法一一验证是否可用，程序如果跑不起来需要自调，部分代码功能进行参考学习。
Android内存缓存图片的标准方法，LruCache
该框架或者说库，主要是用于本地的图片缓存处理。 数据的存入 当你取到图片的元数据，会将数据存入硬盘缓存以及内存缓存中。 数据的获取 取数据的时候，先从内存缓存中取； 如果没有取到，则从硬盘缓存中取（此时...
LruCache 的使用 Demo，虽然加载了非常大的图片，但是使用了 Lrucache 作为缓存，使整个 app 的内存使用情况降下来了。
Android图片的三级缓存原理，介绍了图片三级缓存的原理，介绍了Android中软引用的使用，以及lruCache进行图片缓存，请访问我的博客进行查看：http://blog.csdn.net/qq_20889581?viewmode=contents
实现网络图片加载在手机客户端，保存到内存-SD卡-网络，三步走从而实现减小流量消耗，让用户体验跟家流畅
最近写项目，遇到一个图片的三级缓存问题，于是我研究了一下LruCache和DiskLruCache缓存，把代码上传到这里和大家交流学习
我们在编写Android程序的时候经常要用到许多图片，不同图片总是会有不同的形状、不同的大小，但在大多数情况下，这些图片都会大于我们程序所需要的大小。比如说系统图片库里展示的图片大都是用手机摄像头拍出来的，...
我们一般将网络图片分为三个级别，第一级别是网络层，即根据图片的url地址可以找到服务器上相应图片，获取这一层的图片会消耗流量，所以我们希望可以获取后本地就永久使用，所以就会有接下来的缓存策略；第二层缓存...
为了保证内存的使用始终维持在一个合理的范围...这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。
见博客:http://blog.csdn.net/baidu_nod/article/details/38660617
通过LruCache类，实现Android图片的三级缓存。
BitmapFun的简化版，网络加载图片，LruCache处理缓存
在预览图片的时候容易造成oom，这时候用Lurcache和软应用，先在缓存或软应用或sd卡中加载图片，如果没有去网络中下载图片，然后把其添加到sd中同时也放入缓存中
Android批量下载图片并进行缓存，本例包含内存和文件二重缓存，极大的提高流畅度。