客户端组件化

为什么要组件化模块化

目前项目中存在的问题

1. 组件之间依赖很严重 耦合严重 例如GMBase GMPhobos
2. 编译慢，效率低
3. 业务开发分工不明确，开发人员要关心非业务的代码
4. 改代码时，可能会影响其他业务，牵一发动全身
5. 代码结构不清晰，架构不够稳定，也不便于扩展和组件复用

优点

1. 架构更清晰，解耦
   2.加快编译速度
   3.业务分工明确，开发人员仅专注与自己的业务，提高开发效率
   4.组件、业务独立更新版本，可回滚，持续集成
   5.客户端所有页面 支持协议跳转 支持运营 配置跳转到客户端各页面

组件的定义

组件是构成业务或者功能模块的基本单位。原则上，组件与组件之间互不依赖。

模块，module

例如，我们的社区，是一个业务，可以叫“社区模块”。它可以拆分更小的组件：搜索、签到、评论等
我们的交易金融，是一个业务，可以叫“社区模块”。它可以拆分更小的组件：搜索、签到、评论等

两者关系

从上面的阐述可以得出，一个工程，由多个模块组成，每个模块由多个组件构成。但很多时候，两者界限还是相当模糊。例如“日志组件”称为“日志模块”，也没有违和感。
组件从业务角度上不能继续拆分，可替换，可复用；
模块的定义比较笼统，可以是一个Business业务，可以是技术架构中一个业务，也可以是几个组件构成的小功能

组件化和解耦

大家不妨先思考两个问题：

为何要进行组件化开发？

各个组件之间是否一定需要解耦？

采用组件化，是为了组件能单独开发，能单独开发App就能快速集成，所以单独开发是结果。要让组件能单独开发，组件必须职责单一，对于代码中已有模块，就需要用到重构和解耦的技术，所以重构和解耦是过程。那解耦是否是必须的过程？不一定。比如UIKit，我们用这个系统组件并没有使用任何解耦手段。问题来了，UIKit苹果可以独立开发，我们使用它为什么没用解耦手段？答案很简单，UIKit没有依赖我们的代码所以不用解耦。

PS：可以不纠结组件、服务、模块、框架的概念，只关心一件事，这一部分代码能否独立开发，能就叫组件，不能我管你叫什么

我们之所以要解耦才能独立开发，通常是出现了循环依赖。这时候当然可以无脑的用路由把两个组件的耦合解开，也可以独立开发。然而，这样做只是把强引用改成了弱引用，代码还是烂代码。站在重构的角度来说，A、B组件循环依赖就是设计有问题，要么应该重构A、B让依赖单向；要么应该抽离一个共用组件C，让A、B组件都只依赖于C。
如果我们每个组件都只是单向依赖其他组件，各个组件之间也就没有必要解耦。再换个角度说，如果一个组件职责不单一，即使跟其他组件解耦了，组件依然不能很好的工作。如何解耦只是重构过程中可选手段，代码设计的原则如依赖倒置、接口隔离、里氏替换，都可以指导我们写出好的组件。
所以在组件化中重要的是让组件职责单一，职责单一的重要标志之一就是没有组件间的循环依赖