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也可以采用这种方式对自定义要求更高的动态权限进行类似的处理。
