代码地址：https://github.com/ewgcat/ComponentDemo
上图是目前比较普遍使用的Android APP技术架构，往往是在一个界面中存在大量的业务逻辑，而业务逻辑中充斥着各种网络请求、数据操作等行为，整个项目中也没有模块的概念，只有简单的以业务逻辑划分的文件夹，并且业务之间也是直接相互调用、高度耦合在一起的；
上图单一工程模型下的业务关系，总的来说就是：你中有我，我中有你，相互依赖，无法分离。
然而随着产品的迭代，业务越来越复杂，随之带来的是项目结构复杂度的极度增加，此时我们会面临如下几个问题：
1、实际业务变化非常快，但是单一工程的业务模块耦合度太高，牵一发而动全身；
2、对工程所做的任何修改都必须要编译整个工程；
3、功能测试和系统测试每次都要进行；
4、团队协同开发存在较多的冲突.不得不花费更多的时间去沟通和协调，并且在开发过程中，任何一位成员没办法专注于自己的功能点，影响开发效率；
5、不能灵活的对业务模块进行配置和组装；
为了满足各个业务模块的迭代而彼此不受影响，更好的解决上面这种让人头疼的依赖关系，就需要整改App的架构。
上图是组件化工程模型，为了方便理解这张架构图，下面会列举一些组件化工程中用到的名词的含义：
名词 含义
集成模式 所有的业务组件被“app壳工程”依赖，组成一个完整的APP；
组件模式 可以独立开发业务组件，每一个业务组件就是一个APP；
app壳工程 负责管理各个业务组件，和打包apk，没有具体的业务功能；
业务组件 根据公司具体业务而独立形成一个的工程；
功能组件 提供开发APP的某些基础功能，例如打印日志、树状图等；
Main组件 属于业务组件，指定APP启动页面、主界面；
Common组件 属于功能组件，支撑业务组件的基础，提供多数业务组件需要的功能，例如提供网络请求功能；
**
Android APP组件化架构的目标是告别结构臃肿，让各个业务变得相对独立，业务组件在组件模式下可以独立开发，而在集成模式下又可以变为arr包集成到“app壳工程”中，组成一个完整功能的APP；
从组件化工程模型中可以看到，业务组件之间是独立的，没有关联的，这些业务组件在集成模式下是一个个library，被app壳工程所依赖，组成一个具有完整业务功能的APP应用，但是在组件开发模式下，业务组件又变成了一个个application，它们可以独立开发和调试，由于在组件开发模式下，业务组件们的代码量相比于完整的项目差了很远，因此在运行时可以显著减少编译时间。
这是组件化工程模型下的业务关系，业务之间将不再直接引用和依赖，而是通过“路由”这样一个中转站间接产生联系，而Android中的路由实际就是对URL Scheme的封装；
如此规模大的架构整改需要付出更高的成本，还会涉及一些潜在的风险，但是整改后的架构能够带来很多好处：
1、加快业务迭代速度，各个业务模块组件更加独立，不再出现业务耦合情况；
2、稳定的公共模块采用依赖库方式，提供给各个业务线使用，减少重复开发和维护工作量；
3、迭代频繁的业务模块采用组件方式，各业务研发可以互不干扰、提升协作效率，并控制产品质量；
4、为新业务随时集成提供了基础，所有业务可上可下，灵活多变；
5、降低团队成员熟悉项目的成本，降低项目的维护难度；
6、加快编译速度，提高开发效率；
7、控制代码权限，将代码的权限细分到更小的粒度；
