简述
随着项目日益变大,功能模块和代码越来越多,维护的人员也越来越多,这个时候单一组件的项目结构就会不适宜
组件化分层
一般情况下,组件化都会分为以下的层级,这是最简单的组件化分层,不同团队也会根据自己的业务和需求,增加其他分层
- 壳工程
- 业务组件(n多个,业务越复杂,拆分的业务组件越多)
- 基础组件(1个或多个,通用的功能,底层的支持,如网络框架,分享等通用功能)
组件化能解决的问题
- 项目构建慢
每次的修改都需要对整个项目进行编译,以我现在做的项目为例,打包后apk大小100M+每次编译速度10-20分钟,组件化之后可以做到配置每个组件是代码依赖还是aar依赖,对于没有修改过的组件,直接使用aar,编译速度提升明显
- 代码管理混乱
随着人员和代码的增加,很多团队都会采取业务线或者小组的形式去管理功能和代码,比如小A负责登录,小B负责首页,组件化可以对应每个业务线一到两个组件,每个业务线的成员只允许修改本业务线的代码逻辑
- 设置相应的代码权限
接上一段,每个业务线只需要拥有自己组件的代码权限即可,其他组件的代码不允许修改,从代码权限上隔离
- 组件之间的解耦
打个比方,有一个工具类,定义了一个相对公共的方法,小A接到一个新的需求,现在这个方法不适用于新的需求,需要进行修改,那么小A有这么几种处理的方式,
- 方式一:直接修改这个方法
显然不行,很多不知道干什么的业务都在调用这个方法,改了就可能出问题
- 方式二:重载这个方法,写一个满足当前需求的方法
这样写没问题,我们很多时候也是经常这样用的,这样能够在不影响其他业务逻辑的情况下,完成自己功能的修改,BUT,很多冗余的代码就是这样产生的,每个人做一个类似的功能,都需要自己重载或者重新定义一个方法,时间长了,就变成了一堆几乎一模一样的方法
- 方便测试与维护
比如登录组件修改了相应功能,理论上只需要关注登录组件之内的改变就可以,因为组件之间是没有依赖关系的,几乎不可能因为修改了登录组件的代码,导致首页出现问题
- 可插拔
这个就看每个团队是否有这样的功能了,以我做的项目举例,我负责维护两个APP的IM功能,在做组件之前,我只能尽量保证IM的功能在代码上是基本一致的,但是组件化之后,两个APP可以依赖同一个IM基础库,我的代码在核心业务/通用逻辑业务上是可以公用的,甚至,现在有一个新的APP,也要接入IM,我可以直接给他提供sdk,这个是我在工作中实实在在遇到的,并且只花了一天左右的时间,我就给其他部门提供了一个IM的sdk和demo和文档,其他部门自己做好相关的集成,就可以了
组件化的缺点
- 组件之间不能互通
这其实个理论上来说是优点,但是在我们编写代码的时候,也会给变成带来一些不便,一般的做法是通过ARouter来解决组件之间的页面跳转和方法调用问题
- 通用逻辑/资源等需要在每个组件中定义
这个问题在我看来确实是存在的,对于非常通用的逻辑,我们一般会定义在基础组件中,各个业务组件都可以调用,但是对于两三个组件会使用的逻辑,且不是非常通用的,一般是不会下沉到通用组件的,需要每个组件各自维护,但是各自维护的好处也是有的:灵活性高,组件可以自行修改;隔离性高:不会影响其他组件;
对于上述的缺点,其实也不算是绝对的缺点,只要我们灵活运用,都不是问题
组件化要达到的效果和目的
- 全量功能,源码正常运行(基础功能)
- 部分业务组件,源码正常运行(一般用于开发人员自测使用,比如单独运行IM组件或者单独运行首页组件+IM组件)
- 部分组件,aar正常运行(部分不需要修改的组件,直接使用aar运行)
- 上传/批量上传aar到maven
- 组件之间互相调用
一个比较简单的组件化架构图
相应的代码示例
//壳工程
https://github.com/yezizaiqiutian/component_app
//登录业务
https://github.com/yezizaiqiutian/component_login
//项目基础库
https://github.com/yezizaiqiutian/component_common
//核心基础库
https://github.com/yezizaiqiutian/component_core
//组件通讯库
https://github.com/yezizaiqiutian/component_component(待完善)
//配置文件库
https://github.com/yezizaiqiutian/component_config
最后
这个组件的项目是我之前写着玩的,以后有时间继续补充,很多没有完善的也会继续完善,算是给自己挖了个巨坑吧
