项目网络层重构总结

1. 引入网络抽象层，主要包括以下部分:

   • Request: 通用的Request的实现结构，承载如下职责:
     
     1. 网络请求信息的承载和封装。
     2. 为Interceptor提供切面回调。
     3. 为第三方库的Request**具体实现提供桥接接口。**
   • Sender: 对网络请求发送的抽象，为第三方库的发送请求(以及一些请求控制方法)提供实现接口。
   • Interceptor: AOP，对Request的各项回调进行intercept，可以支持动态挂接，网络层的附加机制的实现将主要集中在这里或者以这里为回调事件的分发点。

2. 通用Request可以实现和第三方网络库Request具体实现细节的解耦，并且当前很多作用于第三方网络请求的代码(如果认证加密)将被迁移为针对通用Request的实现，通用Request将作为项目代码中网络请求的唯一表现形式，第三方库的具体请求将被隔离到最底层，只在Sender的具体实现中可见。通用Request会成为架构中的一个对外网关协议，所有的网络请求均以通用Request的形式发出，最后由Sender的具体实现翻译/适配为对应的请求实现。

3. 通用Request采用注入式的方式来和第三方具体实现进行协作，其本身只提供信息查询接口和回调接口，并且不会维持对第三方具体实现的引用，反过来由第三方具体实现以扩展适配的方式来回调通用Request，第三方具体实现将会维护一个到通用Request的单向引用。

4. 通用Request本身不包含太多的逻辑处理细节，像认证加密等属于网络层附加机制的实现会放在Interceptor中。Interceptor可以支持动态插拔，Request回调Interceptor时会将自身传入，尽量为Request为基本通信单位。目前的一个问题是一些附加机制需要在几处回调都做部署，比较零碎。

5. 全局的网络请求状态将可以检测，一个通用Request在被发送后会保存在内部的RequestManager中，其生命周期持续到该Request结束为止。附加机制的网络请求队列(如加密认证的重发队列)会独立于RequestManager，不同的队列没有直接的耦合关系。各自根据所需进行队列的维护和修改。

6. 通用Request包含了两种类型的信息:

   • 静态信息: 如原始url, method, timeout等，这部分信息在Request被重发时并不会被改变(除非是特殊的需求)。
   • 动态信息: 如requestId， 真正的url(有这个是因为一部分加密信息会附加在原始url上， 具有实时性)等，这部分信息在Request重发时应该重新生成，这样才能区分出是一次新的Request(Request重发从网络层的角度上讲，应该是一个全新的Request，不过业务层不应该这样的细节)。

   可以考虑动态和静态信息进行类级别的分离。

7. 引入了ControlInfo，在发送请求时可以选择性的代入，目前包括:

   • ViewId/ViewType: 该View对应的不是Android原生View，而是一个View抽象，因为很多网络请求的回调需要和界面发生互动（如请求成功后弹出提示对话框），而Android的特性决定了大多数互动都要有一个锚点(比如Activity), 这里的View代表就是该锚点View，ViewId即请求发出时所在的界面的Id(Id本身是我们采用的另外一套View机制为每个Activity/Fragemnt分配和维护的), ViewType则表示View的具体类型(不一定是actiivty/fragment,.可以从业务上面进行分类比如详情页/主页)。
   • SessionId: 有这样的应用场景，复数个连环网络请求对应的是一次业务过程(比如先发一个查询请求，成功的话再发一个领取请求，领取完再发一个登录请求)，对于这一次业务过程中的网路请求，可以看做是同一个session中的网络请求，通过sessionId来进行标记。
   • 一些控制信息，在上面介绍的Interceptor中会被用到。

8. 通用Request中的NetworkCallback是业务层能感知到网络层的唯一途径，可以通过拦截Callback的某些回调方法来屏蔽一些业务层不应该/不需要知道的网络层细节。