随着项目逐渐扩展，业务功能越来越多，代码量越来越多，开发人员数量也越来越多。此过程中，你是否有过以下烦恼？
1：项目模块多且复杂，编码一分钟，编译一次要5分钟甚至10分钟？太慢不能忍？ 2：改了一行代码 或只调了一点UI，就要run整个项目，再忍受一次10分钟？ 3：合代码经常发生冲突？脑壳清疼？ 4：被人偷偷改了自己模块的代码？很不爽？ 5：做一个需求，发现还要去改动很多别人模块的代码？ 6：别的模块已实现的类似功能，自己要用只能去复制一份代码再改改？ 7：“这个不是我负责的，我不管”，代码责任范围不明确？ 8：只做了一个模块的功能，但改动点很多，所以要完整回归测试？ 9：做了个需求，但不知不觉导致其他模块出现bug？
如果有这些烦恼，说明你的项目需要进行【组件化】了。
网上组件化的文章很多，我本人学习组建化的过程也借鉴了网上先辈们的文章。但大多数文章都从底层的细枝末节开始讲述，由下而上给人一种这门技术“博大精深”望而生畏的感觉。而我写这篇文章的初衷就是由上而下，希望别人在阅读的过程中能够觉得“组件化原来也就是这几个东西”的感觉。
组件化&模块化的区别 在传统的项目里我们通常情况下会有一个commonLib的Libary模块和一个app的application模块，业务中的逻辑都写在app中各个功能模块放到不同的包下。这样做有以下几个主要的缺点：
1.无论分包做的再好，随着项目的增大，项目会逐渐失去层次感，别人来接手的时候会很吃力。
2.我们在debug一个小功能的时候每次修改代码都需要重新build整个项目，这样显的很不合理（不知道AS的热部署有没有解决这个问题）
3.多人联合开发在版本管理中很容易出现冲突和代码覆盖的问题
在组件化项目中除了有commonLib和app模块外，我们按照功能划分各个业务组件模块（eg:微信可以划分出chat，contract，find，mine四个大模块），之前的包变成现在的模块，增加了层次感；每个功能模块可以单独编译，加快了编译速度，也为提供单元模块测试提供了支持；多人开发只负责自己的模块，直接避免了版本管理的冲突。
组件化开发可以有效降低代码模块的耦合度，使代码架构更加清晰，同时模块化的编译可以有效减少编译时间，当然总的编译时间是不会减少的，只是App模块化之后开发某个模块时，只需要编译特定模块，可以快速编译调试。
组件化的优势及架构组件化，去除模块间的耦合，使得每个业务模块可以独立当做App存在，对于其他模块没有直接的依赖关系。 此时业务模块就成为了业务组件。
而除了业务组件，还有抽离出来的业务基础组件，是提供给业务组件使用，但不是独立的业务，例如分享组件、广告组件；还有基础组件，即单独的基础功能，与业务无关，例如 图片加载、网络请求等。这些后面会详细说明。
组件化的优势 就显而易见了：
- 加快编译速度：每个业务功能都是一个单独的工程，可独立编译运行，拆分后代码量较少，编译自然变快。
- 提高协作效率：解耦使得组件之间 彼此互不打扰，组件内部代码相关性极高。 团队中每个人有自己的责任组件，不会影响其他组件；降低团队成员熟悉项目的成本，只需熟悉责任组件即可；对测试来说，只需重点测试改动的组件，而不是全盘回归测试。
- 功能重用：组件 类似我们引用的第三方库，只需维护好每个组件，一建引用集成即可。业务组件可上可下，灵活多变；而基础组件，为新业务随时集成提供了基础，减少重复开发和维护工作量。
理想的组件化架构：
1、组件依赖关系是上层依赖下层，修改频率是上层高于下层。
2、基础组件是通用基础能力，修改频率极低，作为SDK可共公司所有项目集成使用。
3、common组件，作为支撑业务组件、业务基础组件的基础（BaseActivity/BaseFragment等基础能力），同时依赖所有的基础组件，提供多数业务组件需要的基本功能，并且统一了基础组件的版本号。所以 业务组件、业务基础组件 所需的基础能力只需要依赖common组件即可获得。 4、业务组件、业务基础组件，都依赖common组件。但业务组件之间不存在依赖关系，业务基础组件之间不存在依赖关系。而 业务组件 是依赖所需的业务基础组件的，例如几乎所有业务组件都会依赖广告组件 来展示Banner广告、弹窗广告等。 5、最上层则是主工程，即所谓的“壳工程”，主要是集成所有的业务组件、提供Application唯一实现、gradle、manifest配置，整合成完备的App。
