浅谈开源项目Android-Universal-Image-Loader(Part 3.1)

来源:互联网 发布:多进程 python windows 编辑:程序博客网 时间:2024/03/29 14:29

最近,在办离职手续,相对来说,比之前一年多忙碌的外包闲了许多。总算有时间去做些平时喜欢而没空去做的事情。一直觉得项目中使用的Image Loader适用性不强,昨晚在github随便逛逛,发现一个开源项目Android-Universal-Image-Loader十分火热。代码并不十分复杂,却写的不错,决定记录和分享一下。

  Android-Universal-Image-Loader是一个针对图片加载、缓存的开源项目。github: https://github.com/nostra13/Android-Universal-Image-Loader

  @author nostra13频繁的更新记录来看,Android-Universal-Image-Loader的后期维护比较好。从Applications using Universal Image Loader来看,还是相当强大的,如:EyeEm Camera, UPnP/DLNA Browser, Facebook Photo/Album,淘宝天猫,京东商城等。到底有何种魅力让大家纷至沓来?

   

01. 项目包结构

图 1

 

  去掉无实际意义的包名:com.nostra13.universalimageloader,一切变显得比较清楚了。

  (1)cache主要是磁盘缓存及内存缓存预定的接口和常规实现类,包含的算法较多(并不复杂),如FIFO算法、LRU算法等。

  (2)core明显是整个Image Loader的核心包,图片下载、适配显示,并向上层应用提供各种接口,默认模板,还包括很多关键枚举类、工具类。

  (3)utils比较简单些,常规工具类,如ImageSizeUtils、StorageUtils等。

 


 

02. 文件存储策略

  针对手机,流量、电量及体验的要求,不断向网络发起重复的请求,都是不恰当的。常规存储方式包括:文件存储、数据库存储、SharedPreference、云存储(网络存储)及保存至内存等几种手段。显然,需要在本地进行持久化,就图片而已,以文件的方式保存无疑是最好的选择。至此,完成了云端-->本地的持久化,但是如果简单的每次都去”本地存储“请求,请求不到再到云端请求,无疑无法解决频繁请求图片所需要的速度和体验。请记住,用户对图片的渴望程序是相当高,试想一下,ListView上下滚动时,每次直接到”本地存储“请求时,整个界面多处在Loading,显然体验效果比较一般。因此,图片一般都会存储至内存中。从内存中读取图片的速度比本地加载的快得多,体验也会更好。这就是平时通常说的三步:内存-->本地文件-->云端。

  在Android-Universal-Image-Loader,单纯从包结构上就可以看出,cache.disc是负责硬盘存储,而cache.memory是负责内存存储的(ps.具体存储实现方式还是在core包内)。而网络请求应该在core.download中,core包在Part3.2会深入分析。

  事实上,我们似乎忽略了一些东西,如果我发起请求的是本地图片呢?如果是R.drawable.*的图片呢?优点1:Android-Universal-Image-Loader设计得比较细致,在ImageDownloader接口枚举类Scheme,明确指出所支持的请求类型:

HTTP("http"), HTTPS("https"), FILE("file"), CONTENT("content"), ASSETS("assets"), DRAWABLE("drawable"), UNKNOWN("");

  021. 存储空间、时间、数量策略

    在cache.disc下,有着比较完整的存储策略,根据预先指定的空间大小,使用频率(生命周期),文件个数的约束条件,都有着对应的实现策略。最基础的接口DiscCacheAware和抽象类BaseDiscCache。简单类图如下:

图2

  从类图中,明显可以看出,整个disc存储的实现方式有四种:文件总数,文件总大小(或目录),生命周期,无限制(即空间、时间维度的限制)。分析重点,是接口/抽象类。

复制代码
public interface DiscCacheAware {    /**     * This method must not to save file on file system in fact. It is called after image was cached in cache directory     * and it was decoded to bitmap in memory. Such order is required to prevent possible deletion of file after it was     * cached on disc and before it was tried to decode to bitmap.     */    void put(String key, File file);    /**     * Returns {@linkplain File file object} appropriate incoming key.<br />     * <b>NOTE:</b> Must <b>not to return</b> a null. Method must return specific {@linkplain File file object} for     * incoming key whether file exists or not.     */    File get(String key);    /** Clears cache directory */    void clear();}
复制代码

  具体看英文注释,比较好理解,此处就不翻译了。

  

  022. 图片文件的命名

  如果你是心思细腻的用户,在图片浏览器中是否会经常看到一些小图片甚至于广告图片。在一定程序上,本人挺鄙视这些图片来源的应用。为什么把一些临时下载的图片,并无实际意义的图片,占据如此重要的位置。对此,我只想说:我会直接删掉这个目录,如果知道是哪个应用的话,估计我也会卸载。我不禁猜想:如果所有应用缓存的图片,都是可以被媒体库扫描出来的话,这是什么境况呢?慢,肯定的。

  因此,图片保存时,以什么样的文件名进行存储是相当重要的。这个必须要根据需求进行定制生成的策略。举三个例子:

  (1)如果要做一个“云相册”,保存图片后,当然希望能够使用“美图秀秀”、“相机360”等进行编辑。

  (2)如果要做一个“淘宝客户端”,所有浏览过的商品图片都存储,并可被其它图片浏览器感知,这似乎不恰当吧。

  (3)如果要做一个“私密相册”,保存本地的图片,自然不希望别人去感知。

  结论:用户有意识去保存的图片,应该可被感知;用户无意识缓存的图片,不应该被“外界”感知,但也有例外如第3种。当然,第三种权限的控制也是可行的。

  Android-Universal-Image-Loader在保存图片时,需要一个FileNameGenerator(译:文件名生产者)。抽象类BaseDiscCache中存在两个构造器:

复制代码
    public BaseDiscCache(File cacheDir) {        this(cacheDir, DefaultConfigurationFactory.createFileNameGenerator());    }    public BaseDiscCache(File cacheDir, FileNameGenerator fileNameGenerator) {        if (cacheDir == null) {            throw new IllegalArgumentException(String.format(ERROR_ARG_NULL, "cacheDir"));        }        if (fileNameGenerator == null) {            throw new IllegalArgumentException(String.format(ERROR_ARG_NULL, "fileNameGenerator"));        }        this.cacheDir = cacheDir;        this.fileNameGenerator = fileNameGenerator;    }
复制代码

  DefaultConfigurationFactory提供默认文件名生产者为HashCodeFileNameGenerator,默认实现比较简单:返回字符串的hashCode。

  核心类图:

图3

  Md5FileNameGenerator相关原理可查询MD5加密算法,JDK自带类java.security.MessageDigest。

 


 

03. 内存存储

  这部分涉及的知识面比较多,算法、链表、堆栈、队列、泛型等。Android-Universal-Image-Loader在“开闭原则”上做得很好,接口简洁、实用,基于接口,都可以自行扩展功能。

  直接看下接口MemoryCacheAware的定义:

复制代码
public interface MemoryCacheAware<K, V> {    /**     * Puts value into cache by key     *     * @return <b>true</b> - if value was put into cache successfully, <b>false</b> - if value was <b>not</b> put into     *         cache     */    boolean put(K key, V value);    /** Returns value by key. If there is no value for key then null will be returned. */    V get(K key);    /** Removes item by key */    void remove(K key);    /** Returns all keys of cache */    Collection<K> keys();    /** Remove all items from cache */    void clear();}
复制代码

  如果不熟悉泛型的话,建议复习一下,或者直接把MemoryCacheAware<K, V>当MemoryCacheAware<String, Bitmap>看,会方便些。

  核心类图:

图4

  大体结构上以文件存储比较相近,关键性的区别在于BaseMemoryCache子类使用的都是WeakReference(弱引用),FuzzyKeyMemoryCache、LimitedAgeMemoryCache、LruMemoryCache使用的是强引用。本节对内存存储方式,比较关键的概念:强引用、软引用、弱引用及虚引用。

  回顾:

  (1)StrongReference(强引用)

    强引用就是平时经常使用的,如常规new Object()。如果一个对象具有强引用,那垃圾回收器绝不会回收。内存不足,甚至出现OOM时,也不会随意回收强引用的对象。

  (2)SoftReference(软引用)

    在内存空间足够,垃圾回收器不会回收它;如果内存空间不足,垃圾回收器就会回收软引用的对象。

  (3)WeakReference(弱引用)

    弱引用相对软引用,具有更短暂的生命周期。常规的GC,只要被扫描到,都会直接被回收。

  (4)PhantomReference(虚引用)

    虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。没用过。。。

  选其一FIFOLimitedMemoryCache进行分析,构造时,必须要指定大小(单位:字节)。当设置的大小超过16MB(Android默认分配的大小好像也是这个)时,会有警告。

复制代码
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);        }    }
复制代码

 而FIFOLimitedMemoryCache的实现也相对简单,只要你清楚FIFO的基本概念:先进先出。

复制代码
public class FIFOLimitedMemoryCache extends LimitedMemoryCache<String, Bitmap> {    private final List<Bitmap> queue = Collections.synchronizedList(new LinkedList<Bitmap>());    public FIFOLimitedMemoryCache(int sizeLimit) {        super(sizeLimit);    }    @Override    public boolean put(String key, Bitmap value) {        if (super.put(key, value)) {            queue.add(value);            return true;        } else {            return false;        }    }    @Override    public void remove(String key) {        Bitmap value = super.get(key);        if (value != null) {            queue.remove(value);        }        super.remove(key);    }    @Override    public void clear() {        queue.clear();        super.clear();    }    @Override    protected int getSize(Bitmap value) {        return value.getRowBytes() * value.getHeight();    }    @Override    protected Bitmap removeNext() {        return queue.remove(0);    }    @Override    protected Reference<Bitmap> createReference(Bitmap value) {        return new WeakReference<Bitmap>(value);    }}
复制代码

  在removeNext()方法中,可以看到每次都是移除队列中的第一个对象。

  


 

  Part3.1就此结束。

  原来,用心写一篇文章,还是相当的困难。前前后后,走读,分析,类图,补充部分遗漏的知识点,足足用了半天的时间。不过,收获良多。

  Part3.2主要是对core包中的下载设计技巧进行分析、研究,core.assist、core.display只会简单过一下。

  Part3.3重在如何在实际项目中运用Android-Universal-Image-Loader,如何自行扩展部分功能。

 

  估计,Part3.2/3.3会晚些日子才会更新,后面会对自己做的一些项目进行一定的总结。希望大家多多支持。

  有任何问题,请邮件至:Osmondy@sina.com 

0 0
原创粉丝点击