使用过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抹掉！！！