上一篇文章介绍了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