安卓组件化（一）

相关博客&＃xff1a;https://www.jianshu.com/p/e6eb9c8d120f
http://blog.csdn.net/guiying712/article/details/55213884
代码地址&＃xff1a;https://github.com/ewgcat/ComponentDemo

单一工程:

上图是目前比较普遍使用的Android APP技术架构&＃xff0c;往往是在一个界面中存在大量的业务逻辑&＃xff0c;而业务逻辑中充斥着各种网络请求、数据操作等行为&＃xff0c;整个项目中也没有模块的概念&＃xff0c;只有简单的以业务逻辑划分的文件夹&＃xff0c;并且业务之间也是直接相互调用、高度耦合在一起的&＃xff1b;

上图单一工程模型下的业务关系&＃xff0c;总的来说就是&＃xff1a;你中有我&＃xff0c;我中有你&＃xff0c;相互依赖&＃xff0c;无法分离。
然而随着产品的迭代&＃xff0c;业务越来越复杂&＃xff0c;随之带来的是项目结构复杂度的极度增加&＃xff0c;此时我们会面临如下几个问题&＃xff1a;

1、实际业务变化非常快&＃xff0c;但是单一工程的业务模块耦合度太高&＃xff0c;牵一发而动全身&＃xff1b;
2、对工程所做的任何修改都必须要编译整个工程&＃xff1b;
3、功能测试和系统测试每次都要进行&＃xff1b;
4、团队协同开发存在较多的冲突.不得不花费更多的时间去沟通和协调&＃xff0c;并且在开发过程中&＃xff0c;任何一位成员没办法专注于自己的功能点&＃xff0c;影响开发效率&＃xff1b;
5、不能灵活的对业务模块进行配置和组装&＃xff1b;

为了满足各个业务模块的迭代而彼此不受影响&＃xff0c;更好的解决上面这种让人头疼的依赖关系&＃xff0c;就需要整改App的架构。

上图是组件化工程模型&＃xff0c;为了方便理解这张架构图&＃xff0c;下面会列举一些组件化工程中用到的名词的含义&＃xff1a;

名词 含义
集成模式 所有的业务组件被“app壳工程”依赖&＃xff0c;组成一个完整的APP&＃xff1b;
组件模式 可以独立开发业务组件&＃xff0c;每一个业务组件就是一个APP&＃xff1b;
app壳工程 负责管理各个业务组件&＃xff0c;和打包apk&＃xff0c;没有具体的业务功能&＃xff1b;
业务组件 根据公司具体业务而独立形成一个的工程&＃xff1b;
功能组件 提供开发APP的某些基础功能&＃xff0c;例如打印日志、树状图等&＃xff1b;
Main组件 属于业务组件&＃xff0c;指定APP启动页面、主界面&＃xff1b;
Common组件 属于功能组件&＃xff0c;支撑业务组件的基础&＃xff0c;提供多数业务组件需要的功能&＃xff0c;例如提供网络请求功能&＃xff1b;
**
Android APP组件化架构的目标是告别结构臃肿&＃xff0c;让各个业务变得相对独立&＃xff0c;业务组件在组件模式下可以独立开发&＃xff0c;而在集成模式下又可以变为arr包集成到“app壳工程”中&＃xff0c;组成一个完整功能的APP&＃xff1b;
从组件化工程模型中可以看到&＃xff0c;业务组件之间是独立的&＃xff0c;没有关联的&＃xff0c;这些业务组件在集成模式下是一个个library&＃xff0c;被app壳工程所依赖&＃xff0c;组成一个具有完整业务功能的APP应用&＃xff0c;但是在组件开发模式下&＃xff0c;业务组件又变成了一个个application&＃xff0c;它们可以独立开发和调试&＃xff0c;由于在组件开发模式下&＃xff0c;业务组件们的代码量相比于完整的项目差了很远&＃xff0c;因此在运行时可以显著减少编译时间。

这是组件化工程模型下的业务关系&＃xff0c;业务之间将不再直接引用和依赖&＃xff0c;而是通过“路由”这样一个中转站间接产生联系&＃xff0c;而Android中的路由实际就是对URL Scheme的封装&＃xff1b;
如此规模大的架构整改需要付出更高的成本&＃xff0c;还会涉及一些潜在的风险&＃xff0c;但是整改后的架构能够带来很多好处&＃xff1a;

1、加快业务迭代速度&＃xff0c;各个业务模块组件更加独立&＃xff0c;不再出现业务耦合情况&＃xff1b;
2、稳定的公共模块采用依赖库方式&＃xff0c;提供给各个业务线使用&＃xff0c;减少重复开发和维护工作量&＃xff1b;
3、迭代频繁的业务模块采用组件方式&＃xff0c;各业务研发可以互不干扰、提升协作效率&＃xff0c;并控制产品质量&＃xff1b;
4、为新业务随时集成提供了基础&＃xff0c;所有业务可上可下&＃xff0c;灵活多变&＃xff1b;
5、降低团队成员熟悉项目的成本&＃xff0c;降低项目的维护难度&＃xff1b;
6、加快编译速度&＃xff0c;提高开发效率&＃xff1b;
7、控制代码权限&＃xff0c;将代码的权限细分到更小的粒度&＃xff1b;