Local image load library,less class,less method

一，先交代为什么自己写这个加载器

Facebook 的 Fresco 作为图片加载工具，由于其出色的内存管理和功能的完善性，是很多项目图片加载库的首选。但是在做 RecyclerView 记载本地图片时，Fresco 在这种应用场景中表现并不出色，具体表现为：每次加载 RecyclerView 的一个 item 时都需要花费较长的时间，即使在设置了内存缓存和磁盘缓存的情况下。对比发现 Glide 对这种应用场景的支持比较好。通过对比两个库实现方式的差异发现：Glide 会缓存裁剪后的图片，但是 Fresco 只缓存原图，所以每次加载 RecyclerView 的 item 时都需要进行裁剪，这部分操作十分耗时，并且 Fresco 并没有暴露缓存相关的配置项。

二，总体流程：

所有图片加载库基本都是一个套路：

1. 从内存缓存中加载
2. 从磁盘缓存中加载
3. 从网络/磁盘中加载，并处理成需要的资源（一般是 bitmap）

LocalImageLoader 也不列外，但是有以下基础细微区别：

1. 使用 LRU 算法，总内存是 16Mb 作为第一道内存缓存，这部分缓存持有 bitmap 强引用，使被引用的 bitmap 对象不会被轻易回收
2. 使用 WeakReference 的第二道内存缓存，保持 bitmap 的弱引用，如果有新产生的 bitmap,就放入此缓存中，使用 WeakReference，减少发生 OOM 的情况，通过实测发现，通过 WeakReference 缓存的图片极易被回收。
3. 考虑到我们的使用场景以及裁剪后图片的体积，没有对磁盘缓存做限制。
4. 处理 Bitmap 的方式是居中裁剪，并且没有提供其他处理方式的配置，如果有需要，这部分可以抽取出来。

三，相关 API 介绍这部分，主要是为了以后扩展功能考虑，我将以后可能变动的实现都做了抽象，具体如下：

1. MemoryCache 内存缓存的抽象，负责 Bitmap 的回收与获取，子类有 DefaultMemoryCache。但是 LruMemoryCache 没有继承此类
2. DiskCache 磁盘缓存的抽象
3. Decoder 文件加载与 bitmap 的处理的抽象，如果发现有可以提高文件加载效率与 Bitmap 处理效率的方法，可以实现此类。
4. XXManager,这部分主要是对相关 API 进行管理的类。 这部分更加详细的可以看代码。

四，代码结构正在完善中，将就着看，有问题有 issue 直接提