为什么要组件化模块化
目前项目中存在的问题
- 组件之间依赖很严重 耦合严重 例如GMBase GMPhobos
- 编译慢，效率低
- 业务开发分工不明确，开发人员要关心非业务的代码
- 改代码时，可能会影响其他业务，牵一发动全身
- 代码结构不清晰，架构不够稳定，也不便于扩展和组件复用
优点
- 架构更清晰，解耦 2.加快编译速度 3.业务分工明确，开发人员仅专注与自己的业务，提高开发效率 4.组件、业务独立更新版本，可回滚，持续集成 5.客户端所有页面 支持协议跳转 支持运营 配置跳转到客户端各页面
组件的定义
组件是构成业务或者功能模块的基本单位。原则上，组件与组件之间互不依赖。
模块，module
例如，我们的社区，是一个业务，可以叫“社区模块”。它可以拆分更小的组件：搜索、签到、评论等 我们的交易金融，是一个业务，可以叫“社区模块”。它可以拆分更小的组件：搜索、签到、评论等
两者关系
从上面的阐述可以得出，一个工程，由多个模块组成，每个模块由多个组件构成。但很多时候，两者界限还是相当模糊。例如“日志组件”称为“日志模块”，也没有违和感。 组件从业务角度上不能继续拆分，可替换，可复用； 模块的定义比较笼统，可以是一个Business业务，可以是技术架构中一个业务，也可以是几个组件构成的小功能
组件化和解耦
大家不妨先思考两个问题：
为何要进行组件化开发？
各个组件之间是否一定需要解耦？
采用组件化，是为了组件能单独开发，能单独开发App就能快速集成，所以单独开发是结果。要让组件能单独开发，组件必须职责单一，对于代码中已有模块，就需要用到重构和解耦的技术，所以重构和解耦是过程。那解耦是否是必须的过程？不一定。比如UIKit，我们用这个系统组件并没有使用任何解耦手段。问题来了，UIKit苹果可以独立开发，我们使用它为什么没用解耦手段？答案很简单，UIKit没有依赖我们的代码所以不用解耦。
PS：可以不纠结组件、服务、模块、框架的概念，只关心一件事，这一部分代码能否独立开发，能就叫组件，不能我管你叫什么
我们之所以要解耦才能独立开发，通常是出现了循环依赖。这时候当然可以无脑的用路由把两个组件的耦合解开，也可以独立开发。然而，这样做只是把强引用改成了弱引用，代码还是烂代码。站在重构的角度来说，A、B组件循环依赖就是设计有问题，要么应该重构A、B让依赖单向；要么应该抽离一个共用组件C，让A、B组件都只依赖于C。 如果我们每个组件都只是单向依赖其他组件，各个组件之间也就没有必要解耦。再换个角度说，如果一个组件职责不单一，即使跟其他组件解耦了，组件依然不能很好的工作。如何解耦只是重构过程中可选手段，代码设计的原则如依赖倒置、接口隔离、里氏替换，都可以指导我们写出好的组件。 所以在组件化中重要的是让组件职责单一，职责单一的重要标志之一就是没有组件间的循环依赖
