前段时间刚完成了新公司网络框架的改造，这篇文章针对架构设计总结下，希望各路大神能多提意见和建议。
一、背景
公司多个Android客户端项目，各自维护一套基于Volley的网络库，维护成本高。另外，需要再新增Okhttp的支持，平滑过渡，以后看情况再决定是否完全抛弃Volley。
二、需求
2.1 增加Okhttp支持。
2.2 实现Volley与Okhttp运行时动态切换。
2.3 针对业务需求，增加对Okhttp个性化定制。
三、实现
首先看看之前项目的组件化情况：
app都是按如上组件化分层来的，而Lib-Network本身耦合了基本网络请求功能 和 公共网络请求业务逻辑。
因此想要做一套公共的网络基础库，那需要抽一层Base-Network出来，仅做基本网络请求功能，不耦合具体业务。
那么Base-Network怎么设计呢？
将请求与多个网络框架进行解耦，由factory来负责初始化对应的网络框架，由统一抽象类约束多种网络框架的行为。
1）Factory: 通过上层下发的服务端配置信息来动态切换网络库，向上提供单例网络库实例并且初始化方法下沉到native，融合验证机制进行一定程度代码保护。Factory好处是实现request与网络库解耦，实现网络库动态切换以及可插拔。
2）通用业务形态：
- 业务请求：优先级要求最高。
- 数据上报：短而频繁、优先级低。
- 大文件上传：不阻塞其他请求。
针对这三种业务形态：Volley 因为是一个4线程的RequestQueue来处理，且自都有一个对应的PriorityBlockingQueue维护请求队列。那么这里针对三种业务各自维护一个RequestQueue，且对三种业务的线程优先级进行优先级设置，在时间片抢占能力上稍微做一定的区分，一定概率保证业务的优先级。而Okhttp是一个大的CachedThreadPool，一个线程池即可，同样设置好线程优先级。
那么最终的设计架构：
方案1
方案2
方案3
思考三个方案：
1.共性业务往下沉，优点是框架层节省代码量，缺点是Base-Network又与业务耦合上了。
2.严格按组件化层级来，优点是层级相对独立、Base-Network更加万金油，缺点是共性业务每个app项目都得在框架层写一套。
3.在Base-Network和Lib-Network中再抽一个Lib-Network-Loft层，针对Lib-Network共性业抽一层公共业务出来。优点是既保证业务独立，又没有重复代码，缺点是多了一个mdoule需要维护。
个人感觉，看项目精细化程度要求，要求高的用3，要求低的用1。
网友评论