Glide 魔法般的自定义扩展

      使用过Glide的朋友都明白，简单的用法就是：

Glide.with(context)
    .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")
    .into(ivImg);

      而Picasso看起来像是Glide的“兄弟”一样，但Glide的with中提供了多种传递形式，如activity和Fragment，这样设计的目无非是想跟随宿主的生命周期来做事儿。

而且从夹在图片的参数上看默认加载为RGB_565图片，从查找的资料显示RGB_565与ARGB_8888图片相比，在比较普通的手机上肉眼似乎不能区分。

自然RGB_565质量相比较差，运行时占据的内存也是差了不少，这可就是我们的重点啦，有效的减缓了oom机会！如果你仍要使用高质量的图片，那么Glide确实提供了GlideModule方式自定义设置，

在清单文件application中插入meat-data即可：

<meta-data android:name="com.inthecheesefactory.lab.glidepicasso.GlideConfiguration" android:value="GlideModule"/>

 重写GlideModule：

 @Override
    public void applyOptions(Context context, GlideBuilder builder) {//既然拿到了GlideBuilder我们就应该可以做很多事儿啦！ 

//DecodeFormat.PREFER_ARGB_8888 //DecodeFormat.PREFER_RGB_565  builder.setDecodeFormat(。。。); } @Override public void registerComponents(Context context, Glide glide) { }

 没错既然重写了GlideModule，并且拿到了GlideBuilder，如果到此为止的话那自定义的Glide就显得太过于Low啦！

除了上面代码中设置了图片的质量参数外，重头戏就在于这两个方法：

builder.setMemoryCache( new LruResourceCache( customMemoryCacheSize );
builder.setBitmapPool( new LruBitmapPool( customBitmapPoolSize );//关于Lru可以自己了解

 现在可以望文生义，就是用来设置Glide要占用RAM的一个缓存阀值额度。

 方式可选如下：

 1）完全自定义标准

 int maxMemory = (int) Runtime.getRuntime().maxMemory();//获取系统分配给应用的总内存大小
 int memoryCacheSize = maxMemory / 6;//设置图片内存缓存占用整个app的比例

 2）按照Glide默认标准，可以自己在做调整，当然如果你有理由去厌恶内存缓存也可以直接.skipMemoryCache( true )

MemorySizeCalculator calculator = new MemorySizeCalculator(context);
int defaultMSize = calculator.getMemoryCacheSize();  
int defaultBPoolSize = calculator.getBitmapPoolSize();

 在持久化缓存方面Glide也提供的相当ok

builder.setDiskCache(new InternalCacheDiskCacheFactory(context,xxxxxx));
    //使用内部存储和外部存储做缓存时只能二选一
builder.setDiskCache(new ExternalCacheDiskCacheFactory(context,xxxxxx));    

 而且也可以使用DiskLruCacheFactory制定外部路径：

builder.setDiskCache(new DiskLruCacheFactory( Environment.getDownloadCacheDirectory().getPath(), xxxxx));

 如果确定这么做对你有用，那就试试吧！

       在图片加载的优先级需求上，Glide工程师也为我们做好了链式的调用方法，可以说实在是太贴心！

 方法很简单，  load(...).priority( Priority.LOW )和.priority( Priority.HIGH )分别是低权重加载和高权重加载。在同时请求的情况下，设置了高权重加载

 绝大多数情况下会优先加载出来；虽然并不是非常严格的遵守就像onRestoreInstanceState一样谷歌不能保证100%的调用。

       哈哈，说到这里有些兴奋的肚子饿了，Glide提供了.into方法设置宿主ImageView，但实际有很多的应用场景，我们不能够直接去使用ImageView，

 如包装起来的自定义控件；就在这时Glide工程师又将汤勺放到了你的嘴边。

       最后介绍下Glide中提供了ViewTarget和SimpleTarget两种包装的形式，分别开放出Drawable和Bitmap，这使我们直接可以获取到它

转换处理过程的中间产物，示例如下：

//ViewTarget能够支持转换成Drawable

自定义View  custView=new 自定义View(context)

public ViewTarget<自定义View, GlideDrawable> vt = new ViewTarget<自定义View, GlideDrawable>(custView) { 

　　@Override 

　　public void onResourceReady(GlideDrawable resource, GlideAnimation<? super GlideDrawable> glideAnimation) { 
　　　　this.view.自定义View中设置图片的方法(resource.getCurrent()); 
} }; 

Glide .with( context ).load( xxx).into( vt );

private SimpleTarget starget = new SimpleTarget<Bitmap>( 300, 300 ) {  //如果能够预知图片的大小，可以在这里做限制，这会使加载变得又完美了一步！
    @Override
    public void onResourceReady(Bitmap bitmap, GlideAnimation glideAnimation) {
        imageView2.setImageBitmap( bitmap );
    }
};

private void loadImageSimpleTargetApplicationContext() {  
    Glide
        .with( context ).load( xxxx ).asBitmap()
        .into( starget );
}

 以上的两种方式并没有写成into接收new匿名对象的方式，这样into持有全局对象的意义是可以有力的防止匿名对象被GC抹掉！！！