教你写Android网络框架之基本架构
栏目：综合技术时间：2015-02-07 09:03:19
转载请注明出处，本文来自【 Mr.Simple的博客 】。
我正在参加博客之星，点击这里投我1票吧，谢谢~
前言
在前段时间，偶然参加了博客之星的评选，也偶然的进入到了鸿洋和任玉刚两知名博主的开发群，感遭到了很浓厚的技术探讨氛围，因而自己也冒出了写1些系列博客的想法。虽然说本人水平有限，但是也希望自己的博客能够帮到1些需要帮助的人。需要你是高手，那末明显不合适你，就没有必要再看下去了。如果你对框架开发或说Android网络要求不是很了解，每次要使用网络时都要到百度搜索1番，那末着多是你需要的。
在开发进程中，网络是我们很重要的1部份，因此我们就以网络框架或说网络模块开始。在这个框架开发进程中，我会整理开发思路、和遇到1些设计问题时会有怎样样的斟酌、解决方案，固然这只是我个人的观点，大家也能够有自己的实现。除网络框架，后续的系列还想更新ImageLoader框架、ORM框架，如果有时间也会增加动画框架和微博开发的系列文章。固然这些框架只是1些简单的框架基础，本人水平、时间有限，而且已有现成、成熟的很多框架，我们在这里只是以重复造轮子的态度去学习轮子构建进程，从而到达能够造轮子的地步。至于很多细节的问题，我们这里就补过量讨论了，如果有兴趣，各位可以自行研究。
最后，我们暂且把这个框架命名为Simple_Net_Framework，下面我们1起进入主题吧。
基本结构
图1 （ Simple_Net_Framework的基本结构 ）
SimpleNet框架的基本结构类似于Volley,包括1些命名上也有跟Volley1致。它主要分为4个部份，最上面的部份为Request，即各种要求类型。例如返回的数据类型为json的对应为JsonRequest，返回数据字符串的为StringRequest，如果需要上传文件，那末你需要使用MultipartRequest，该要求只支持小文件的上传，如果上传的文件过大则会产生OOM。
第2部份为消息队列，消息队列保护了提交给网络框架的要求列表，并且根据相应的规则进行排序。默许情况下更具优先级和进入队列的顺序来履行，该队列使用的是线程安全的PriorityBlockingQueue<E>，由于我们的队列会被并发的访问，因此需要保证访问的原子性。
第3部份是Executor，也就是网络的履行者。该Executor继承自Thread，在run方法中循环访问第2部份的要求队列，要求完成以后将结果投递给UI线程。为了更好的控制要求队列，例如要求排序、取消等操作，这里我们并没有使用线程池来操作，而是自行管理队列和Thread的情势，这样全部结构也变得更加灵活。
第4部份则是Response投递类，在第3部份的Executor中履行网络要求，Executor是Thread，但是我们其实不能在主线程中更新UI，因此我们使用
ResponseDelivery来封装Response的投递，保证Response履行在UI线程。
每一个部份职责都相对单1，这样便于往后的升级和保护。
框架分析
图1中看起来有点像是分层架构，其实不是，这个图更多的是表达了它的逻辑顺序，而不是结构。而在我们的利用开发中，分层架构是1个重要的手段，如图2所示。
图2
但在开发进程中，我们常常会把UI和业务层耦合起来，由于它们的关系太密切了，分解起来其实不是那末容易。高手能够把复杂的事情简单化，而分解就是简单化的重要手段，分解这个进程在开发进程中我们成为重构。但是如何分离UI和业务层也是本人最近想学习的，如果各位有好的解决方案，还希望多多指教。
那末我们就引入了1个分层概念，为了便于理解你也能够依照如图1的结构来加深理解。那末分层有甚么优缺点呢？
优点：
1、复杂问题分解简单化，每层负责自己的实现，并向外提供服务；
2、职责分离，复杂的系统都有很多人员进行开发，这些功能开发的管理和集成是个很严重的问题，分层设计实现以后，每层只需定义好自己的对外接口，其他依赖层服务的就能够进行开发；
3、每层对其他层都是独立的，对外隐藏实现细节，上层无需知道下层的细节，只需调用接口便可；
4、有益于标准化。
缺点：
1、分层以后对领域业务的修改有可能需要修改很多层；
2、过量的层次影响性能。
如上所说，我们的Simple_Net_Framework其实不是分层的，而是简单的模块化，但是理论基础都是类似的，依赖于抽象而不依赖于实现、单1职责......这里引入分层的概念，这是便于理解，同时也是希望大家在开发进程中能够尽可能保证模块的内聚性、耦合性。
再看Simple_Net_Framework，Request是1个抽象的泛型类，泛型类型就是返回的Response类型，例如StringRequest就是继承自Request<String>。第2部份的RequestQueue依赖于Request，Request是抽象的，因此任何Request的子类都可以传递到要求队列中来，它依赖的是抽象Request，而不是具体的某个实现，因此保证了可扩大性。你可以自己实现自己所需的Request，例如大文件的上传Request。同理，第3部份的NetworkExecutor也只是依赖于Request抽象，但这里又引入了1个类型HttpStack，这个网络要求的真正履行者，有HttpClientStack和HttpUrlConnStack，二者分别为Apache的HttpClient和java的HttpURLConnection，关于这二者的区分请参考:Android访问网络，使用HttpURLConnection还是HttpClient？。HttpStack也是1个抽象，具体使用HttpClient还是HttpURLConnection则由运行系统版本来定，HttpStackFactory会根据系统版本给框架返回对应的HttpStack。最后的ResponseDelivery比较简单了，只是通过Handler将结果投递给UI线程履行，也就是履行RequestListener的onComplete方法，此时网络履行完成，用户便可在该方法中更新UI或相干的其他的操作。
下面我们再看看SimpleNet的工程结构，如图3所示。
图3 图4
这就是Simple_Net_Framework框架的基本结构了，如果期待下1篇博客的更新，就请顶个帖吧！谢谢~
我正在参加博客之星，点击这里投我1票吧，谢谢~
------分隔线----------------------------
上一篇 昨天湿鞋了。。
------分隔线----------------------------