现在的状态
- 经过几年的业务开发，项目包越来越大了，集成的aar也越来越多，编译速度...
- 项目中的类，基类，工具类，业务包越来越庞大，牵一发动全身，团队开发，各种git合并冲突问题；
- 资源问题越来越多;
- 外部aar更新频繁，什么 aar还嵌套？aar不能传递依赖，各种编译，拷贝，打包，运行，测试....
- 人越来越多，代码越来越糟；
- 又有新业务来了...
好久好久没有更新此文章了；
到现在为止，基本上，摸清了一些套路，在此记录一下，希望对大家有帮助；
那就得重构...
说明：组件跟模块是有区别，有个时候，他们又是一致的，比如：网络是一个组件，基于网络的第二次封装，又是一个模块，也可以成为新的组件，因为她由底层库，与自己的逻辑组成而成；
针对某个 具体业务，比如：登录模块，我们可以说他是一个组件，也可以是一个模块。概念就不纠结了；
各个模块独立git仓库：如果模块代码较多，比如：网络二次封装，我们可以单独建立一个git仓库，对于一些简单的工具类，少量类的情况下，我们将此归集成一个大模块，比如:
工具类组件；我们我们在抽现有功能，或新建业务功能时，就可以直接通过 gradle compile 进行引入，类似于导入 google库一样；这样模块可独立维护，有更新时，主app只需要修改对应的模块的版本号即可；
compile "com.android.support.constraint:constraint-layout:1.0.2"
compile "com.android.support.constraint:constraint-layout-solver:1.0.2"
一起从抽库开始
0.总体图
我们的方案，目前比较简单，总体图如下：
总体模块设计图
注意： 各个模块与主App都依赖了common-sdk，打包的时候，gradle足够聪明，只会保留一份引入，大可放心，如果有强迫症，可以在模块中采用 provider 形式引入；
说明：
- common-sdk ： 见下详细说明：提供公共基础能力；
-
各业务模块：分别依赖于
common-sdk,因为有了登录模块依赖，是可以脱离主App独立运行的，实现独立运行，独立测试、独立维护；如何脱离，我们后面详细说明一下； - 第三方sdk：如果第三方是本公司其他团队或合作方开发的，可将我们的一些基础模块输出给他们，一来可以技术对外输出，一来，可以有效降低第三方sdk包大小（common-sdk由多个组件组成，可拆）；
- 主App：这就是宿主了，在集成测试时，我们可将所有功能拉进来测试，也可只拉部门，有效减少编译时间，提升效率；
1. common-sdk 模块
如下图，common-sdk 为拆分现有app各个模块的基础，比如后面，需要从冗余的app主工程抽离功能A，
就需要引入此 common-sdk模块；
common-sdk
2. 网络库的独立
现在回头看之前自己写的代码，网络基于 xutils 的2次封装，在请求的时候，我的第二次封装非常不好，导致，现有模块，太难隔离，而且，针对与网络，每个app的网络请求数据格式是不同的，如果将 封装的2次网络移入到每个独立运行的业务，显然是不显示，会导致，冗余非常严重； 所以我们的计划是：
- 先将一个基本的网络库模块独立出来，只做网络基本管理(basenet)；
- 在基本网络库的基础上，进行针对具体app的封装，比如：加上加密处理等，叫做common-sdk;
待续。。。。
网友评论