标签:
Android中最常用到缓存的地方就是图片,通过过缓存即可以提高应用程序的效率,又可以节省用户的流量。
图片的缓存简单来说可以分为SD卡缓存和内存缓存,也可以俩者配合使用。
Android中图片缓存遵循的策略就是:当第一次从网络中加载图片的时候,将其缓存到存储设备上(比如sd卡,这也就是我们说的SD卡缓存),并且在内存中同样也缓存一份(内存缓存),这样当下次使用或者网络请求图片的时候,就先去内存中获取(因为从内存中读取要比从SD卡中读取的快,所以我们先从内存中读取,这样的话在节省流量的同时也可以提高程序的性能),如果内存中没有的话再去SD卡中获取,如果SD卡中也没有的话才去网络上请求。
当然,由于设备的存储容量限制,我们也需要把缓存到SD卡的图片资源在一个合适的时间内删除。当然,这个合适的时间怎么定义就仁者见仁智者见智了,目前常用的是算法是LRU算法,所以一个完整的缓存策略包括添加,获取,删除三类操作
LRU(Least Recently Used),近期最少使用算法,它的核心思想就是当缓存满时,优先淘汰即删除近期最少使用的缓存对象。
采用LRU算法的缓存有俩种:
LruCache是Android 3.1 提供的,使用support-4兼容包中LruCache可以向下兼容到2.2。
LruCache内部采用一个LinkedHashMap以强引用的方式存储外界提供的缓存对象,提供了put和get方法来添加和获取缓存对象,另外LruCache也是线程安全的。。
Runtime.getRuntime().maxMemory()
在Java中返回的是java虚拟机(这个进程)能构从操纵系统那里挖到的最大的内存,而在Android中返回应用程序最大可用内存,以字节为单位。也可以用
((ActivityManager)getSystemService(Context.ACTIVITY_SERVICE)).getMemoryClass()
来获取,不过返回值的单位是M。
Runtime.getRuntime().totalMemory()
在Java中返回的是java虚拟机现在已经从操纵系统那里挖过来的内存大小,也就是java虚拟机这个进程当时所占用的所有内存,在Android中返回的是应用程序已获得内存,所以totalMemory()是慢慢增大的。
Runtime.getRuntime().freeMemory()
简单来说就是已经获取到但是还没有使用的内存。
创建LruCache代码:
//创建LruCache对象
int maxSize = (int) Runtime.getRuntime().maxMemory();// 返回byte
int cacheSize = maxSize / 1024 / 8;
// 创建LruCache时需要提供缓存的最大容量
mCache = new LruCache<String, Bitmap>(cacheSize) {
@Override
protected int sizeOf(String key, Bitmap value) {
return super.sizeOf(key, value);
}
@Override
protected void entryRemoved(boolean evicted, String key, Bitmap oldValue, Bitmap newValue) {
// 当调用put或remove时触发此方法,可以在这里完成一些资源回收的操作
super.entryRemoved(evicted, key, oldValue, newValue);
}
};
mCache.put(key, value);// 添加缓存对象
mCache.get(key);// 获取缓存对象
mCache.remove(key);// 删除缓存对象
mCache.resize(1024);// 重新设置缓存的总容量大小
上面讲过,DiskLruCache不属于Android SDK 的一部分,但是它得到了Google官方的认可与推荐,它的源码在这里或者这里;其实GitHub上才是正儿八经的出产地哈。在使用DiskLruCache时,首先要从网上下载DiskLruCache的源码,然后放到自己的项目里编译后才能正常使用。
DiskLruCache不能通过构造方法来创建,它通过open方法来穿件自身
public static DiskLruCache open(File directory, int appVersion, int valueCount, long maxSize)
1. directory表示磁盘缓存的存储路径
缓存目录没有具体限制,可以根据需求自己的定义。一般来说,可以选择SD卡上的/sdcard/Android/data/<application package>/cache
目录,这个目录是Android系统指定的应用程序缓存目录,当应用卸载时,缓存也会被系统清除;当然还可以选择sd卡上的其他目录,也可以选择data下的当前应用目录。当然,一个严禁的程序还要考虑SD卡是否存在等。
2. appVersion表示应用的版本号
当appVersion改变时,之前的缓存都会被清除,所以如非必要,我们为其指定一个1,不再改变即可
3. valueCount表示单个节点对应的数据个数,也就是同一个key可以对应多少个缓存文件,一般来说我们都选取1.
4. maxSize缓存的总大小。
private void createDiskLruCache() {
try {
File cacheDir = getDiskCacheDir(DiskLruCacheActivity.this, "bitmapsCache");
if (!cacheDir.exists()) {
cacheDir.mkdirs();
}
diskLruCache = DiskLruCache.open(cacheDir, 1, 1, MAX_DISK_CACHE);
} catch (IOException e) {
Log.i("disk cache", "createDiskLruCache e: " + e.toString());
}
}
DiskLruCache的缓存添加是通过Editor完成的,代码如下:
// 把图片添加到硬盘缓存
private void exeAdd2DiskCache(DiskLruCache.Editor editor) {
if (editor != null) {
try {
// 创建DiskLruCache时设置一个节点只有一个数据,所以这里的index直接设为0即可
OutputStream outputStream = editor.newOutputStream(0);
if (downloadUrlToStream(imageUrl, outputStream)) {
editor.commit();// 提交写入操作
Log.i("disk cache", "onCreate editor.commit() ");
} else {
editor.abort();// 回退整个操作
Log.i("disk cache", "onCreate editor.abort() ");
}
diskLruCache.flush();
} catch (IOException e) {
Log.i("disk cache", "onCreate e: " + e.toString());
}
}
}
// 建立HTTP请求,并获取Bitmap对象。
private boolean downloadUrlToStream(String urlString, OutputStream outputStream) {
HttpURLConnection urlConnection = null;
BufferedOutputStream out = null;
BufferedInputStream in = null;
try {
final URL url = new URL(urlString);
urlConnection = (HttpURLConnection) url.openConnection();
in = new BufferedInputStream(urlConnection.getInputStream(), 8 * 1024);
out = new BufferedOutputStream(outputStream, 8 * 1024);
int b;
while ((b = in.read()) != -1) {
out.write(b);
}
return true;
} catch (final IOException e) {
e.printStackTrace();
} finally {
if (urlConnection != null) {
urlConnection.disconnect();
}
try {
if (out != null) {
out.close();
}
if (in != null) {
in.close();
}
} catch (final IOException e) {
e.printStackTrace();
}
}
return false;
}
当然,以上只是展示DiskLruCache的用法,在实际项目中还要和项目需求结合,考虑实际情况,比如Caused by: android.os.NetworkOnMainThreadException
异常等。
首先需要将URL转换成Key,然后通过DiskLruCache的get方法得到一个Snapshot对象,在通过Snapshot对象得到缓存文件的输入流,再把输入流转换成Bitamp对象。
// 从缓存中获取Bitmap对象
private Bitmap getCacheBitmap() {
String key = hashKeyForDisk(imageUrl);// 把Url转换成KEY
try {
DiskLruCache.Snapshot snapShot = diskLruCache.get(key);// 通过key获取Snapshot对象
if (snapShot != null) {
InputStream is = snapShot.getInputStream(0);// 通过Snapshot对象获取缓存文件的输入流
Bitmap bitmap = BitmapFactory.decodeStream(is);// 把输入流转换成Bitmap对象
return bitmap;
}
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
关于 BitmapFactory.decodeStream(is) 更多资料请点这里查看
private void deleteCacheBitmap(String url){
try {
String key = hashKeyForDisk(imageUrl);
diskLruCache.remove(key);
} catch (IOException e) {
e.printStackTrace();
}
}
这个remove方法,如果不是必要的话,我们尽量不要去调用,因为我们已经设定了最大缓存容量,当超过这个容量时,系统会根据Lru算法自动删除该删除的缓存文件。
当执行完写入操作后,我们看看对应的目录下(/sdcard/Android/data//cache)有什么文件?
打开cache目录后,发现里边只有一个bitmapsCache的文件夹;这个文件是哪里来的呢?这个其实就是上文在创建DiskLruCache实例时传入的url中拼接的(看 getDiskCacheDir 方法),为什么要指定这么一个目录呢?其实就是类似于分类的概念,比如你可以把缓存的Bitmap放到一个文件夹下,把file或者其他格式的数据放到另外一个文件夹下。
打开bitmapsCache文件夹,它的子目录又有哪些呢?首先有一个文件,这个文件的文件名很长而且没有任何规则,完全看不懂是什么意思;另外下边还有一个journal文件。其实文件名很长的文件就是一张缓存的图片,每个文件都对应着一张图片,如果我们缓存了很多图片的话,就会有一堆这样的文件;而journal文件是DiskLruCache的一个日志文件,就像我上面说的:这个文件中保存着对数据的操作记录。如下图:
打开journal这个文件,发现它长成这样 长得也很整齐:
首先有一行字符串“libcore.io.DiskLruCache”表示我们使用的是DiskLruCache技术;然后又有三行,且每行都只有一个“1”,其中第一行的“1”表示DiskLruCache的版本号,这个值是恒为1的,第2行的“1”表示应用程序的版本号,我们在open()方法里传入的版本号是什么这里就会显示什么,第三个“1”表示的是valueCount,表示单个节点对应的数据个数,这个值也是在open()方法中传入的,通常情况下都为1。接下来就是一个空行,标志着开始记录数据的操作记录。
接下来,会有DIRTY开头的一行数据,DIRTY后边跟着的是文件的key,DIRTY表示开始向缓存中写入数据,但写入结果是什么还未知。然后调用commit()方法表示写入缓存成功,这时会向journal中写入一条CLEAN记录,表示数据写入成功;如果数据写入失败,会调用abort()方法回退整个操作,这时会向journal中写入一条REMOVE记录。当调用get()方法去读取一条缓存数据时,就会向journal文件中写入一条READ记录;另外,某些行后面还有一个数字(20090、6602),这个数字就是缓存图片的大小,以byte为单位。
===============================================
上一篇:Bitmap的使用
更多内容请关注 我的专题
转载请注明 原文链接:
http://www.jianshu.com/p/635fceca82d3
===============================================
这天,在简书上看到一篇帖子,里边有几张图片觉着挺好看,发出来,一起瞅瞅 :)
标签:
原文地址:http://blog.csdn.net/jasonpeak/article/details/51802711