-
(业务)组件,可有自己独立的版本,业务线互不干扰,可单独编译、测试、打包、部署;
-
各业务线共有的公共模块可开发为组件,作为依赖库供各业务线调用,减少重复代码编写,减少冗余,便于维护;
-
通过 gradle 配置文件,可对第三方库进行统一管理,避免版本冲突,减少冗余;
-
通过 gradle 配置文件,可实现 application 与 library 灵活组合与拆分,可以更快速的响应需求方对功能模块的选择。
=======================================================================
首先要说明的是,下述是一个简单的不能再简单的组件化案例,只求帮助大家搭建起组件化的架构,功能上极其简约。
九层之台,起于累土。我们这就开始搭组件化的架构吧!
先上一张组件化项目整体架构图
其中的“业务组件”,既可以作为 application 单独打包为 apk,又可以作为 library 灵活组合为综合一些的应用程序。
大多数开发者做组件化时面对的业务需求,都是上面这种情况。
我司的需求略有不同,不是将子业务组件组合为整体应用程序,而是反其道而行之,需要将已上线项目拆分给不同的业务公司使用,在不同业务系统中,项目的逻辑和代码会有区别,且版本不统一。
基于此,我搭建项目架构如下图所示,其中“m_moudle_main”是公司主要的、且逻辑和代码相同的业务组件,“b_moudle_north”和“b_moudle_south”是拆分出来的业务组件,管理各自私有的逻辑和代码,且版本有差别。
从Android工程看,结构如下图所示:
注:取moudle名,手动加上“b_” “m_” “x_”这样的前缀,只是为了便于分辨组件层次。
在项目根目录下,自建 config.gradle 文件,对项目进行全局统一配置,并对版本和依赖进行统一管理,源码如下:
/**
- 全局统一配置
*/
ext {
/**
-
module开关统一声明在此处
-
true:module作为application,可单独打包为apk
-
false:module作为library,可作为宿主application的组件
*/
isNorthModule = false
isSouthModule = false
/**
- 版本统一管理
*/
versions = [
applicationId : “com.niujiaojian.amd”, //应用ID
versionCode : 100, //版本号
versionName : “1.0.0”, //版本名称
compileSdkVersion : 28,
minSdkVersion : 21,
targetSdkVersion : 28,
androidSupportSdkVersion: “28.0.0”,
constra