Android 组件化，从入门到不可自拔

并且我要强调的是，组件化真的不难，还没搞过的小伙伴不要怂。

什么是组件化

---

组件，顾名思义，“组装的零件”，术语上叫做软件单元，可用于组装在应用程序中。

所以，组件化，要更关注可复用性、更注重关注点分离、功能单一、高内聚、粒度更小、是业务上能划分的最小单元，毕竟是“组装的零件”嘛！

从这个角度上看，组件化的粒度，似乎要比模块化的粒度更小。

不过，我个人认为，要把组件化拆分到如此小的粒度，不可能，也没有必要。在组件化项目的实际开发中，组件化的粒度，是要比模块化的粒度更大的。

组件化的好处

---

首先要说的是，上述模块化的好处，组件化都有，不再赘述；上述模块化的弊端，组件化都给解决了，具体如下：

1. 组件，既可以作为 library，又可以单独作为 application，便于单独编译单独测试，大大的提高了编译和开发效率；

2. （业务）组件，可有自己独立的版本，业务线互不干扰，可单独编译、测试、打包、部署；

3. 各业务线共有的公共模块可开发为组件，作为依赖库供各业务线调用，减少重复代码编写，减少冗余，便于维护；

4. 通过 gradle 配置文件，可对第三方库进行统一管理，避免版本冲突，减少冗余；

5. 通过 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，可作为宿主