模块化到组件化

模块化：模块化就是将一个程序按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容。

组件化：每个组件是一个独立的app。每个组件都有自己独立的版本,可以独立的编译,测试,打包和部署

开发的架构的历史：

1）单工程开发模型：最早的开发模型

这种工程模式，随着业务的增加，项目越来越不好维护，耦合增加的同时编译时间太长

2）主工程多组件开发模型：将业务和基础库 都抽取出来，成为业务组件和基础组件。主工程（也称为壳工程）是个可运行的app，做为所有组件的入口。主工程通过依赖的方式使用组件所提供的功能

这种工程模式组件以jar的形式呈现,或以aar的形式呈现.不论是jar还是aar,本质上都是Library,他们不能脱离主工程而单独的运行.当团队中成员共同参与项目的开发时,每个成员的开发设备中必须至少同时具备主工程和各自负责组件,不难看出通过对项目实行组件化,每个成员可以专注自己所负责的业务,并不影响其他业务,同时借助稳定的基础组件,可以极大减少代码缺陷,因而整个团队可以以并行开发的方式高效的推进开发进度.

该模型仍然存在一些可以改进的点:每次修改依赖包,就需要重新编译生成lib或者aar.比如说小颜同学接手了一个项目有40多个组件,在最后集成所有组件的时候,小颜同学发现其中某组件存在问题,为了定位和修改该组件中的问题,小颜同学不断这调试该组件.由于在该模型下,组件不能脱离主工程,那么意味着,每次修改后,小颜同学都要在漫长的编译过程中等待.

3）主工程多子工程开发模型：所有业务组件不再是mouble而是作为一个子工程,基础组件可以使moudle,也可以是子工程,该子工程和主工程不同:Debug模式下下作为app,可以单独的开发,运行,调试;Release模式下作为Library,被主工程所依赖,向主工程提供服务.

在该种模型下,当小颜同学发现某个业务组件存在缺陷,会如何做呢?比如是基础组件2出现问题,由于在Debug模式下,基础组件2作为app可以独立运行的,因此可以很容易地对该模块进行单独修改,调试.最后修改完后只需要重新编译一次整个项目即可.

第二部分：组件的实施

1）子工程切换方式：

在主工程多子工程模式下，子工程在debug模式下可以单独运行，但是在release模式下仅做为library运行。我们应该如何设置呢？

采用Gradle构建的工程中,用apply plugin: 'com.android.application'来标识该为Application,而apply plugin: 'com.android.library'标志位Library.因此,我们可以在编译的是同通过判断构建环境中的参数来修改子工程的工作方式,在子工程的gradle脚本头部加入以下脚本片段:

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

除此之外,子工程中在不同的运行方式下,其AndroidMainifest.xml也是不相同的,需要为其分别提供自己AndroidManifest.xml文件:在子工程src目录下(其他位置创建)创建两个目录,用来存放不同的AndroidManifest.xml,比如这里我创建了debug和release目录 

在该子工程的gradle构建脚本中根据构建方式制定：

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

2）组件通信

在主工程多子工程模式下，子工程需要相互通信（其实我们希望他们都是独立的，没有任何通信耦合的）

解决通信的问题，我们只能通过“组件总线”了

所有挂载到组件总线上的业务组件,都可以实现双向通信.