android网络框架一般性原理分析

这里归纳写一个android网络框架的一般性原理：

Http网络请求原理

  学过《计算机网络》的应该都知道http是一种应用层协议，它通过tcp实现了可靠的数据传输，能够保证数据的完整性、正确性，而tcp对于数据传输控制的优点也能够体现在http上，使得http的数据传输吞吐量、效率得到保证。

  对于移动开发来说，网络应用基本上都是C/S架构，也就是客户端/服务器架构。客户端通过向服务器发起特定的请求，服务器返回结果，客户端解析结果，再将结果展示在UI上。

详细的交互流程有如下几步：

1. 客户端执行网络请求，从URL中解析出服务器的主机名
2. 将服务器的主机名转换成服务器的IP地址
3. 将端口号从URL中解析出来
4. 建立一条客户端与web服务器的tcp连接
5. 客户端通过输出流向服务器发送一条http请求
6. 服务器向客户端会送一条http响应报文
7. 客户端从输入流获取报文
8. 客户端解析报文，关闭连接
9. 客户端将结果显示在UI上

android中执行网络请求的方式有两种：httpclient、httpurlconnection，其实网络框架也主要是基于此做一些功能扩展和封装。

生产者消费者模式

早晨我在看java并发的时候发现，其实一般性的android
网络框架就是一个典型的生产者-消费者模式。我不太了解服务端，我觉得服务端在处理客户端的并发请求时也
对应着一个典型的生产者-消费者模式。（仅是思考，不太成熟）。这里不会细讲并发这块内容，后续的博客会有一个专题专门来讲解并发相关的内容。

客户端请求多个mobileapi，对应着多个任务，然后多个任务会进入一个缓冲区，多个网络执行的线程会去并发的处理这个缓冲区中的任务。典型的生产者消费者模式。

BlockingQueue可用于充当共享内存缓冲区，用于维护请求任务队列。

BlockingQueue就类似一个“意见箱”。它之所以适合作为数据共享的通道，是java并发包中一个比较重要的类，具体如何实现的大家可以下去研究。这里就不讲了。它常和ThreadPoolExecutor 结合使用。

BlockingQueue是用于实现生产者和消费者的一个不错的选择。但是BlockingQueue并不是一个高性能的实现。更深入的我还在研究中，这里先止于此。

命令模式

命令模式的特点就是：让命令发送者和命令接受者之间解耦，此外，命令模式可以增加一个命令的队列，支持对命令进行撤销。这个模型明显和android网络框架一一对应，android网络框架也支持对命令的撤销。

这里不会详解命令模式，之前的设计模式系列博客已经讲过这块内容，可以去翻看前面的博客。

支持扩展

对于android网络框架来说，可能的扩展性方向是什么呢？应该是可以支持多种格式的请求：如String、xml、json等等。如何设计这块的扩展性，各个网络框架的设计殊途同归。

异步和回调（Callback）

网络请求肯定是异步的，但是网络请求执行结束后，你需要把执行的结果告诉异步任务执行者，这个时候就需要回调了。不过回调也只是一种方案而已。

更多资料：
http://www.ruanyifeng.com/blog/2012/12/asynchronous%EF%BC%BFjavascript.html

http://quinnhe.iteye.com/blog/2192940

http://www.jianshu.com/p/3141d4e46240