为什么要组件化？

从个人经历来说的话，随着所接触的APP的体积变得越来越大，业务的也变得越来越复杂，业务模块的数量越来越多，而且每个模块的代码也变的越来越多，单一工程下的APP架构势必会影响开发效率，增加项目的维护成本，每个工程师都要熟悉如此之多的代码，将很难进行多人协作开发，而且Android项目在编译代码的时候电脑会非常卡，又因为单一工程下代码耦合严重，每修改一处代码后都要重新编译打包测试，导致非常耗时，代码想要做单元测试也很难。

目前大部分app的单一项目结构原型。大致如下图所示：

屏幕快照 2017-10-28 17.53.16.png

我们再来看下他们的直接的依赖关系图：

屏幕快照 2017-10-28 18.03.01.png

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

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

为了更好的满足各个业务的迭代而彼此不受影响，更好的解决上面这种让人头疼的依赖关系，开始着手app组件化。

组件化：

APP组件化架构整改的方向就是告别结构臃肿的时代。业务组件和功能组件，类库工程之间遵循向下依赖关系，相互独立，app组件化项目结构原型。大致如下图所示：

屏幕快照 2017-10-28 18.37.35.png

一个项目工程拆分成若干个模块工程，由app壳工程提供统一的入口，每个业务独立的模块module共享项目的依赖库。由壳工程集成需要引入的业务模块，至于各个独立的业务模块之间的调用依赖关系，我们借助一个中间层充当路由功能，这个路由我们放在各个业务模块共同引用的依赖库那一层。由路由统一调度他们之间的依赖关系，路由调度解决平级依赖问题示意图：

屏幕快照 2017-10-28 18.50.12.png

APP 业务组件化架构优点：

(1)加快迭代速度，各个业务模块组件更加独立，不再因为业务耦合情况，在发版时候，由于互相等待而迟迟不能发布版本。
(2)稳定的公共模块采用依赖库方式，提供给各个业务线使用，减少重复开发和维护工作量。
(3)迭代频繁的业务模块采用组件方式，各业务线研发可以互不干扰、提升协作效率，并控制产品质量。
(4)为新业务随时集成提供了基础，所有业务可上可下，灵活多变。
(5)降低团队成员熟悉项目的成本，降低项目的维护难度。
(6)加快编译速度，提高开发效率