相关博客:https://www.jianshu.com/p/e6eb9c8d120f
http://blog.csdn.net/guiying712/article/details/55213884
代码地址: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、控制代码权限,将代码的权限细分到更小的粒度;