上一篇文章介绍了android组件化开发的意思逻辑和基本思路，具体可以看这里。但是除了基本的思路外，这种开发方式虽然对多人协同开发、项目管理和后期维护有很多好处，但是同样在开发过程中也有很多的坑。这一部分就主要介绍组件化开发需要注意的问题和解决方法。
1.module之间的引用
在AS 3.0之后，gradle的compile已经被废弃，取而代之的是implementation和api。这两个的区别一般只需要记住一点：implementation引入的各种子模块是无法被更高层的module使用的，而api可以。
举个栗子：A module 引入了B module，B module引入了C module，如果使用的是implementation方式，那么C对于A来说是不可见的；而使用api方式A是可以使用C中的方法的。同理，把C换成开源库、so文件、aar文件、jar包文件结论也适用。
2.不同module之间jar包的引用
这里再单独说一下jar包文件，同样举个栗子：A module引入了B module，B module出于某种需求在lib中添加了c.jar包。这是如果A要使用相关的api，必须在A module也声明c.jar包，不然一般情况下api会抛出异常。B module中对c.jar的声明就是一般的gradle配置的常用方式，在对应module的build.gradle文件中添加如下代码：
...
repositories {
flatDir {
dirs \'libs\'
}
}
dependencies {
api fileTree(dir: \'libs\', include: [\'*.jar\'])
...
}
而在A module中，c.jar的路径需要变为相对路径
repositories {
flatDir {
dirs \'libs\', \'../moduleB/libs\'//第一个表示A模块本身的lib文件夹，第二个表示相对于A模块，c.jar所在的路径
}
}
dependencies {
implementation fileTree(dir: \'libs\', include: [\'*.jar\'])
...
}
同时需要注意为了能让A模块使用c.jar，Bmoudle的配置文件使用的是api方式引入。
3.不同module的build.gradle配置维护
对于不同的module，很多的gradle配置其实是比较重复的，比如SDK支持的版本号，一些常用的suppor包引入等。以com.android.support:appcompat为例，不同的module如果引入的版本不同，轻则构建时发出警告，严重时可能直接导致构建失败。所以，我们需要维护一个统一的全局版本。这里我门需要用到根目录的config.gradle文件。没有的话可以自行新建一个。
ext {
android = [
compileSdkVersion: 27,
buildToolsVersion: "27.0.2",
minSdkVersion : 19,
targetSdkVersion : 26
]
dependencies = [
project : [
moduleBase : \':moduleSystem:moduleBase\',
moduleCommon : \':modulePublic:moduleCommon\',
moduleUser : \':moduleCore:moduleUser\'
],
"support:appcompat-v7" : \'com.android.support:appcompat-v7:27.0.2\',
"support:design" : \'com.android.support:design:27.0.2\',
"junit:4.12" : \'junit:junit:4.12\'
]
}
内部的名称和嵌套层级都是可以自定义的，使用的时候以rootProject.ext开头，例如rootProject.ext.dependencies["support:appcompat-v7"]。这样如果需要对配置做修改，只需要修改一处就可以了。
4.不同module之间的数据通讯
因为AS项目的机制问题，不同的module之间需要靠implementation和api的方式保持引入关系，而对于被引用或者平级之间的module，都是不可见的。这就导致这些module之间的数据交互出现了问题。
-
不同module之间的页面跳转
这里主要的解决方式是通过开源路由库来解决，相关的库可以在gayHub上去搜rout、router关键字。我在自己项目中使用的是阿里的ARouter。 -
不同module之间的事件响应和消息传递
这个没啥好说的了，eventbus解决之。5. build.gradle buildType统一
这个其实应该算作是AS 3.0的新版本的坑，不过在这儿用到了大量的module，用AS 3.0的同学也就必须要做这个工作了。我们知道在主app模块的buidl.gradle文件中可以修改buildTypes来配置不同的apk构建方式：
buildTypes {
debug {
}
//打包测试用（内部非混淆打包测试服务器）
debugTest.initWith(buildTypes.debug)
debugTest {
}
releaseLocal {
}
//正式服务器（对外发布公开包）
releaseFormal.initWith(buildTypes.releaseLocal)
releaseFormal {
}
新特性总结为一句话就是主app的buildTypes有多少，在每个子module的配置中也得保持一致。子module中不一定需要具体的配置，但是得保证每个都得有。例如这里有debug、debugTest、releaseLocal、releaseFormal 4种，那么所有的子模块也得有对应的4中配置。
6. 系统层继承和改写
在项目中通常会有下面这种需求。我们一般会在系统层的moduleBase中写一个自定义的BaseApplication.class类。而在app中，我们通常会在Application中初始化一些额外的启动配置，例如推送的初始化等，而很可能对于系统层而言，推送相关的module是不可见的，换言之，我们无法在moduleBase的BaseApplication.class类中完成对应的初始化操作。
对于这种情况，我采用的是在app层再自定义一个SystemApplication.class类继承BaseApplication.class，并实现BaseApplication.class的抽象方法的方式来对应的操作。
另外，对于自定义的BaseActivity、BaseFragment也可以采用这种方式对自定义要求更高的动态权限进行类似的处理。
转自：https://www.jianshu.com/p/bfd5afed498f