Android常用的网路框架： 
大多数应用程序基本都需要连接网络，发送一些数据给服务端，或者从服务端获取一些数据。通常在 Android 中进行网络连接一般使用 Scoket 和HTTP，HTTP 请求方式比 Scoket 多得多。HTTP 请求一般采用原生的 HttpClient 和 HttpUrlConnection 的两种网络访问方式。可是在 Android 5.0 的时候 Google 就不推荐使用 HttpClient 了，到了 Android 6.0 (api 23) SDK，不再提供 org.apache.http.* (只保留几个类), 因此，设置 android SDK 的编译版本为23时，且使用了 httpClient 相关类的库项目：如 android-async-http 等等，会出现有一些类找不到的错误。

列举目前常用的网络框架,当然呢，每种网络框架都会有其优点和缺点的，主要是根据我们自身的项目进行选择： 

1.Volley 
Volley 的中文翻译为“齐射、并发”，是在 2013 年的 Google 大会上发布的一款 Android 平台网络通信库，具有网络请求的处理、小图片的异步加载和缓存等功能，能够帮助 Android APP 更方便地执行网络操作，而且更快速高效。

在 Google IO 的演讲上，其配图是一幅发射火弓箭的图，有点类似流星。这表示，Volley 特别适合数据量不大但是通信频繁的场景。见下图： 

优点： 
（1）自动调度网络请求； 
（2）高并发网络连接； 
（3）通过标准的 HTTP cache coherence（高速缓存一致性）缓存磁盘和内存透明的响应； 
（4）支持指定请求的优先级（ 请求队列的优先级排序）； 
（5） 提供多样的取消机制：网络请求 cancel 机制，我们可以取消单个请求，或者指定取消请求队列中的一个区域； 
（6）框架容易被定制，例如，定制重试或者回退功能； 
（7）包含了调试与追踪工具； 
（8）默认 Android2.3 及以上基于 HttpURLConnection，2.3 以下使用基于 HttpClient 
（9）提供简便的图片加载工具（其实图片的加载才是我们最为看重的功能)

缺点： 
（1）不能下载文件：这也是它最致命的地方

官网或相关地址： 
Volley 的 github 地址：https://github.com/mcxiaoke/android-volley； 
Google I/O 2013 – Volley: Easy, Fast Networking for Android：https://www.youtube.com/watch?v=yhv8l9F44qo&feature=player_embedded 
简单的使用：http://www.dengzhr.com/others/mobile/android/762

2.Android-async-http 
Android-async-http 是一个强大的网络请求库，这个网络请求库是基于 Apache HttpClient 库之上的一个异步网络请求处理库，网络处理均基于 Android 的非 UI 线程，通过回调方法处理请求结果。 
android-async-http 是一个强大的第三方开源网络请求库。可惜的是 Android 6.0 (api 23) SDK，不再提供 org.apache.http.* (只保留几个类)。

优点： 
(1) 在匿名回调中处理请求结果 
(2) 在 UI 线程外进行 http 请求 
(3) 文件断点上传 
(4) 智能重试 
(5) 默认 gzip 压缩 
(6) 支持解析成 Json 格式 
(7) 可将 Cookies 持久化到 SharedPreference

官网或相关地址： 
Android-async-http 的 github 地址：https://github.com/loopj/android-async-http 
官网教程：http://loopj.com/android-async-http/

接下来我们来看下我们国人封装的两个框架 Afinal 框架和 xUtils ，这两个框架的功能非常的丰富，甚至提供了数据库的封装，这很符合我们国人开发的App，都是把一大堆的功能都集进去，那这么强大的网络框架是不是真的那么强大呢？通常我们都会这样想：功能越丰富的开源框架，那么它在单一的功能上，比如就网络框架这一部分，是不是就没有其他专一网络的框架好呢？

注：这两个框架的作者已经停止更新了，因此现在就不推荐使用了

3.Afinal 
Afinal 是一个 android 的 sqlite orm 和 ioc 框架。同时封装了android中的http框架，使其更加简单易用；使用 finalBitmap，无需考虑 bitmap 在 android 中加载的时候 oom 的问题和快速滑动的时候图片加载位置错位等问题。

Afinal的宗旨是简洁，快速。约定大于配置的方式。尽量一行代码完成所有事情。

Afinal主要是分四个模块： 
(1) 数据库模块：android 中的 orm 框架，使用了线程池对 sqlite 进行操作。 
(2) 注解模块：android 中的 ioc 框架，完全注解方式就可以进行UI绑定和事件绑定。无需 findViewById 和 setClickListener 等。其实它后面是使用反射来进行初始化的。 
(3) 网络模块：通过 httpclient 进行封装 http 数据请求，支持 ajax方式加载，支持下载、上传文件功能。 
(4) 图片缓存模块：通过 FinalBitmap，imageview 加载 bitmap 的时候无需考虑 bitmap 加载过程中出现的 oom 和 android 容器快速滑动时候出现的图片错位等现象。

官网或相关地址： 
Afinal框架 的 github 地址：https://github.com/yangfuhai/afinal

注：这个框架的作者已经停止更新了，因此现在就不推荐使用了

4.Xutils 
xUtils跟Afinal是同类型的框架， 现在作者已经两三年前就没有进行更新了。

官网的简介： 
xUtils3 api 变化较多, 已转至 https://github.com/wyouflf/xUtils3 
xUtils 2.x 对 Android 6.0兼容不是很好, 请尽快升级至 xUtils3. 
xUtils 包含了很多实用的android工具。 
xUtils 支持大文件上传，更全面的http请求协议支持(10种谓词)，拥有更加灵活的 ORM，更多的事件注解支持且不受混淆影响… 
xUitls 最低兼容android 2.2 (api level 8)

官网或相关地址： 
Afinal框架 的 github 地址：https://github.com/wyouflf/xUtils

注：这个框架的作者已经停止更新了，因此现在就不推荐使用了

上面网络框架其实就个人而已，就不推荐使用了，要不就是功能太过丰富，如果在主流的 app 中使用，对后期的维护， 代价就很大了。比如你发现你框架中不适合使用某个功能，需要替换这部分的框架，你就会发现，你整个项目都不出现这个框架的影子，对于后期维护的成本实在是太大了！

后面的几个网路框架（okhttp ， retrofit）是目前较好的网络框架，在公司也发现，很多项目都是使用这几个网络框架的。这两个网络开源框架都是 square 公司提供的，在开源界中，有两家公司提供的网络框架是非常丰富的，一个是 square 和 Facebook ，真心感谢这两个公司。

5.OKHttp 
OkHttp 是一个相对成熟的解决方案，据说 Android4.4 的源码中可以看到 HttpURLConnection 已经替换成 OkHttp 实现了。在 Android 6.0 中底层的源码已经使用了 OKHttp ，这个是可以确定的。

OkHttp 处理了很多网络疑难杂症：会从很多常用的连接问题中自动恢复。如果您的服务器配置了多个IP地址，当第一个 IP 连接失败的时候，OkHttp 会自动尝试下一个 IP。OkHttp 还处理了代理服务器问题和 SSL握手失败问题。

使用 OkHttp 无需重写您程序中的网络代码。OkHttp 实现了几乎和Java.NET.HttpURLConnection 一样的API。如果你用了 Apache HttpClient，则 OkHttp 也提供了一个对应的 okhttp-apache 模块。

官网或相关地址： 
OKHttp 的 github 地址：https://github.com/square/okhttp

6.retrofit 
其实 retrofit 是根据 OKHttp 封装的框架，它的底层网络请求就是使用OKHttp的，这个框架的作者也是非常有名的，就是 Jake Wharton 。简直就是我的偶像啊！

优点： 
（1）支持 okhttp 
（2）注解处理，简化代码 
（3）支持上传和下载文件 
（4）支持自己更换解析方式 
（5）支持多种http请求库

官网或相关地址： 
OKHttp 的 github 地址：https://github.com/square/retrofit

选择开源框架的见解：

1.学习的成本：对该框架学习的时间长短，文档是否齐全的考虑 
2.流行的程度：该开源框架是否流行，github 上 start 的个数，都是我们考量的标准 
3.是否还在维护：如果该框架没人维护了，随着技术的不断更新，都会出现大大小小的问题的 
4.代码的体积： 体积当然不能太大了 
5.代码的设计： 整体框架的设计