1、单体应用

所有代码写在一个工程里。不同业务写到各自模块，以包名来区分。

弊端
1、无论包名做的再好，随着项目扩大，项目失去层次感，接受吃力。

2、报名作为约束，太弱了。一不注意就会出现不同业务之间之间相互调用，代码高度耦合。

3、多人联合开发在代码管理中很容易出现冲突和代码覆盖问题。

2、组件化

业务组件层各个组件不再出现横向的、直接的依赖关系，可以分别单独编译成一个APK安装包，进行安装、测试，也可以合并编译成一个完成的APK包。

2.1、为什么使用组件化

组件化基于可重用的目的，将应用拆分成多个独立组件，以减少耦合。
1.）通过关注点分离的形式，将App分离成多个模块，每个模块都是一个组件。解决了各种业务代码耦合在一起所导致的问题。
2.）开发的过程中，让这些组件被其它组件依赖，但是在调试时也可以单独成为独立的工程并且运行，这样就解决了因为编译耗时过多降低开发效率的问题。
3.）多人开发中，每个组件模块由单人负责，降低了开发之间沟通的成本，减少因代码风格不一致而产生的相互影响。

2.2、什么是组件化

1.）组件（Component）,是对数据和方法的简单封装，功能单一，高内聚，并且是业务能划分的最小粒度。
2.）组件化是基于可重用的目的，将大型的软件系统按照分离关注点的形式，拆分成多个独立的组件，使得整个软件系统也做到电路板一样，是单个或多个组件元件组装起来，哪个组件坏了，整个系统可继续运行，而不出现崩溃或不正常现象，做到更少的耦合和更好的内聚。

2.3、区分模块化与组件化

1.）模块化是将一个程序按照其功能做拆分，成为相互独立的模块，以便于每个模块只包含与其功能相关的内容，模块我们相对熟悉，比如登录功能可以是一个模块，搜索功能可以是一个模块等等。
2.）组件化是模块化思想的一种演进，它们二者本质都是一致的。
组件化更注重关注点分离，所谓的关注点分离，就是把复杂的问题做到合理分解，再分别仔细研究这些问题的不同侧面(关注点)，最后综合得到整体解决方案。
如果从集合角度来看的话，可以说往往一个模块包含了一个或多个组件，或者说模块是一个容器，由组件组装而成。简单来说，组件化相比模块化粒度更小。

2.4、区分组件化与插件化

1.）插件化也是基于模块化的思想，将应用拆分成多个模块，而这些模块都是一个APK，最终打包时将宿主APK和插件APK分开打包。在运行程序时，宿主APK可以动态的选择并加载想要的插件APK。
2.）插件化与组件化存在很多相似之处，但是它们根本的区别在于：
组件化的模块虽然在调试的时候可以切换到application独立运行，但是最终在打包时，每个模块始终都只是一个library，整个应用只有单独的一个APK。
插件化是拆分出了多个APK，并且在运行时通过动态加载的技术方案，来加载这些插件APK。

2.5、组件化要考虑的问题

分而治之，并行开发，一切皆组件。要实现组件化，无论采用什么样的技术方式，都需要考虑以下几个方面的问题：
1.）组件分层：如何将一个庞大的项目工程分成有机的整体？
2.）组件单独运行和集成调试：每个组件都是高度内聚的，是一个完整的整体，如何让其单独运行和调试？在开发解读如何做到按需编译组件？
3.）组件间通信：每个组件具体实现细讲都互相不了解，但每个组件都需要给其他调用方法提供服务，那么主项目与组件、组件与组件之间如何通信就变成关键？
4.）组件生命周期：这里的生命周期指的是组件在应用中存在的时间，组件是否可以做到按需、动态使用，因此就会涉及到组件加载、卸载等管理问题。

2.6、组件分层

组件大致分层如下：主工程、业务组件层、功能组件层、基础组件层。

3、demo

根据组件的分层来创建module。

3.1、创建module

1.）创建一个项目名为Component(名字随意)，作为我们的主工程，是整个应用的主入口。对项目做一些初始化和配置都是在主工程里。

2.）创建第2个业务组件，一个main，一个login。File–>New–>New Module --> Phone & Tablet。业务组件都选择Phone & Tablet，这样后面就可以进行单独的运行和调试。

为了让分层更明显，在Module name栏中加一个moduleCore，后面创建的所有业务组件都放到moduleCore文件夹下面。在Package name栏加一个module，避免命名冲突的一些问题。



3.）创建基础组件。File --> New --> New Module --> Android Library。
在Module name栏中加一个moduleBase，创建的基础组件都放在该文件夹下。同样在Package name栏加上一个module避免命名冲突。

4.）创建功能组件，File --> New --> New Module --> Android Library。

最后，创建的结果如下

3.2、管理组件分层中业务组件、基础组件之间的依赖关系

对依赖做一个统一的管理，避免因版本不一致而产生的依赖冲突。这么多的module，它可能去依赖各种第三方库、SDK。因此，这里先做一个版本的管理。

1.）在project下的build.gradle里创建一个ext{}，里面添加如下内容。

isDebug = false //当它为true时，是调试模式，组件可以单独运行(applicaton)；当它为false，是正式的编译打包的模式(library). 作业：使得业务组件可以在application和library之间进行切换

    android = [
            compileSdkVersion: 32,
            minSdkVersion: 21,
            targetSdkVersion: 32,
            buildToolsVersion: "30.0.2",
            versionCode: 1,
            versionName: "1.0"
    ]

    applicationId = [ // 可以切换到application
            "app" : "com.example.component",
            "main" : "com.example.module.main",
            "login" : "com.example.module.login"
    ]
// SDK的一下library
    library = [
            "appcompat" : "androidx.appcompat:appcompat:1.3.0",
            "material" : "com.google.android.material:material:1.4.0",
            "constraintlayout" : "androidx.constraintlayout:constraintlayout:2.0.4"
    ]
//第三方的library
    libARouter = "com.alibaba:arouter-api:1.5.1"
    libARouterCompiler = "com.alibaba:arouter-compiler:1.5.1"
    libGson = "com.google.code.gson:gson:2.8.6"

2.）修改 main业务组件 里的build.gradle文件(login是一样的)。


当main/login是一个applicaton (isDubug==true时, 可以单独运行)时，对AndroidManifest.xml文件也要进行修改。
首先，在mian下面创建一个debug文件夹，然后拷贝一份AndroidManifest.xml 到里面，如下

其次，将main下面的AndroidManifest.xml 做如下修改(注意：不是修改debug下的那个AndroidManifest.xml)

最后，再修改build.gradle(main/login)，对当前的业务组件是application还是library进行判断，然后动态的选择两个AndroidManifest.xml

3.）修改 libBase基础组件 里的build.gradle文件

4.）修改 modulePay功能组件 里的build.gradle文件。

5.）修改**主工程(app)**里的build.gradle文件。


到这里，组件化创建工程就以完成。
当把project下的build.gradle里的ext里的isdebug改成true时，就可以单独运行moduleCore.man/moduleCore.login。

3.3、业务组件间通信和参数传递

使用 组件路由，待续…