架构升级过程图
Base建立-网络
Q:为啥要对网络做架构调整？
R：
1）旧的网络在业务端存在两份，一份是普通Http，另一份是上传下载，
像网络这种偏base的东西，都需要做base化，防止业务端改到，闭合修改。
2）为后面的日志上报 & 重构直播课，组件化做准备
Q:啥方案？
1）NetWorkManager 建立，所有网络相关的就只有这个入口。业务端传入对应的type，
选择业务类型，是普通http请求还是上传下载的，还是监控相关的。
2）NetRetrofitCache 主要做不同类型的网络请求的cache。
3）BuilderConfigFactory 一个工厂，主要负责生成对应的OkHttpBuilder，还有一个作用就是处理共性的RetrofitBuilder配置
3）InterceptorFactory 一个工厂，负责生产对应的OkHttp的拦截器，因为拦截器其实是一个可复用的东西，不属于业务范畴。
Q:为啥不重写一套？
R：
1）本身的NetWork没啥大问题，Retrofit+OkHttp是主流,只是入口不统一，没有下沉base，所以对应的NetWork调整就足够了。
Q:这样做有啥好处？
R:
1）下沉了NetWork
2）闭合了业务端对Interceptor的修改
3）干掉了业务端存在两个网络的问题，统一了NetWork入口。
Q:怎么做？
R:
0:NetWork-先搭建框架
1:替换引用-替换业务层的引用
2:干掉-干掉旧代码
3:自测&写测试场景-自测各个场景，熟悉产品业务。
Q:重构完之后，有啥问题？
1）ServerRequestErrorHandler 耦合了业务端的请求ACCOUNT_LOGIN，后面改造日志的时候，可以干掉
2）ProgressResponseBody 中处理了下载进度，这个在业务处理上是不对的，应该在业务层自己去做这些处理；另外ProgressResponseBody还用了EventBus 这个也是有问题；后面从产品需求出发，顺便让业务端的把改掉。
3）GreenDao 不利于组件化，业务层的Dao 都会集合到base中来，这个问题暂时没啥方案。
4）MonitorUtil 后面干掉和数据库的耦合。
