Android组件化架构

Android组件化架构

当APP规模达到一定时，利用组件化架构能够有效的简化APP的逻辑。按业务逻辑分组，各个团队只需关注于自己的模块实现，编译发布APP时再把各个模块集合在一起。组件化架构方式能让这一切变得简单而易于维护，特别适用于不同团队之间的协作开发。本文主要介绍组件化架构的代码组织方式。

组件化架构需要各个组件不仅能够单独运行而且也能无缝的集成到主程序中，在这个过程中会遇到以下问题：

1. 组件可在Application和Library之间自由切换

TODO:
在项目的根目录下的gradle.properties文件中声明一个变量isModule(该变量能对整个项目中所有的gradle文件生效)代表是否是组件开发模式。

gradle.properties
isModule=false

在每个组件build.gradle文件中添加以下代码，根据刚才定义的变量动态构建该模块。

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

2.组件AndroidManifest.xml与工程AndroidManifest.xml冲突的问题

TODO:
可以为组件模式和工程模式分别指定不同的AndroidManifest.xml文件，并同时维护两份文件。这两份xml文件的区别就是，在组件模式下要去掉LAUNCHER Activity的声明，其他均相同。

//每个模块下的build.gradle文件
sourceSets {
        main {
            if (isModule.toBoolean()) {
                manifest.srcFile 'src/main/module/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/AndroidManifest.xml'
            }
        }
    }

3.组件Application与主工程Application冲突的处理

TODO:
由于每个APP都有唯一个Application对象，在组件合并时没法做到相互调用，这时候就需要有一个全局模块来统一管理这个Application了。
在组件化工程模型图中，功能组件集合中有一个 Common 组件， Common 有公共、公用、共同的意思，所以这个组件中主要封装了项目中需要的基础功能，并且每一个业务组件都要依赖Common组件，Common 组件就像是万丈高楼的地基，而业务组件就是在 Common 组件这个地基上搭建起来我们的APP的，在Common组件中我们封装了项目中用到的各种Base类，这些基类中就有BaseApplication 类。

BaseApplication 主要用于各个业务组件和app壳工程中声明的 Application 类继承用的，只要各个业务组件和app壳工程中声明的Application类继承了 BaseApplication，当应用启动时 BaseApplication 就会被动实例化，由于所有组件都依赖于Common组件，所以任何组件都可以操作BaseApplication类，这样也就实现了Application的集中管理。

4.组件资源名重复的问题

TODO:
组件化不可避免的会出现资源名冲突的问题，如A和B组件里面有相同名称的图片等。解决这个问题最简单的办法就是在项目中约定资源文件命名规约，比如强制使每个资源文件的名称以组件名开始，这个可以根据实际情况和开发人员制定规则。当然了万能的Gradle构建工具也提供了解决方法，通过在在组件的build.gradle中添加如下的代码：

//设置了resourcePrefix值后，所有的资源名必须以指定的字符串做前缀，否则会报错。
//但是resourcePrefix这个值只能限定xml里面的资源，并不能限定图片资源，所有图片资源仍然需要手动去修改资源名。
resourcePrefix "modulea_"

5.跨跳转问题，路由选择

TODO:
利用第三方路由框架实现组件间的跳转，如ARouter或ActivityRouter等。

代码方案

在组件化工程模型中主要有common模块，空壳模块，普通业务模块三种类型。common模块管理了所有的依赖关系，所有模块都依赖common模块。空壳模块是汇聚整合整个项目的模块，它依赖了所有的业务模块（moudleA,moudleB,moudleC）,app名称，图片代码混淆等都在这里实现。普通业务模块即根据业务细分的模块，承担各个业务独立的功能。

common模块

common模块始终为com.android.library类型。它的主要用作是统筹管理所有依赖关系，各种Android权限的声明以及工具库的实现。所有模块都依赖common模块。它的主要作用如下：

1. Common组件的AndroidManifest.xml中声明Android应用的所有权限uses-permission和uses-feature。所有业务组件无需在自己的AndroidManifest.xml中再重复声明权限了。

2. Common组件的build.gradle需要统一依赖业务组件中用到的各种第三方依赖库和jar包，如ARouter、Okhttp等。

3. Common组件中封装了项目中的公共组件，工具类，以及全局BaseApplication。

4. Common组件的资源文件中需要放置项目公用的Drawable、layout、sting、dimen、color和style 等等，另外项目中的 Activity主题必须定义在Common中，方便和BaseActivity配合保持整个Android应用的界面风格统一。

空壳模块

空壳模块就是一个空壳工程，没有任何的业务代码，也不能有Activity，但它又必须被单独划分成一个组件，而不能融合到其他组件中，是因为它有如下几点重要功能：

1. 空壳模块中声明了我们Android应用的Application，这个 Application必须继承自Common组件中的 BaseApplication（如果你无需实现自己的Application可以直接在表单声明BaseApplication），因为只有这样，在打包应用后才能让BaseApplication中的Context生效，当然你还可以在这个 Application中初始化我们工程中使用到的库文件，还可以在这里解决Android引用方法数不能超过65535 的限制，对崩溃事件的捕获和发送也可以在这里声明。

2. 空壳模块的 AndroidManifest.xml 是我Android应用的根表单，应用的名称、图标以及是否支持备份等等属性都是在这份表单中配置的，其他组件中的表单最终在集成开发模式下都被合并到这份 AndroidManifest.xml 中。

3. 空壳模块的build.gradle 是比较特殊的，app壳不管是在集成开发模式还是组件开发模式，它的属性始终都是：com.android.application，因为最终其他的组件都要被app壳工程所依赖，被打包进app壳工程中，这一点从组件化工程模型图中就能体现出来，所以app壳工程是不需要单独调试单独开发的。另外Android应用的打包签名代码混淆，以及buildTypes和defaultConfig都需要在这里配置。

普通业务模块

这个就是和业务相关的模块，无特殊的说明，如moudleA，moudleB，moudleC。

依赖关系：
壳模块依赖moudleA moudleB moudleC
各个moudle均依赖common