目录
从零实现ImageLoader（一）—— 架构
从零实现ImageLoader（二）—— 基本实现
从零实现ImageLoader（三）—— 线程池详解
从零实现ImageLoader（四）—— Handler的内心独白
从零实现ImageLoader（五）—— 内存缓存LruCache
从零实现ImageLoader（六）—— 磁盘缓存DiskLruCache
LRU算法
在同步加载与异步加载的实现之后，终于又迎来了图片加载框架的另一个重要特性——内存缓存。至于加入内存缓存原因，之前也已经提到了，主要有以下两点：
- 图片的加载是需要时间的，不论是从网络，还是从磁盘，都会造成应用不同程度的卡顿，而直接从内存中加载就可以避免这种情况。
- 内存的大小并不是无限的，如果一味的将图片放入内存而不加管理，很快就会触发OOM，所以一个好的内存管理也是必不可少的。
而Android就给我们提供了这样一个工具，这就是LruCache。
LRU，全称Least Recently Used，近期最少使用算法，主要是基于如果数据很久没有被访问过，那么它将来被访问的几率也很小的思想。它会优先淘汰掉那些很久都没有被访问的数据，而这也正是内存缓存想要做到的事。
加入内存缓存
我们创建一个新类MemoryCache用来封装LruCache：
public class MemoryCache {
private LruCache<String, Bitmap> mLruCache;
public MemoryCache(int maxSize) {
mLruCache = new LruCache<String, Bitmap>(maxSize) {
@Override
protected int sizeOf(String key, Bitmap value) {
return value.getByteCount();
}
};
}
public Bitmap get(String key) {
return mLruCache.get(key);
}
public void put(String key, Bitmap bitmap) {
mLruCache.put(key, bitmap);
}
}
LruCache的使用非常简单，唯一需要注意的是需要重写sizeOf()方法。sizeOf()是用来计算每条数据的大小的，默认会返回1，也就是每张图片都会被当做1Byte对待，如果不重写，恐怕内存都撑爆了也没有一个图片被淘汰。
现在我们就可以在Dispatcher.get()方法中加入内存缓存代码了：
public Bitmap get() throws IOException {
//从内存获取
Bitmap image = mMemoryCache.get(mKey);
if(image == null) {
image = NetworkUtil.getBitmap(mUrl);
synchronized(mMemoryCache) {
if(mMemoryCache.get(mKey) != null) {
mMemoryCache.put(mKey, image);
}
}
}
return image;
}
get()方法会首先尝试从内存中获取图片，如果没有再从网络上进行下载，并加入内存缓存。这里之所以要加锁重新判断，主要是为了避免有其他线程在我们下载图片时将同样的数据已经加入缓存，导致缓存数据的重复。
这里的key我们选择使用图片URL的MD5值：
private String getKeyByUrl(String url) {
MessageDigest digest;
try {
digest = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException(e);
}
byte[] md5 = digest.digest(url.getBytes());
StringBuilder result = new StringBuilder();
for (byte aMd5 : md5) {
if ((0xFF & aMd5) < 0x10) {
result.append('0').append(Integer.toHexString(0xFF & aMd5));
} else {
result.append(Integer.toHexString(0xFF & aMd5));
}
}
return result.toString();
}
还有一个问题就是图片缓存的大小，一般来说，为了平衡图片缓存的效率与内存的占用，我们都会选择使用1/8内存大小：
private int calculateMemoryCacheSize(Context context) {
ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
int memorySize = activityManager.getMemoryClass() * 1024 * 1024;
return memorySize / 8;
}
这样我们就实现了一个完整的内存缓存方案。
LruCache原理
当然，我们学习LruCache，不仅要知其然，还要知其所以然，下面我们就一起来探索LruCache的实现原理。
LruCache内部维护了一个LinkedHashMap类，所有的数据都是在这个里面存储的：
public LruCache(int maxSize) {
if (maxSize <= 0) {
throw new IllegalArgumentException("maxSize <= 0");
}
this.maxSize = maxSize;
this.map = new LinkedHashMap<K, V>(0, 0.75f, true);
}
而get()和put()的实现也很简单：
public final V get(K key) {
if (key == null) {
throw new NullPointerException("key == null");
}
V mapValue;
synchronized (this) {
mapValue = map.get(key);
if (mapValue != null) {
hitCount++;
return mapValue;
}
missCount++;
}
...
}
public final V put(K key, V value) {
if (key == null || value == null) {
throw new NullPointerException("key == null || value == null");
}
V previous;
synchronized (this) {
putCount++;
size += safeSizeOf(key, value);
previous = map.put(key, value);
if (previous != null) {
size -= safeSizeOf(key, previous);
}
}
...
trimToSize(maxSize);
return previous;
}
为了逻辑的清晰我去掉了一些回调代码，不过剩下的好像除了一些状态记录变量的更新就是对map的put和get了，难道LRU算法的实现都是在最后一句的trimToSize()方法里？
public void trimToSize(int maxSize) {
while (true) {
K key;
V value;
synchronized (this) {
...
if (size <= maxSize) {
break;
}
Map.Entry<K, V> toEvict = map.eldest();
if (toEvict == null) {
break;
}
key = toEvict.getKey();
value = toEvict.getValue();
map.remove(key);
size -= safeSizeOf(key, value);
evictionCount++;
}
...
}
}
依旧是对LinkedHashMap的操作，连获取最久的数据都是使用LinkedHashMap.eldest()方法，原来你是这样的LruCache！看来LRU算法的核心实现都在LinkedHashMap里面了。
LinkedHashMap概览
LinkedHashMap继承自HashMap，所以内部数据的存储方式依然是数组加链表，有所不同的是，LinkedHashMap还单独维护了一个双向循环链表，也正是这个链表赋予了它排序的功能。所以LinkedHashMap里的数据结构看起来就像这样：
上面的虚线箭头就代表着LinkedHashMap内部维护的双向循环链表，需要注意的是这里有一个链表头Header，而Header是一个空节点，且没有存储在Hash表内，只是用来维持链表的正常运作的。
而借助这个双向链表，LinkedHashMap内部实现了两种排序方法，由accessOrder状态控制，当accessOrder为false时会按照数据插入的顺序排序，为true时则会按照数据访问的顺序排序，而这也就是实现LRU算法的关键。
链表节点
要想弄清楚双向链表是怎么实现LRU算法的，我们首先得搞清楚链表节点是怎么实现的：
private static class LinkedHashMapEntry<K,V> extends HashMapEntry<K,V> {
// These fields comprise the doubly linked list used for iteration.
LinkedHashMapEntry<K,V> before, after;
LinkedHashMapEntry(int hash, K key, V value, HashMapEntry<K,V> next) {
super(hash, key, value, next);
}
/**
* Removes this entry from the linked list.
*/
private void remove() {
before.after = after;
after.before = before;
}
/**
* Inserts this entry before the specified existing entry in the list.
*/
private void addBefore(LinkedHashMapEntry<K,V> existingEntry) {
after = existingEntry;
before = existingEntry.before;
before.after = this;
after.before = this;
}
void recordAccess(HashMap<K,V> m) {
LinkedHashMap<K,V> lm = (LinkedHashMap<K,V>)m;
if (lm.accessOrder) {
lm.modCount++;
remove();
addBefore(lm.header);
}
}
...
}
和一般的双向链表节点差不多，LinkedHashMapEntry持有before和after两个节点。而addBefore()方法确保了每个新插入的数据都在老数据的前面。重点则是这里的recordAccess()，该方法会在每次数据被访问的时候调用，如果accessOrder为true，也就是按照数据访问顺序排序，该数据将会被移动到链表的最开始。下面我们就来看看LinkedHashMap到底是不是这样实现的。
get方法
public V get(Object key) {
LinkedHashMapEntry<K,V> e = (LinkedHashMapEntry<K,V>)getEntry(key);
if (e == null)
return null;
e.recordAccess(this);
return e.value;
}
get()方法的逻辑非常简单，调用父类的getEntry()方法获取数据后，再调用recordAccess()方法将元素移动到链表开头，实现了越久没有访问的数据越靠后。
奇怪的put方法
put()方法就比较麻烦了，我在LinkedHashMap里找了一圈也没有找到put()方法的实现，难道LinkedHashMap使用了父类HashMap的put()方法？可这又怎么做到维护双向链表的更新呢？原来HashMap.put()方法在完成数据的插入之后，最终会回调一个createEntry()方法，而LinkedHashMap正是依靠重写这个方法实现的链表更新：
void createEntry(int hash, K key, V value, int bucketIndex) {
HashMapEntry<K,V> old = table[bucketIndex];
LinkedHashMapEntry<K,V> e = new LinkedHashMapEntry<>(hash, key, value, old);
table[bucketIndex] = e;
e.addBefore(header);
size++;
}
就在这个方法里LinkedHashMap用自定义的LinkedHashMapEntry节点替换掉了HashMap创建的HashMapEntry，并且将节点加入到双向链表的开头。
eldest方法
public Map.Entry<K, V> eldest() {
Entry<K, V> eldest = header.after;
return eldest != header ? eldest : null;
}
由于是双向链表，所以header另一边肯定就是最后一个数据了。
至此，整个LRU算法的实现也就呈现在大家眼前了。
