转载请标明出处，本文出自：chaossss的博客

Android-Universal-ImageLoader Github 地址

Cache

我们要对图片进行缓存，有两种方式：内存缓存和本地缓存。这两种方式的区别在于，内存缓存是缓存在 Android 系统为应用分配的运行内存之中，读取速度快，但是可能会带来 OOM 的问题；本地缓存一般缓存在 SD 卡中，读取速度较慢，但是缓存空间足。

那么我们要怎么来实现内存缓存和本地缓存呢？根据单一职责原则，如果 MemoryCache 和 DiskCache 的抽象不一致的话，我们就需要分别创建 MemoryCache 和 DiskCache 的抽象基类，分别实现各自的细节。而显然，两者抽象是不一致的，因为 MemoryCache 面对的对象是图片（Bitmap），DiskCache 面对的对象是文件（File）。因此，我们应该分开实现 MemoryCache 和 DiskCache。

MemoryCache

MemoryCache 整体设计及相关基类的实现

那我们现在该干啥呢？想 MemoryCache 的功能啊！对于进行内存缓存我们能想到什么应用场景呢：

1. 首先每一个 MemoryCache 肯定有相应的增删取功能
2. 当 MemoryCache 被存满了（Android 应用的内存资源是很宝贵的），我们该怎么处理呢：
   
   • 回收最近没有用过的
   • 回收最早在内存中缓存的
   • 回收使用频率最低的
   • 在缓存时，key 相同的图片，回收旧的图片，缓存新的图
3. 有时候我们可能需要缓存高分辨率的高清图片，而这种图片非常大，缓存到内存中就会 OOM，在这种情况下，为了让应用能正常运行，我们应该能在缓存时限制图片的大小

我就想到这么多哈，肯定还会有很多不一样的情况，毕竟需求是层出不穷的……那么根据现在得到的应用场景，我们就要开始设计 MemoryCache 啦。根据分析得到的结果我们可以发现：内存缓存有不一样的缓存策略和缓存限制，但是具有相同的抽象。所以我们首先需要实现 MemoryCache 的抽象：

public interface MemoryCache {

    boolean put(String key, Bitmap value);

    Bitmap get(String key);

    Bitmap remove(String key);

    Collection<String> keys();

    void clear();
}

实现了抽象，就得开始考虑具体实现拉。我们刚刚也说了，MemoryCache 具有不同的缓存策略和缓存限制，策略不一样的实现类一般不会存在继承关系，而具有相同限制的 MemoryCache 则可能存在抽象。那么我们可以得到：

public abstract class BaseMemoryCache implements MemoryCache

public abstract class FuzzyKeyMemoryCache implements MemoryCache

public abstract class LruMemoryCache implements MemoryCache

很多人会奇怪了，为什么 LruMemoryCache 和 FuzzyKeyMemoryCache 不是继承于 BaseMemoryCache 呢？我们不妨想象为什么需要 BaseMemoryCache，我们之所以引入 BaseMemoryCache，是因为限制不同的 MemoryCache 具有相同的抽象，在 AUImgLoader 中，不同的限制体现在：缓存图片的大小限制和缓存图片的引用方式限制。

有关引用的知识可以看这Java中的强引用、软引用、弱引用和虚引用

所以，在 BaseMemoryCache 的实现中，我们添加了对应的抽象方法：

protected abstract Reference<Bitmap> createReference(Bitmap value);

反观 LruMemoryCache，我在深入源码剖析LruCache中给大家讲解过 LruCache 的原理，我们在 LruMemoryCache 中进行缓存，是只使用强引用进行缓存的，换言之，LruMemoryCache 的抽象和 BaseMemory 的实现是不一样的，因为 BaseMemoryCache 中多了一个 createReference() 抽象方法，而 LruMemoryCache 不需要这个抽象方法。

而 FuzzyKeyMemoryCache 是一个只考虑缓存策略的内存缓存类，它只考虑怎么去处理 key 相同的图片，具体你用什么方式实现，就由开发者自己决定，因为 FuzzyKeyMemory 的处理方法都是调用抽象接口完成的（源码我就不放了哈，大家可以自己下载）

BaseMemoryCache

经过刚刚的分析，我们得到了 MemoryCache 的三个基类：BaseMemoryCache、LruMemoryCache、FuzzyKeyMemoryCache。接下来，我们就来根据 BaseMemoryCache 实现我们想要的细节。

我们已经提到，BaseMemoryCache 是用于处理缓存限制的基类，而所谓的限制体现在：限制大小和限制引用方式。那么很显然，引用方式只有强引用、弱引用值得我们进行区分（Android 2.3 已经不鼓励开发者使用软引用了，因为在进行垃圾回收时软引用和弱引用都具有被回收的倾向），所以我们可以得到下面两个实现类：

public abstract class LimitedMemoryCache extends BaseMemoryCache

public class WeakMemoryCache extends BaseMemoryCache

千呼万唤始出来，我们最终的细节实现类 LimitedMemoryCache 终于出现了……在 LimitedMemoryCache 中，我们将使用强引用缓存图片，那么，LimitedMemoryCache 还需要提供的就是图片大小的限制：

public LimitedMemoryCache(int sizeLimit) {
        this.sizeLimit = sizeLimit;
        cacheSize = new AtomicInteger();
        if (sizeLimit > MAX_NORMAL_CACHE_SIZE) {
            L.w("You set too large memory cache size (more than %1$d Mb)", MAX_NORMAL_CACHE_SIZE_IN_MB);
        }
    }

剩下的，就是根据我们的缓存策略对 LimitedMemoryCache 进行拓展啦。

MemoryCahce 的工具类

那么经过刚刚的努力，我们现在已经能过在内存中进行缓存，即使 AUImgLoader 自带的缓存实现类不能满足我们的需求，由于 AUImgLoader 的内存缓存功能模块是通过装饰者模式架构的，我们要对已有的类进行拓展也是很简单的。但是现在内存缓存模块只是提供了必要的“内存缓存功能”，我们还需不需要其他的工具来简化我们的使用呢？

大家不妨想想，我们加载了一些尺寸较小的图片在内存中，它们占用的总内存并不大，还不需要将它们缓存到本地，但我们仍需要对它们进行细粒度的管理（否则当图片数量增多，内存空间不够时我们对图片的处理会带来各种问题）。那么我们就需要一个工具类协助我们进行内存缓存的管理，不妨创建一个叫做 MemoryCacheUtils 的类：

public final class MemoryCacheUtils {

    private MemoryCacheUtils() {
    }
}

大家会注意到这个类将是一个无法被继承的类，也无法通过构造方法获得实例对象。毕竟一方面，这个工具类不需要重复创建实例对象，只需要调用类去执行方法就行了；另一方面，工具类并不需要继承，需要什么添加进去就行了。

这里说 MemoryCacheUtils 无法创建实例对象是指一般情况下无法创建，实际上如果使用 Java 的反射机制的话还是可以创建对象的。

那么这个类要帮我们完成什么工作呢？分析实际的使用场景，我们可以得到：

1. 为即将加入内存缓存的图片生成相应的键
2. 使用 Comparator 判断键是否相等时，可能出现不同的 Uri 生成的键相同的情况，此类需要提供方法解决这个问题
3. 当你输入一个 Uri 时可能会在内存缓存中找到多个响应图片，所以方法类应返回响应图片列表
4. 当你输入一个 Uri 时可能会在内存缓存中找到多个已缓存的键，所以方法类应返回键列表
5. 将对应输入 Uri 的所有缓存图片从内存中移除

public static String generateKey(String imageUri, ImageSize targetSize){}

public static Comparator<String> createFuzzyKeyComparator(){}

public static List<Bitmap> findCachedBitmapsForImageUri(String imageUri, MemoryCache memoryCache){}

public static List<String> findCacheKeysForImageUri(String imageUri, MemoryCache memoryCache){}

public static void removeFromCache(String imageUri, MemoryCache memoryCache){}

具体实现我就不在这多说拉，大家可以自行查看源码进行阅读，里面的逻辑并不难。

MemoryCache 结构图

经过上面的设计和代码实现，我们在 AUImgLoader 中得到下面这张内存缓存功能模块的整体结构图：

做图的时候 BaseMemoryCache 的 createReference() 方法忘了加进去了，大家见谅哈……

DiskCache

DiskCache 整体设计及相关基类的实现

实际上 DiskCache 的设计思想和 MemoryCache 是非常接近的，我们只要遵循刚刚的思路就可以拉。那么首先需要实现 DiskCache 的抽象：

public interface DiskCache {
    File getDirectory();

    File get(String imageUri);

    boolean save(String imageUri, InputStream imageStream, IoUtils.CopyListener listener) throws IOException;

    boolean save(String imageUri, Bitmap bitmap) throws IOException;

    boolean remove(String imageUri);

    void close();

    void clear();
}

然后获得两个基类：

public class LruDiskCache implements DiskCache

public abstract class BaseDiskCache implements DiskCache

同样的，我们根据缓存的限制实现 BaseDiskCache 的细节,就可以完成本地缓存功能模块拉

DiskCache 的辅助工具类

虽然 DiskCache 整体设计和实现都挺简单的，但是大家还需要考虑到一个问题，就是我们每一张图片缓存到本地之后都需要为其命名，那么我们就应该为其实现相关的命名类咯。能够区分每一张图片的命名方式无非就是：哈希和MD5,引用网上一张图，我们应该设计一个文件命名功能模块，提供给 DiskCache 使用：

那么首先实现命名类的抽象：

public interface FileNameGenerator {
    String generate(String imageUri);
}

然后分别实现细节就可以拉：

public class HashCodeFileNameGenerator implements FileNameGenerator {
    @Override
    public String generate(String imageUri) {
        return String.valueOf(imageUri.hashCode());
    }
}

public class Md5FileNameGenerator implements FileNameGenerator {

    private static final String HASH_ALGORITHM = "MD5";
    private static final int RADIX = 10 + 26; // 10 digits + 26 letters

    @Override
    public String generate(String imageUri) {
        byte[] md5 = getMD5(imageUri.getBytes());
        BigInteger bi = new BigInteger(md5).abs();
        return bi.toString(RADIX);
    }

    private byte[] getMD5(byte[] data) {
        byte[] hash = null;
        try {
            MessageDigest digest = MessageDigest.getInstance(HASH_ALGORITHM);
            digest.update(data);
            hash = digest.digest();
        } catch (NoSuchAlgorithmException e) {
            L.e(e);
        }
        return hash;
    }
}

DiskCache 的工具类

DiskCache 除了在进行本地缓存时需要工具类帮助其生成文件名，还需要工具类帮它完成其他工作：本地缓存管理、本地存储策略等……于是我们需要引入多个工具类协助完成这些职责。

大家需要注意到的是，工具类和辅助工具类将处于不同的包中，因为辅助工具类是完成职责必不可少的一环。而工具类是减少使用者的使用成本，两者间的差别使得类所在的包不一致。

DiskCacheUtils

和 MemoryCacheUtils 一样，DiskCacheUtils 也是一个无法被继承，无法创建实例对象的类。

public final class DiskCacheUtils {

    private DiskCacheUtils() {
    }
}

这个工具类的主要使用场景为：

1. 找到 Uri 对应的本地缓存文件
2. 移除 Uri 对应的本地缓存文件

所以我们分别实现对应的方法就可以拉：

public static File findInCache(String imageUri, DiskCache diskCache){}

public static boolean removeFromCache(String imageUri, DiskCache diskCache){}

StorageUtils

为了将图片存储到本地 SD 卡中，我们需要获得本地缓存对应的目录，于是引入了 StorageUtils 负责完成相关的事项。由于工具类都是无法继承和创建对象的类，我就不再放出响应的构造方法和类声明了。在 StorageUtils 中，我们可能存在的使用场景有：

1. 获得本地缓存目录
2. 新建额外的本地缓存目录
3. 为某些图片提供对应的特定缓存目录
4. 为单个图片提供缓存目录

实现各自对应的方法，就OK拉。

DiskCache 结构图

经过上面的设计和代码实现，我们在 AUImgLoader 中得到下面这张内存缓存功能模块的整体结构图：

反思

大家会发现，无论是 DiskCache 还是 MemoryCache，还是它们的工具类，代码结构清晰，类间耦合度低，许多开发者看到这样的代码都会感叹：这代码写得真漂亮。但我相信观察力敏锐的同学会一眼看出，MemoryCache 和 DiskCache 都使用了装饰者模式进行设计，功能的拓展只要针对对应的抽象进行“装饰”就可以了；工具类则严格遵循设计模式中的设计原则，尽可能独立不同的工具模块。所以大家在开发的时候也应该注意这些开发细节，不断重构代码，让代码结构变得清晰。