经典的网络请求例子
典型网络请求
代码模型：
- 用URL生成连接 ；
- 得到输出流(输出流中写入数据) ;
- 得到输入流，获取数据；
遗留下的问题：
- Android 系统不允许主线程直接操作网络请求，需要在子线程中进行；
子线程的创建销毁本身就是一种资源消耗，同时线程生命周期不好控制，会导致各种使用问题； - 网络异常的处理。请求重连的时候怎么处理，怎样传递错误信息到业务层进行显示，缓存怎么弄，容错机制怎么考虑......需要完善；
- 每个地方都写同样类似的代码的时候，会出现大量的代码冗余，需要把相同的东西提出来统一处理，再根据业务情况写差异性代码；
- 代码应该具有向后兼容性，允许不同场景下的定制，或者能够快速稳定的修改/替换内部代码，但是保证业务逻辑的稳定性；
- 这个时候，我们需要一个网络框架了；
解决问题的思路
- 频繁的线程创建销毁。
采用线程池的方式，可以让之前创建的一些线程保存下来，留着之后的请求继续使用；因为线程池中保留了一定量的线程，但是网络请求数量是未知的，那么需要一个队列，保存尚未来得及处理的请求，有空闲线程的时候继续处理； - 异常的处理
网络请求是异步的，很明显的是我们需要定义接口，采用回调的方式，在异常产生的时候丢到业务层； - 缓存机制
对于需要缓存的请求，如果之前已经拉取过数据了，我们就可以直接从本地拿取数据加以显示，不用向服务器要。一种最简单的方式就是将请求数据存下来，同时跟请求数据相关联，根据关联规则存取； - 重试机制
网络请求有时候会遇到重定向，会遇到暂时性质的网络问题。那么我们就需要根据异常原因采取重新连接； - 代码复用
好好的分析一下每一个网络请求，发现它们有太多的相似；比如说都会openConnection ，都会 判断responseCode ，获取 inputstream 等；不同的点上，似乎只有每次请求的URL ，请求参数，请求方式，以及最后的回调处理不一样；我们把相同的代码封装起来，不同的代码，通过参数的方式传递进来就好。 - 向后兼容性/可扩展性
很多时候我们这个方面的考虑，都是需要通过接口的方式搞定；一个接口多个实现，能够满足很多的个性化需要以及未来的改造；
看看Volley是怎么做的
Volley流程图.png
** 框架初始化：**
Volley 类提供初始化接口，创建请求管理队列RequestQueue；
RequestQueue中持有全局性的操作对象，跟具体请求无关：
缓存管理接口mCache，负责从磁盘上保存读取之前
网络请求控制类mNetwork ，具体实现单个网络请求的控制类，发起连接，获取原始网络流数据；
缓存分发器mCacheDispatcher ，一个线程类，负责从磁盘读取数据并返回结果；
网络请求分发起mDispatchers ，线程类数据，保存着数个线程，每个网络请求都是在其中一个线程中执行；
事件传递器mDelivery，框架中产生了异常，成功获取数据后都是通过这里回调出去的；
网络请求协议栈HttpStack，接口类，可以采用不同的实现方式获取到http的连接；
单个网络请求流程：
以mRequestQueue 的add 方法为入口，传递具体的Requst执行请求流程；
Requst中包含有网络请求必须的网络设置参数，服务器请求参数，以及回调接口；
mRequestQueue会根据缓存情况决定是否从Cache中获取数据；
不需要缓存数据或者缓存数据过期，请求会进入网络请求队列，经由mDispachters的分发后，从网络获取数据；
数据获取过程中产生的结果以及异常信息，经由mDelivery回传到request对应的回调中；
于是一个网络请求过程完成。
