网络框架
AFinal
https://github.com/yangfuhai/afinal
优点：
- 自动异步请求，不会造成主线程阻塞
- 内部提供文件下载功能
缺点：
- 对HTTP请求没有任何缓存策略，不符合HTTP缓存协议
- 不提供请求取消功能
- 请求无优先级概念
- 未修复HttpUrlConnection的BUG
Volley
https://github.com/mcxiaoke/android-volley
优点：
- 内部提供4个网络请求线程及1个缓存调度线程辅助请求，效率高
- 遵循HTTP标准协议处理缓存相关策略
- 请求有优先级概念
- 支持不同类型请求的自定义扩展
- 支持取消已发出的请求
- 提供接口给用户自己实现网络请求层
缺点：
- 对大数据及流媒体没有较好支持
- 内置HttpStack对SSL、OAUTH支持存在隐患
OkHttp
https://github.com/square/okhttp
优点：
- HttpUrlConnection的修复扩展，android系统内部也采用了这个框架
- 支持SPDY协议
- 遵循HTTP标准协议的缓存管理策略
- 同时提供同步、异步请求接口
- 可以对请求进行拦截
- 拥有连接池重用机制
- 支持请求取消
缺点：
- 默认是同步获取响应数据，增大出错几率
- 依赖Okio，导致整体框架库增大
- 对于简单的HTTP网络请求略显沉重，不够轻量
结论
- AFinal由于其内部糟糕的线程池管理及毫无HTTP缓存的原因强烈建议废弃，浪费了大量服务器带宽。
- Volley内部有良好的请求调度机制，并且对各种网络请求有着极好的扩展性，但是内部使用的HttpStack对于如SSL认证和OAUTH2.0在不同Android平台存在隐患。
- Okhttp是最好的网络请求实现层，对各种协议支持较好，但是由于其可扩展性太高，在用户使用时导致需要考虑的偏多，框架偏重。
有一种比较折中的实现方案是使用Volley作为调度管理，由于Volley提供了HttpStack可设置的接口，所以可以使用Okhttp作为真实的网络请求层来避免协议隐患问题。相关链接
ImageLoader
Volley
https://github.com/mcxiaoke/android-volley
Volley首先本质上是网络框架，只是内部提供了ImageRequest作为图片加载功能，严格意义上讲并不属于ImageLoader家族。缓存部分，其内部预留了ImageCache接口，可以直接对接一级缓存（内存缓存），但是如果想对接二级缓存（磁盘缓存）的话需要对原有代码做一定改动。
Universal-ImageLoader
https://github.com/nostra13/Android-Universal-Image-Loader
老牌ImageLoader，内部结构复杂不易于定制与裁剪，使用麻烦，需要对显示、缓存做许多额外配置。
Picasso
https://github.com/square/picasso
Squre公司出品，JakeWharton主刀。快速入手，代码结构清晰明了，易于二次开发及裁剪。
- 自动管理一二级缓存
- 自动取消ImageView的回收和请求取消
- 可以对图片加载过程进行拦截
缺点：
- 二级缓存速度略慢
Glide
https://github.com/bumptech/glide
Google员工出品，GoogleIO2014 app中首次出现，使用同picasso基本一致，但是有更强大的功能扩展，支持gif解析，同时在缓存管理十分优秀，缓存加载速度优于picasso。与picasso特性能够重合。
缺点：
- API 10（测试可以在项目中正常使用，原因正在查看）
- 库体积有470k+，较大
Fresco
https://github.com/facebook/fresco
Facebook出品，首个需要so库支撑的ImageLoader，专为图片浏览类APP服务，如Facebook，Twitter，图钉等有超多图片展现、瀑布流交互的APP。
优点：
- 使用到了匿名缓存空间，减轻了虚拟机内存空间压力
- 提供了原生gif解析及控件支持
缺点：
- 对于非图片强展示型app来说功能冗余
- 由于so库的存在，导致整体库高达2M