详解 Gradle 自动实现 Android 组件化

buildscript {...}plugins {id "calces.modules" version "1.0.11"}

在较旧版本的 Gradle 中或需要动态配置的情况下的插件构建脚本代码：

buildscript {repositories {maven {url "https://plugins.gradle.org/m2/"}}dependencies {classpath "gradle.plugin.com.tangpj.tools:calces:1.0.11"}}apply plugin: "calces.appConfig"

2. 在项目 build.gradle 配置 AppConfig

appConfig {debugEnable false

apps {app{modules ':library1', ':library2'}

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

}

modules{library1{mainActivity ".Library1Activity"applicationId "com.tangpj.library1"isRunAlone true}library2{mainActivity ".Library2Activity"applicationId "com.tangpj.library2"isRunAlone true}}

}

3. 在 modules（子模块）引入模块自动化构建插件 (注意：不需要手动配置 com.android.library 或 com.android.application)

apply plugin: 'calces.modules'

这样我们就完成了组件化的构建了，是的，我们不再需要再手动管理单个组件了与 App 的构建了，通过Calces，我们能实现快速的组件化构建与多 App 同时构建。

那么问题来了，我们如何实现组件间的通信呢？在简单的项目中，推荐该 Demo 一样，通过使用 Android隐式Intent来实现组件间通信。在中大型项目中，笔者推荐使用阿里的路由解决方案：ARouter。具体使用方法参考官方文档就可以了，使用方法十分简单。

**注意：**在使用隐式 Intent 实现组件件通信的时候需要注意找不到相应组件异常：java.lang.IllegalStateException: Could not execute method of the activity。导致这个异常的原因是找不到目标组件导致的，所以在实际开发的时候，需要捕获这一异常，并且根据项目实际情况来进行实际的处理。使用 ARouter 框架则能通过设置降级策略来实现异常处理（查看 ARouter 文档了解更多）。

如果只是实现项目的简单组件化，那么看到这里就可以了，如果希望实现更加灵活的组件化架构的读者可以继续看下去，下面笔者将全面分析组件化的优势与笔者总结的组件化构建思想。

组件化构建简述

组件化构建与其说是一种技术，不如说是一种思想。组件化构建是通过对项目重新划分成一个个高内聚、低耦合的模块来解决项目过于臃肿，代码过于复杂的一种架构思想。

我们通过对 Google 官方的架构演示 Demo todo-mvp 进行拆分来对 Android 组件化进行深入的分析。

Demo 地址：TodoCalces

todo 系列 app 是 Google?android-architecture项目中为了演示 Android 架构的最佳实现而编写的一系列演示 Demo。todo app 的特点是，它足够简单，代码量少，易于理解。但是又不会过于简单，因为它是一个包含完成功能的 App。它实现了任务列表、任务详情、新建任务、编辑任务、统计任务的功能。

todo-mvp 实现的功能：

• 任务列表

• 任务详情

• 新增/编辑任务

• 统计任务

我们将以 todo-mvp 的功能来划分为 4 个业务模块，将底层划分为 2 个模块，分别是 superLib（提供 mvp 架构支持与其它的一些支持库功能）与 dataLib（数据支持模块，Room 提供底层数据库支持功能）。对于大型项目还可以加入 resLib 支持模块，用来存放公共图片资源、字符穿资源、样式等。

架构划分图如下：

从架构图可以看出，所有的业务组件都依赖底层库，而 APP 又依赖于业务组件，APP 组件在这里是作为一个独立组件存在的。在一般的组件化实践中，都不包含 APP 这个组件的，APP 组件的存在是有其意义的。

首先，我们的组件化除了实现组件的独立管理和动态配置 APP 所依赖的组件外，还有一个十分重要的目的就是，通过组合不同的组件，打包多个不同的 APP。例如，QQ 有分普通版和轻聊版，轻聊版是功能简化版的 QQ。如果我们使用组件化来管理工程的话，我们只需要把不需要的模块移除掉就可以了。而 APP 组件在这里的作用是充当一个包装盒，把需要的组件包装进来。并且我们可以通过控制包装盒的样式来配置不同的 APP 风格。在这里我们可以通过 Application 中的 Style 来实现。

这里我们还是以 todo-mvp 为例，例如我们需要实现一个不包含统计功能的 todo APP，按照我们的原理，我们只需要去掉 statistics 的依赖就可以了。

架构划分图如下：

如果 nostatsitcs 需要不同的配色的方案的话，只需要在 AndroidManifest 的 application 标签中配置对应的 theme 就可以了。

使用 Calces 实现 todo-mvp 的组件化

通过上面的分析，我们来试下对 todo-mvp 项目按照业务功能来划分组件。我们先来看看划分后的目录：

好了，我们已经对 todo-mvp 项目进行初步的划分了。根据上面分析的理论得知，我们的业务模块是可以单独运行的，并且我们能够快速构建一个不包含 statistics 模块的 APP。

我们只需要使用Calces就能快速实现我们需要的功能。

按照Calces的教程，我们得知，实现Calces只需要三个步骤：

1. 引入依赖库

2. 在项目的 build.gradle 中配置 AppConfig

3. 在业务模块中引入模块自动化构 c 持续

第一点和第三点在其它所有项目中的配置都是一样的，在这里不作论述，下面我们看看对于 TodoCalces 项目，我们要如何配置 AppConfig 。

appConfig {

debugEnable false

apps {app {mainActivity "com.tangpj.tasks.TasksActivity"modules ':modules:addtask',':modules:taskdetail',':modules:tasks',':modules:statistics'}

app2 {name 'nostatistic'applicationId 'com.tangpj.nostatistic'modules ':modules:addtask',':modules:taskdetail',':modules:tasks'}

}

modules {addtask {name ":modules:addtask"applicationId "com.tangpj.addtask"mainActivity ".AddEditTaskActivity"isRunAlone false}

taskdetail {name ":modules:taskdetail"applicationId "com.tangpj.taskdetail"mainActivity ".TaskDetailActivity"isRunAlone true}

task {name ":modules:tasks"applicationId "com.tangpj.tasks"mainActivity ".TasksActivity"isRunAlone true}

statistics {name ":modules:statistics"applicationId "com.tangpj.statistics"mainActivity ".StatisticsActivity"isRunAlone true}

}}

根据 AppConfig 可以得出，我们分别配置了 2 个 APP，分别是 app1 和 app2。并且 app2 中是没有依赖 statistics 的。现在我们两个 APP 运行的对比图。

app1(带 statistics 模块)：