Android 组件化

场景：

公司业务扩大，业务拆分。团队已业务划分。就会遇到开发并行的问题。在中情况下可以使用业务组件化

技术：

组件化的基本就是通过 gradle 脚本来做的

实现

通过在需要组件化的业务 module 中：   

if (isDebug.toBoolean()) {    apply plugin: 'com.android.application'} else {    apply plugin: 'com.android.library'}

并在业务 module 中放一个 gradle.properties

isDebug=false

如此，当我们设置 isDebug 为 true 时，则这个 module 将会作为 application module 编译为 apk，否则 为 library module 编译为 aar

Manifest

一个很常见的需求就是，当我作为独立业务运行的时候，manifest 会不同，比如会多些 activity（用来套的，或者测试调试用的），或者 application 不同，总之会有些细微的差别。

一个简单的做法是：

sourceSets {    main {        if (isDebug.toBoolean()) {            manifest.srcFile 'src/debug/AndroidManifest.xml'        } else {            manifest.srcFile 'src/release/AndroidManifest.xml'        }    }}

这样在编译时使用两个 manifest，但是这样一来，两者就有很多重复的内容，会有维护、比较的成本。

我们可以利用自带 flavor manifest merge，分别对应 debug/AndroidManifest.xml, main/AndroidManifest.xml, 以及 release/AndroidManifest.xml。

main 下的 manifest 写通用的东西，另外 2 个分别写各自独立的，通常 release 的 manifest 只是一个空的 application 标签，而 debug 的会有 application 和调试用的 activity（你总得要有个启动 activity 吧）及权限。

这里有一个小 tip，就是在 release 的 manifest 中，application 标签下尽量不要放任何东西，只是占个位，让上面去 merge，否则比如一个 module supportsRtl 设置为了 true，另一个 module 设置为了 false，就不得不去做 override 了。

和main同级下有一个debug和release目录，在用命令行gradle assembleDebug 就会把main中的manifest和debug中的manifest合并。

当debug的时候就会使用debug的manifest中的activity作为入口启动，这样在开发的时候只需要在当前模块编译开发即可。

release的时候module就是library了，而入口就是app。

---

`