網絡框架
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