博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Image-Loader LruMemoryCache
阅读量:6383 次
发布时间:2019-06-23

本文共 3348 字,大约阅读时间需要 11 分钟。

这段时间在研究Universal-Image-Loader 这个图片处理开源框架,这里主要分析一下它的LRU(Least Resently Used,最近最少使用)内存缓存的实现。 

在UIL它提供的默认缓存类是LruMemoryCache,在它类上面有如下一段注释:

/** * A cache that holds strong references to a limited number of Bitmaps. Each time a Bitmap is accessed, it is moved to * the head of a queue. When a Bitmap is added to a full cache, the Bitmap at the end of that queue is evicted and may become eligible for garbage collection.
* NOTE: This cache uses only strong references for stored Bitmaps. */

说明该缓存存储的是强引用的Bitmap对象,同时每当一个bitmap被访问之后,它就会被放到队列的头部,当队列满了需要删除元素时,就会删除队尾的元素,让它变成可以被垃圾回收器回收的对象。 

在LruMemoryCache中声明了三个全局变量:

private final LinkedHashMap
map;//存放对象的map容器private final int maxSize; //缓存设定的最大值 /** Size of this cache in bytes */ private int size; //缓存中已经占有的大小

它的构造数也同样简单:

public LruMemoryCache(int maxSize) {        if (maxSize <= 0) { throw new IllegalArgumentException("maxSize <= 0"); } this.maxSize = maxSize; this.map = new LinkedHashMap
(0, 0.75f, true); }

这里传进来的maxSize参数在默认的情况下是程序进程占用内存总数的八分之一,单位是Byte。 

根据Key值获取对应的bitmap对象,代码超简单:

/**     * Returns the Bitmap for {@code key} if it exists in the cache. If a Bitmap was returned, it is moved to the head     * of the queue. This returns null if a Bitmap is not cached.     */    @Override    public final Bitmap get(String key) { if (key == null) { throw new NullPointerException("key == null"); } synchronized (this) { return map.get(key); } }

存储bitmap对象:

@Override    public final boolean put(String key, Bitmap value) {        if (key == null || value == null) { throw new NullPointerException("key == null || value == null"); } synchronized (this) { size += sizeOf(key, value); //调用sizeOf这个函数获得该bitmap对象的占用内存的大小,并且让缓存总数增加 Bitmap previous = map.put(key, value);//这里就是把对象放入容器中的最核心的一句代码,如果容器中已经有了此元素,则返回该元素的value值,否则返回空 if (previous != null) { size -= sizeOf(key, previous);//如果容器中已经有了此元素,则需要把增加的数量减掉 } } trimToSize(maxSize); //此函数计算是否超出最大限量,是则删除队尾元素 return true; }

这里涉及到两个函数: 

获取图片大小的函数

private int sizeOf(String key, Bitmap value) {        return value.getRowBytes() * value.getHeight(); }

保证缓存内存量不超过设定的最大值

private void trimToSize(int maxSize) {        while (true) { String key; Bitmap value; synchronized (this) { if (size < 0 || (map.isEmpty() && size != 0)) { throw new IllegalStateException(getClass().getName() + ".sizeOf() is reporting inconsistent results!"); } if (size <= maxSize || map.isEmpty()) { break; } Map.Entry
toEvict = map.entrySet().iterator().next(); if (toEvict == null) { break; } key = toEvict.getKey(); value = toEvict.getValue(); map.remove(key); size -= sizeOf(key, value); } } }

此外,该类还有一个移除特定key的元素的方法:

/** Removes the entry for {@code key} if it exists. */    @Override    public final Bitmap remove(String key) { if (key == null) { throw new NullPointerException("key == null"); } synchronized (this) { Bitmap previous = map.remove(key); if (previous != null) { size -= sizeOf(key, previous); } return previous; } }

至此整个缓存类就已经解析完了,你会发现其实代码超简单的,其中一个最重要的东西就是存放键值对的容器–LinkedHashMap。LinkedHashMap实现了Map接口,并且具有链表的特性,即有可预知的迭代顺序。通常在默认的情况下,该集合的迭代顺序是按照插入元素的顺序,先插入的元素在队尾,最后插入的在头部;然而当我们调用LinkedHashMap的构造函数LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder) ,并传入accessOrder的值为true时,LinkedHashMap就会按照访问先后的顺序迭代,最近被访问的放在队头,最迟访问的在队尾。正是因为这个特性,LinkedHashMap很适合被用来作为LRU缓存的容器。因此有了LinkedHashMap这个神器,我们完全可以仿照UIL的缓存类构建自己的缓存!

转载地址:http://sgwha.baihongyu.com/

你可能感兴趣的文章
字符串拼接引发的BUG
查看>>
RocketMQ源码解析:定时消息与消息重试
查看>>
Java中atomic包中的原子操作类总结
查看>>
攻击JavaWeb应用[4]-SQL注入[2]
查看>>
Android 源码分析(一)项目构建过程
查看>>
iOS 网络编程(一)TCP IP协议简介
查看>>
React在线编辑简历
查看>>
七牛大数据平台的演进
查看>>
可能是全网最全的移动直播 trouble shooting 手册(6)——马赛克严重
查看>>
iOS开发笔记(四):frame与bounds的区别详解
查看>>
iOS--collectionView简单瀑布流的实现
查看>>
我想,我需要试试
查看>>
app异常处理
查看>>
Redis 中三种特殊的数据类型
查看>>
Python篇-绘图
查看>>
Cris 的 Spark SQL 笔记
查看>>
Computer Vision 杂志对何恺明 Rethinking ImageNet Pre-training 的最新评论
查看>>
阿里云支付:可以更换绑定的支付宝账号吗?
查看>>
学web前端从哪里开始学起呢-好程序员
查看>>
5G网络数据中心系统需要什么光模块?
查看>>