图片加载框架Glide，Picasso fresco volley imageloader Universal Image Loader的比较

glide(底层)：HttpUrlConnection

Glide的网络请求部分可以使用当前最流行的网络请求框架Volley或OkHttp，也可以通过Glide的ModelLoader接口自己写网络请求。 
Glide默认使用HttpUrlConnection进行网络请求

Google推荐的图片加载库，专注于流畅的滚动。

1.优点 
1）使用RGB_565，内存占用比Picasso小一半。 
2）图片展示和页面的生命周期一致（对context有类型要求） 
3）相比Picasso，Glide在缓存策略和加载GIF方面略胜一筹 
减少了缓存文件的大小 
Picasso和Glide在磁盘缓存策略上有很大的不同。Picasso缓存的是全尺寸的，而Glide缓存的是跟ImageView尺寸相同的。 这样在下次显示的时候不需要重新调整大小，显示的会更快。 
4）在页面不可见时停止网络请求，停止对图片的解析操作。 
5）专注于流畅的滚动 
6）当列表在滑动的时候，调用pauseRequests()取消请求，滑动停止时，调用resumeRequests()恢复请求。这样是不是会好些呢？ 
7）支持当你想清除掉所有的图片加载请求时 
8）同时因为Glide和Activity/Fragment的生命周期是一致的，因此gif的动画也会自动的随着Activity/Fragment的状态暂停、重放。Glide 的缓存在gif这里也是一样，调整大小然后缓存。 
9）支持gif 
但是从我的一次测试结果来看Glide 动画会消费太多的内存，因此谨慎使用。 
10）Glide还可以将任何的本地视频解码成一张静态图片。 
11）使用glide，你可以配置图片显示的动画，而Picasso只有一种动画：fading in。 
12）可以使用thumbnail()产生一个你所加载图片的thumbnail。

2.缺点 
1）Glide 功能强大，但代码量大、流转复杂。在较深掌握的情况下才推荐使用，免得出了问题难以下手解决。

3.性能分析 
比Picasso性能好一些。

4.风险（包大小等） 
包大小：1.3mb 
能否解决listview图片错位问题？可以

Picasso（底层默认无缓存，使用的是API 9 以上使用 okhttp，以下使用 Urlconnection的缓存）

1.优点 
1）picasso能够根据网络状态调整线程池的并发数量 
2）使用简单，源码简单易懂。Picasso 代码虽然只在一个包下，没有严格的包区分，但代码简单、逻辑清晰 
3）内部维护了一个监控类，能够实时反馈内存缓存的命中率，使用状态等等。

2.缺点 
1）ARGB_8888 
2）Picasso的方式则因为需要在显示之前重新调整大小而导致一些延迟，Glide加载显示更快。

3.性能分析

4.风险（包大小等） 
包大小：1.2mb 
能否解决listview图片错位问题？

fresco(默认网络HttpURLConnection)

Facebook出的，不是一般的强大。

1.优点 
1）使用了Native缓存(5.0以下，不包括5.0) 
2）支持模糊渐进形式展示图片（类似webView） 
3）能够根据View的展示状态控制网络请求和图片解析的状态（在页面不可见时停止对图片的网络请求和解析操作，在页面可见时恢复操作） 
4）对多帧动画图片支持更好（未测试） 
5）对外提供清除缓存的方法

2.缺点 
1）ARGB_8888 
2）体积较大，集成后增大apk体积 
3）需要使用特定的view，需要xml支持

3.性能分析

4.风险（包大小等） 
包大小：4mb 
能否解决listview图片错位问题？

volley imageloader

1.优点

2.缺点 
Google官方出品，可惜不能加载本地图片~

3.性能分析

4.风险（包大小等）

Universal Image Loader

1.优点

2.缺点 
一个强大的图片加载库，包含各种各样的配置，最老牌，使用也最广泛。

3.性能分析

4.风险（包大小等）