Android知识总结：Universal-Imageloader学习笔记5 一种特殊情况下的图片缓存方式

背景

在最近的项目中，由于后台的特殊要求，每次加载图片时，图片url都会携带一个时间戳，即如下图片格式为这样的形式：http://xxxx/aaaa/cccc.jpg?timestamp 其中问号前面的部分是不变的，而timestamp每次是不同的。换句话说，每次加载图片的url是不同的。也就是说，如果不经过特殊处理，ImageLoader的缓存是没有办法使用的，也就是说所有图片只要显示必须当下下载，也就别提什么用户体验了。

通过抓包了解到，服务端每张图片的url其实是在url的基础上加了一个时间戳，也就是说对于同一张图片，每次下载时其实是在一个固定url的基础上加时间戳构成真的url。换句话说，就是上面那个示例url其实问号前面的部分是不变的，既然有不变的地方，可否为我们所用？

感觉上当然是可以的，实现就需要我们重新分析一下ImageLoader是怎样加载缓存图片的。

加载图片过程

详细过程分析可以参考如下链接http://blog.csdn.net/lidec/article/details/50133533，此处我们只看bitmap是如何被存入与取出缓存的。

由之前的博文可以知道，下载的主要业务逻辑存在于ImageLoader的displayImage方法。

图片的缓存分为内存缓存（memoryCache）和硬盘缓存（diskCache），如果我们能找到url与缓存索引的对应关系，我们就可以直接将url中固定不变的部分拿出来，用这部分生成索引，然后当我们查找缓存中的索引时，直接使用固定不变那部分url生成索引。总之，就是用url中不带时间戳的部分来作为取缓存的依据，这样，不管后面时间戳怎么变化，我们都能得到唯一的图片。

通过分析源码可知，图片内存缓存的索引生成方式如下：

String memoryCacheKey = MemoryCacheUtils.generateKey(uri, targetSize);
......
Bitmap bmp = configuration.memoryCache.get(memoryCacheKey);

        通过图片的uri与大小，经过一定的算法生成内存缓存索引，然后通过这个索引就可以在缓存中获取bitmap

当内存中不存在缓存时，我们就需要从硬盘中获取。在前文分析配置文件时候，我们发现ImageLoader中为我们提供了一个FileNameGenerator接口，通过重写这个接口可以实现我们对硬盘缓存文件的自定义命名。所以，我们可以通过实现自己的FileNameGenerator，来截取我们所需要的有效url，并使用一定的算法生成我们的命名。是不是这样呢，我们看看源码。

 //尝试在文件中加载  
        File imageFile = configuration.diskCache.get(uri);  
        if (imageFile != null && imageFile.exists() && imageFile.length() > 0) {  
            ......  
            //从文件中解码图片  
            bitmap = decodeImage(Scheme.FILE.wrap(imageFile.getAbsolutePath()));  
        }  
    我们可以看看diskCache的get(uri)是怎么做的。

    protected File getFile(String imageUri) {
        String fileName = this.fileNameGenerator.generate(imageUri);
        File dir = this.cacheDir;
        if(!this.cacheDir.exists() && !this.cacheDir.mkdirs() && this.reserveCacheDir != null && (this.reserveCacheDir.exists() || this.reserveCacheDir.mkdirs())) {
            dir = this.reserveCacheDir;
        }

        return new File(dir, fileName);
    }
    可见，里面是调用fileNameGenerator来生成的文件名，而解码文件时，用到的file就是这个文件民对应的file，所以，我们只需要实现自己的fileNameGenerator，将时间戳部分截取掉，用其余部分生成文件名，就可以实现uri的固定。

两个实际问题
   
   
   
   

    
    
    
     
    
    
    
    原理就是这样，而让人蛋疼的问题还在后面，首先，要修正以前博客配置ImageLoder文章的一个bug，经过试验，在config中设置fileNameGenrator是无效的。如下
   
   
   
   
   
   
   
   

    
    
    
    
    
    
    
    
config.diskCacheFileNameGenerator(new MyHashCodeNameGenerator());
    
    
    
    
    这么写就扯了dan了，其实打开缓存文件夹，里面根本不是按照你的规则生成的文件名，而是默认的hashcode生成。通过阅读源码，我发现必须在设置diskCache类型的时候传入将Generator构造函数，这样才能有效设置。代码如下：
    
    
    
    

   
   
   
   
   
   
   
   

    
    
    
    
    
    
    
    
ImageLoaderConfiguration.Builder config = new ImageLoaderConfiguration.Builder(context);
         ......
        config.diskCache(new BaseDiskCache(new File(FileUtils.getImageDir()), null, new MyHashCodeNameGenerator()) {
        });
        //config.diskCacheFileNameGenerator(new MyHashCodeNameGenerator());    这个没用
        ImageLoader.getInstance().init(config.build());
    
    
    
    
    第二坑是我一开始直接截取字符串后，用这个字符串的hashcode作为文件名返回，后来发现对于相同的字符串，返回的hashcode是不一样的。所以，是时候回头看看java基础了............. 然后我开始参照原文件中的MD5NameGenerator进行了实现，MD5加密只和字符有关系，只要传入相同字符串，返回值必定相同，所以只是对问号前的部分进行MD5编码并返回字符串。代码如下
   
   
   
   
   
   
   
   

    
    
    
    
/**
 * Created by vonchenchen on 2016/1/6 0006.
 */
public class MyHashCodeNameGenerator 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 s) {

        String urlHeader = s.split("[?]")[0];
        byte[] md5 = getMD5(urlHeader.getBytes());
        BigInteger bi = new BigInteger(md5).abs();
        return bi.toString(RADIX);

        //String urlHeader = s.split("[?]")[0];    //这样写虽然截取后url一样，但是生成的hashcode每次不同
        //return String.valueOf(s.hashCode());
    }

    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;
    }
}
    
    
    
    
 这样，我们就在不改变ImageLoader源码的情况下，为程序增加了硬盘缓存，节省了流量，也使图片加载更为流畅。问题有点烦人，原理其实很简单，实现也走了些弯路，总结经验，稳步前进。