从设计到实现,一步步教你实现Android-Universal-ImageLoader-缓存

转载请标明出处,本文出自: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){}

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

MemoryCahce 的结构图

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拉。

DiskCahce 的结构图

反思

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

阅读更多
文章标签: android 图片加载
个人分类: Universal-ImageLoader
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭